系统实时性评估指标-中断延迟简介
实时系统的主要特点是必须保证处理结果的时间确定性,我们通常使用基准程序法对其进行性能指标评估。通过对实时系统的性能评估,就可以确认系统的时间确定性、可靠性、稳定性等指标。
衡量实时操作系统实时性能的重要指标有很多,本文将对运用最为广泛的指标之一,中断延迟时间,进行介绍。那么什么是中断延迟?如何测得实时操作系统的中断延迟呢?让我们一起来看看吧!
什么是中断延迟?
中断延迟(Interrupt Latency)是指从硬件中断发生到开始执行中断处理程序第一条指令之间的这段时间。也就是计算机接收到中断信号到操作系统作出响应,并完成换到转入中断服务程序的时间。
由于外部事件的发生常常是以一个中断申请信号的形式来通知处理器,然后才运行中断服务程序中来处理该事件,所以中断延迟是影响系统实时性的一个重要因素。
为了进一步描述清楚中断延迟,我们把中断延迟的时间分为以下三种:
- 识别中断时间:外界硬件发生了中断后,CPU到中断处理器读取中断向量,并且查找中断向量表,找到对应的中断服务子程序(ISR)的首地址,然后跳转到对应的ISR去做相应处理。
- 等待中断打开时间:在允许中断嵌套的实时操作系统中,中断也是基于优先级的,允许高优先级中断抢断正在处理的低优先级中断。所以,如果当前正在处理更高优先级的中断,即使此时有低优先级的中断,也系统不会立刻响应,而是等到高优先级的中断处理完之后才会响应。即使在不支持中断嵌套的系统中(即中断是没有优先级的,中断是不允许被中断的),如果当前系统正在处理一个中断,而此时另一个中断到来了,系统也是不会立即响应的,而只是等处理完当前的中断之后,才会处理后来的中断。
- 关闭中断时间:当前中断来了,但由于之前某个程序访问共享区,而关闭中断了,导致当前中断得不到处理。而只有等待其访问完成共享区之后,再开中断。
怎样减少中断延迟?
明白了什么是中断延迟,以及哪些因素会影响中断延迟,那么,怎样减少中断延迟呢?在OneOS系统中,经过开发前期分析与实测,我们发现通过对内核加锁粒度优化可以减少中断延迟。
大粒度的加锁位置为:
- 任务栈切换流程;
- 时钟中断处理流程。
在任务栈切换流程中,OneOS采用了前置计算待调度任务算法,可以有效降低该流程的加锁粒度。
在时钟中断处理流程中,因为要判断有哪些睡眠任务和阻塞任务已超时,往往要处理多个在TICK队列上的任务,若采用一把大锁,势必导致加锁粒度过大、影响外部中断响应时间(嵌入式系统一般都是支持中断抢占的)。OneOS采用每处理完1个在TICK队列上的任务后开中断,之后再关中断的方式,可以降低加锁粒度。(不过这样做会导致任务调度系统复杂,必须要认真处理此微小时隙所带来的额外资源冲突问题噢~)
如何测试中断延迟?
既然已经找到了减少中断延迟的方法,那我们来测试一下优化后的结果吧!
为了满足测试要求,首先系统选取一个定时器中断,并且设置定时器中断的优先级比其他所有中断优先级都高(这样就屏蔽掉等待中断打开时间)。
设置定时器的计数模式为递增模式,这样定时器产生中断时会重新装入0到定时器计数器中。在中断定时器中断服务函数中直接读取定时器计数值,通过定时器计数值除以定时器时钟得到中断延迟时间。
同时,为了避免关中断的时间内发生多次定时器中断,建议定时器中断的周期大于1ms。在多次产生定时器中断后我们记录下最大的中断延迟作为测试结果,最后我们还需要添加内核接口的调用。具体的流程下图所示。
根据以上测试方法,可以获得如下测试结果:
测试结果可以看出,OneOS的实时性得到了强有力的保证。
在第三方的测试中,基于同样的硬件平台,OneOS内核性能主要指标也均领先于竞品,实时性跑分大幅领先。未来,OneOS将继续努力,朝着成为业界领先的国产操作系统的目标不断前行!

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
Flink+ice 实现可视化规则编排与灵活配置(Demo)
ice文档站:http://124.221.148.247/zh 1 Demo仓库地址: github:https://github.com/zjn-zjn/flink-ice gitee:https://gitee.com/waitmoon/flink-ice 2 Demo功能描述 通过netcat制造输入流(nc -l 9000 windows:nc -l -p 9000) flink接收本地9000端口输入流,以回车(\n)分割单词 输入流经过IceProcessor处理后打印结果流 3 项目搭建 使用flink-quickstart-java快速搭建flink项目 3.1 添加ice依赖 因flink为非Spring项目,需依赖ice-core并手动初始化,Spring项目直接依赖ice-client-spring-boot-starter即可 <dependency> <groupId>com.waitmoon.ice</groupId> <artifactId>ice-core</artifactId> <v...
- 下一篇
通过自动化单元测试的形式守护系统架构
1 背景 随着需求开发迭代,代码库规模逐渐变大,新的团队成员引入等诸多因素,系统起初制定的架构规则不可避免遭到破坏。不仅仅是破坏团队的统一开发规范,更为重要的是随着代码库规模逐渐增长,大大降低系统的可维护性、扩展性,增加评审复杂度和重构成本,也最终导致团队生产力下降以及研发成本增长。 在敏捷开发环境下,系统通过迭代增量的交付价值,系统架构也是如此。团队不可能在项目之初就建立完美的系统架构,系统架构应该随着系统迭代不断演进。 架构演进和架构腐化是看待架构的不同视角:架构腐化着眼于现状,架构演进侧重于未来 架构腐化不可避免,随着时间流转腐化现象必然发生。而我们需要做的是:通过某种方式及早发现和修正 2 为什么选择Archunit 我们需要通过引入一种机制或技术,降低或及早发现架构腐化现象的发生,保持统一的系统架构约束。 支持架构规则自动化检查 轻量级,接入成本低 结果及时反馈 灵活扩展且扩展成本低 对于架构规则常见的验证方式:代码评审、代码质量分析工具或平台、Archunit 以下对常见的几种方式进行优劣势对比: 代码评审:通过强流程控制代码评审活动发生,增强代码评审的强度和质量 优势...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- Windows10,CentOS7,CentOS8安装Nodejs环境
- CentOS8安装MyCat,轻松搞定数据库的读写分离、垂直分库、水平分库
- Red5直播服务器,属于Java语言的直播服务器
- SpringBoot2整合Thymeleaf,官方推荐html解决方案
- Jdk安装(Linux,MacOS,Windows),包含三大操作系统的最全安装
- CentOS7设置SWAP分区,小内存服务器的救世主
- SpringBoot2初体验,简单认识spring boot2并且搭建基础工程
- SpringBoot2全家桶,快速入门学习开发网站教程
- Docker安装Oracle12C,快速搭建Oracle学习环境
- SpringBoot2整合MyBatis,连接MySql数据库做增删改查操作