T?=中断响应时间 任务停止 外部中断 中断分派 活动任务 中断例程 I RT 开始中断处理 图2.1异步中断和中断响应时间 中断响应时间并不是一个常量。它与操作系统和硬件平台有关。要测 量精确的关闭中断的时间，并不是通过上面的定义来进行。因为从中断到 来到当前任务停止属于中断延迟时间。在Liuⅸ中，内核或驱动程序显式 地关/开中断，一般是通过调用cliO/st0来进行操作。中断延迟程序计 算一对_ciO_stiO调用之间的时间。在调用_ciO时，记录系统时间值， 读出$t0被调用时的系统时间值。他们之间的时间差就是关中断时间。 Linux下的关中断时间如图2.2所示： 关中断时间测试程序重新写了cli0/sti0宏，以允许记录调用它们 的文件以及在何处调用。记录这些信息以分析在Liux中那些关中断时间 是比较长。（中断测试程序的代码在附录A) 我对Liux进行了大约3个小时的测试，测试的结果如表。在测试中 运行一些程序，其中包括一个磁盘循环拷贝程序，打开一些应用程序。可 以发现系统负载比较重时，系统的页面调度花了比较多的时间，将近500 微秒。表2.1表2.2是统计结果。 yan_joseph@163.net Copyright2002杨立峰 9
ryan_joseph@163.net Copyright 2002 杨立峰 9 图 2.1 异步中断和中断响应时间 中断响应时间并不是一个常量。它与操作系统和硬件平台有关。要测 量精确的关闭中断的时间，并不是通过上面的定义来进行。因为从中断到 来到当前任务停止属于中断延迟时间。在 Linux 中，内核或驱动程序显式 地关/开中断，一般是通过调用__cli()/__sti()来进行操作。中断延迟程序计 算一对__cli()/__sti()调用之间的时间。在调用__cli()时，记录系统时间值， 读出__sti()被调用时的系统时间值。他们之间的时间差就是关中断时间。 Linux 下的关中断时间如图 2.2 所示： 关中断时间测试程序重新写了__cli()/__sti()宏，以允许记录调用它们 的文件以及在何处调用。记录这些信息以分析在 Linux 中那些关中断时间 是比较长。（中断测试程序的代码在附录 A） 我对 Linux 进行了大约 3 个小时的测试，测试的结果如表。在测试中 运行一些程序，其中包括一个磁盘循环拷贝程序，打开一些应用程序。可 以发现系统负载比较重时，系统的页面调度花了比较多的时间，将近 500 微秒。表 2.1 表 2.2 是统计结果
外部中断或任务停止 系统调用 中断分派 中断完成 活动任务 开始中断处理 中断例程 中断执行时间 关中断时间 图2.2关中断时间 中断关闭时间直方图 600 500 470496 400 360 33 (sn) 300 246259267277279 口系列1 200 186190 50 100 42566292 0 00.0 12345678910111213141516 表2.1中断关闭时间直方图 ryan_joseph@163.net Copyright2002杨立峰 10
ryan_joseph@163.net Copyright 2002 杨立峰 10 图 2.2 关中断时间 中断关闭时间直方图 42 56 62 92 150186190 246259267277279 330360 470496 0 100 200 300 400 500 600 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 微秒(us) 系列1 表 2.1 中断关闭时间直方图
中断关闭时间概率密度函数直方图 口系列1 12345678910111213141516 表2.2中断关闭时间概率密度函数直方图 可以看出在我的测试系统中系统中断关闭时间最大达到496微秒，一 般中断关闭时间是在250微秒到300微秒左右。这次测试并没有进行所有 情况下的测试，从这些结果我们就可以看出：Liuⅸ的系统设计人员采用 分时的调度、低的计时分辨率、非占先式内核、关中断和虚拟内存是造成 系统关中断时间过于长的原因。 2.2.2上下文切换测试 上下文切换时间是保存一个进程状态，然后恢复另外一个进程状态的 时间。我写了一个测试程序来测试这个时间（程序见附录B)。程序运行 时，根据输入的参数来决定创建多少个进程。所有的进程用一个环形的 UNIX管道连接。程序中实现一个令牌在这些进程之间传递，迫使进行进 程间的上下文切换。程序记录在进程间传递令牌2000次所花的时间。每一 次令牌的传递有两个开销：上下文切换开销和令牌传递开销。程序首先计 算令牌在环形管道中传递的开销，在输出的结果已经除去了这部分开销。 为了计算更真实的切换时间，我加入了人为的数据在里面，进程切换 时间包括保存用户级数据状态的时间。测试的结果在表2.3所示，Y轴表 示切换时间，X轴表示进程数目，sze表示进程的大小。 yan_joseph@l63.net Copyright2002杨立峰 11
ryan_joseph@163.net Copyright 2002 杨立峰 11 中断关闭时间概率密度函数直方图 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 系列1 表 2.2 中断关闭时间概率密度函数直方图 可以看出在我的测试系统中系统中断关闭时间最大达到 496 微秒，一 般中断关闭时间是在 250 微秒到 300 微秒左右。这次测试并没有进行所有 情况下的测试，从这些结果我们就可以看出： Linux 的系统设计人员采用 分时的调度、低的计时分辨率、非占先式内核、关中断和虚拟内存是造成 系统关中断时间过于长的原因。 2.2.2 上下文切换测试 上下文切换时间是保存一个进程状态，然后恢复另外一个进程状态的 时间。我写了一个测试程序来测试这个时间（程序见附录 B）。程序运行 时，根据输入的参数来决定创建多少个进程。所有的进程用一个环形的 UNIX 管道连接。程序中实现一个令牌在这些进程之间传递，迫使进行进 程间的上下文切换。程序记录在进程间传递令牌 2000 次所花的时间。每一 次令牌的传递有两个开销：上下文切换开销和令牌传递开销。程序首先计 算令牌在环形管道中传递的开销，在输出的结果已经除去了这部分开销。 为了计算更真实的切换时间，我加入了人为的数据在里面，进程切换 时间包括保存用户级数据状态的时间。测试的结果在表 2.3 所示，Y 轴表 示切换时间，X 轴表示进程数目，size 表示进程的大小
从结果看，进程的随着进程的大小变化，切换时间在增加，在16k以 内增加幅度不大，是因为此时进程的大小还没有超出一级缓存的大小，超 过16k时，增加幅度比较大，进程大小达到64k时，切换时间达到300微 秒。Liux切换时间过于大的原因是系统保存了过于多的状态。在上下文 切换过程中，系统是关中断的，意味着此时的系统关中断时间超过300微 秒。对于实时应用来所是不能接受的。 350 ◆—size=2k 300 量一size=4k size=8k ×size=16k 250 米一size=32k ●—size=64k 200 米 米siz=32k 150 100 =16k 50 s12 si 16 24 32 64 96 进程数 表2.3上下文切换时间 2.3当前的实时操作系统 在这一节我们来看看一些操作系统的设计者是怎样来处理前一节所 提到的问题的。 最简单的解决方案是改变分时的调度程序。一个例子是文献[12]介绍 的系统。MNX的round-robin调度器换为基于优先级的调度器。由于在 MNX中不使用页面调度和页面交换技术，假如对时间的响应不过分要求 ryan_joseph@163.net Copyright2002杨立峰 12
ryan_joseph@163.net Copyright 2002 杨立峰 12 从结果看，进程的随着进程的大小变化，切换时间在增加，在 16k 以 内增加幅度不大，是因为此时进程的大小还没有超出一级缓存的大小，超 过 16k 时，增加幅度比较大，进程大小达到 64k 时，切换时间达到 300 微 秒。Linux 切换时间过于大的原因是系统保存了过于多的状态。在上下文 切换过程中，系统是关中断的，意味着此时的系统关中断时间超过 300 微 秒。对于实时应用来所是不能接受的。 size=2k size=4k size=8k size=16k size=32k size=64k 0 50 100 150 200 250 300 350 2 4 8 16 24 32 64 96 进程数 切换时间(us) size=2k size=4k size=8k size=16k size=32k size=64k 表 2.3 上下文切换时间 2.3 当前的实时操作系统 在这一节我们来看看一些操作系统的设计者是怎样来处理前一节所 提到的问题的。 最简单的解决方案是改变分时的调度程序。一个例子是文献[12]介绍 的系统。MINIX 的 round-robin 调度器换为基于优先级的调度器。由于在 MINIX 中不使用页面调度和页面交换技术，假如对时间的响应不过分要求
的话，这种方法是可以接受的。 一些在UNX系统中采用POSIX.1b-1993实时标准规定的方式。这个 标准规定了优先级调度，锁定用户程序页面，实时信号，改进的IPC和计 时器，和别的一些特性。依从这些标准使UNIX更适合实时应用。 Linux是部分支持POSIX.1b标准的操作系统12]。从1997年5月1 日起，在Liux中完全实现了适合用于控制的调度器和内存锁定技术，定 时器也部分实现。内核的不可占先，低的定时精度，和高的中断延迟仍然 没有解决。因此，POSIX.Ib兼容的Lix操作系统只适合一些软实时的处 理。 别的满足POSIX.1b的操作系统是QNX26]。QNX操作系统是微内核 的操作系统。内核只是实现4种服务：进程调度，进程间通信，低级的网 络通信，和中断分派。别的一些服务，比如说设备驱动程序和文件系统， 实现为与用户进程协同操作的方式。这样系统内核非常小（大约7KB左右） 而且非常快的。 QNX兼容POSIX1003.1标准（编程接口）和POSIX1003.2标准（外 壳和应用程序)。对于熟悉UNIX的开发者来说，是非常方便的。QNX提 供标准的UNIX部件：编译器，调试器，X-Windows,和TCP/IP。 微内核的设计比起传统的单块结构的设计有很多优势。调试用户程序 比起调试内核模块更为简单。假如用户进程运行在单独的地址空间（像 QNX那样)，内存管理错误在不同模块是相互隔离的。驱动程序可以更获 得多线程的好处。另外有良好的裁剪性。比如，QNX可以减少到100KB 以下以适合ROM的大小，或者扩展到全功能的多机开发环境。移植和维 护微内核的系统也更简单。缺点是微内核比起单块结构的内核来说不那么 紧凑。 对于实时处理的微内核它提供了轻量级进程，快的上下文切换，和 IPC。一个实时的用户进程可以中断设备驱动程序，在单块结构的内核是 不可能的。由于微内核操作系统是非常小的，可以方便的计算最坏情况下 的计时参数，比如中断延迟时间。 大多数的微内核操作系统的弱点是它的性能要差。微内核结构的操作 系统在进程间通信和上下文交换有比较重的系统开销。微内核操作系统只 提供简单的系统服务。因此，与单块结构的操作系统相比，完成相同的任 务微内核操作系统要进行更多的系统调用。虽然一些研究者认为上下文切 换，消息传递等可以高效地实现2]，就性能而言，单块结构的操作系统仍 yan_joseph@163.net Copyright2002杨立峰 13
ryan_joseph@163.net Copyright 2002 杨立峰 13 的话，这种方法是可以接受的。 一些在 UNIX 系统中采用 POSIX.1b-1993 实时标准规定的方式。这个 标准规定了优先级调度，锁定用户程序页面，实时信号，改进的 IPC 和计 时器，和别的一些特性。依从这些标准使 UNIX 更适合实时应用。 Linux 是部分支持 POSIX.1b 标准的操作系统[12]。从 1997 年 5 月 1 日起，在 Linux 中完全实现了适合用于控制的调度器和内存锁定技术，定 时器也部分实现。内核的不可占先，低的定时精度，和高的中断延迟仍然 没有解决。因此，POSIX.1b 兼容的 Linux 操作系统只适合一些软实时的处 理。 别的满足 POSIX.1b 的操作系统是 QNX[26]。QNX 操作系统是微内核 的操作系统。内核只是实现 4 种服务：进程调度，进程间通信，低级的网 络通信，和中断分派。别的一些服务，比如说设备驱动程序和文件系统， 实现为与用户进程协同操作的方式。这样系统内核非常小（大约 7KB 左右） 而且非常快的。 QNX 兼容 POSIX 1003.1 标准（编程接口）和 POSIX 1003.2 标准（外 壳和应用程序）。对于熟悉 UNIX 的开发者来说，是非常方便的。QNX 提 供标准的 UNIX 部件：编译器，调试器，X-Windows，和 TCP/IP。 微内核的设计比起传统的单块结构的设计有很多优势。调试用户程序 比起调试内核模块更为简单。假如用户进程运行在单独的地址空间（像 QNX 那样），内存管理错误在不同模块是相互隔离的。驱动程序可以更获 得多线程的好处。另外有良好的裁剪性。比如，QNX 可以减少到 100KB 以下以适合 ROM 的大小，或者扩展到全功能的多机开发环境。移植和维 护微内核的系统也更简单。缺点是微内核比起单块结构的内核来说不那么 紧凑。 对于实时处理的微内核它提供了轻量级进程，快的上下文切换，和 IPC。一个实时的用户进程可以中断设备驱动程序，在单块结构的内核是 不可能的。由于微内核操作系统是非常小的，可以方便的计算最坏情况下 的计时参数，比如中断延迟时间。 大多数的微内核操作系统的弱点是它的性能要差。微内核结构的操作 系统在进程间通信和上下文交换有比较重的系统开销。微内核操作系统只 提供简单的系统服务。因此，与单块结构的操作系统相比，完成相同的任 务微内核操作系统要进行更多的系统调用。虽然一些研究者认为上下文切 换，消息传递等可以高效地实现[2]，就性能而言，单块结构的操作系统仍