RTLinuxPro处理器预留和中断控制技术剖析

RTLinuxPro 处理器预留和中断控制技术一些 Linux 实时操作系统制造商把中断响应时间和处理器预留作为得到实时 Linux 的主要方法。但其负面结果是功能环境缩小、服务功能简单，没有实时性的保证。本文分析了 RTLinuxPro 是如何简易地为用户产生处理器预留和中断控制，以及如何提供一个完整的POSIX RTO环境来支持它。硬实时操作系统一直以来是一个功能单一、非集成化，不受重视的应用领域。另一方面， Linux 系统则代表了目前计算机技术当中良好的集成性和普适性。如果把这二者结合起来，那将得到一个功能完善的硬实时操作系统，同时可以把具有web接入的用户的网络功能部分以一种快捷、安全和简单的方 式集成到系统当中。图 1： RTLinux 技术。RTCore就是这样一种能够为RTLinuxPro和RTCoreBSD1供硬实时环 境的例子。除了大量的Linux应用接口外，RTCore还提供POSIX境下硬实时 的中断句柄、线程、信号、互斥体(mutexes) 、信号量 (semaphores) 、进程间通信等。同类技术中，其它方法的重点是放在对中断响应时间的提高方面。其工作本身是有探索价值的，但取得的结果却很有限，只是在一个特定LINUX版本和硬件体系结构下使中断响应时间得到了改善，仍然没有硬实时方面的保 证。同时，采用这些方法的操作系统提供给编程者的服务也十分有限。尽管对 于某些基础应用，如频繁的采样和对采样信号的简单快速响应的场合，这些方 法是有效的，但多数情况下，却反映出现实中的应用领域根本就不是那么地简 单。特定CPU上的线程引导先来看一个实时线程如何将自己装入一个给定的CPU的例子。 此处放 L1这里没有什么新的东西，一个新的线程产生，就像其他任何的 POSIX应用一样。区别只是这一行“ pthread_attr_setcpu_np(&attr, 0); ”。这旬告诉RTCore当新的线程创建的时候，应该把它放到CPU 0中，而且永远不会从CPU+被清除掉。原因在于当一个线程/任务被允许从一个处理器转移到另一 个的时候，高速缓存(Cache) 的影响会改变实时性能。如果知道了在什么样的CPU都有哪些线程，那么就可以把这种转移的影响降低到最小，实时性能也 会得到显著提高，同时RTOS勺调度负荷也降到了最低。另外一个比较新的东西是“ timespec_add_ns(&next,1000*1000); ”，这句给 timespec 结构体增加了一个毫秒，它是为了方便起见而提供的一个函数(POSIX并没有定义这个函数，所以用户通常要手工规格化一些数据)。如果用户熟悉RTLinux,就不应该对这个函数感到陌生，它已经用了好几年了。RTLinuxPro 的用户应该注意到这个函数： rtl_main_wait() ，这是一个事件等待句柄，它允许程序暂时挂起直到从用户或者系统接收到一个退出信号。 ( 类似于GUI应用中的事件等待进入函数)。上述已经在一个特定的CPU有了一个线程，并且可以保留该 CPU 被普通OS所占用。本文中进行的所有测试都把 Linux当作一个普通的OS预留处理器这个小标题似乎有些模棱两可。本文的题目隐含了处理器预留这个难题的重点，似乎需要深入而详细地讨论，但实际上，代码里只要一行程序就可以了。下面是对前面程序的修改：pthread_attr_setcpu_np(&attr, 0);pthread_attr_setreserve_np(&attr, 1);pthread_create(&thread, NULL, thread_code, 0); .“ pthread_attr_setreserve_np(&attr,1); ”这句设置了线程的一个布尔属性。当在特定处理器上产生了一个线程后，只要该线程存在，GPO就被禁止在这个处理器上运行。实际上也是如此的,一旦这条语句被执行，GPO就被禁止在处理器上 面运行了，只能为创立的线程保留 CPU包括运行在CPUk的其它实时线程)。 在有些情况下，允许所有的实时应用程序直接保留在处理器的高速缓存中。由于处理器不用再去RAMfr取代码了，所以处理器的性能相对得到了提高。因为 GPOSK远不会在Cache中运行，从而不会把实时代码挤出Cache,所以Cache永远都被实时代码占据。 (Linux 相当庞大，一旦运行起来就会占据很大的Cache空间)。中断控制在上面的代码中，为实时代码保留CPU对其上的GPO叶断产生负面的影响。由于Linux 不在其上运行了，不能接受中断了，所以对于其他设备，如以太网设备这样的硬件就只等通过另外一个CPU Linux提供信号了。这样就使得保留的处理器不处理任何除了产生实时线程以外的任何中断。现在处理器完全在实时线程的控制下了，我们再次把重点放在处理器上所感兴趣的实时中断上。对于线程，由于可控的高速缓存的作用而使得结果的性能更好，同时也使得中断控制器被激活的次数达到最小，只需要处理很少量的中断了。下面看一下如何处理这个问题，由于POSIX处理不了中断，所以必须要有专门的RTCore函数来处理它，首先，我们在函数的前面定义一个 counting 中断句柄：.static int interrupt_count = 0;unsigned int interrupt_handler(unsigned int irq,struct rtl_frame *regs) interrupt_count+;rtl_global_pend_irq(irq);return 0;.然后把它加入到线程代码中，重新关注一下 CPU 0的中断：.static unsigned long affinity = 1;static unsigned long old_affinity;void *thread_code(void *t) struct timespec next;rtl_request_irq(4, interrupt_handler);rtl_irq_set_affinity(4, &affinity, &old_affinity);.在这里，有一个非常基本的中断句柄，该句柄只是增加中断源4 接收到的中断计数值(虽然我们对此中断不感兴趣，但它为GPO除留中断做以后处理) 。该句柄是通过rtl request irq() 函数加入到代码中的。一旦中断被清除，则释放该句柄同时恢复原来的相关屏蔽。.pthread_join(thread, NULL);rtl_irq_set_affinity(4, &old_affinity, NULL);rtl_free_irq(4);.在线程的初始化阶段，第一个相关函数调用将确保4 号中断在处理器0上面(相关参数为CPUW蔽位，如第0位为1说明中断应该指向CPU0)原来 的相关屏蔽就被存到旧的相关参数中了，这样当应用程序结束以后就可以重新恢复了。实际结果对于现在这些结果和所有的这些测试，我们只报告其中最坏的情况。测试结果一般情况值通常都非常低，但对实时应用而言没有什么意义。如果你看到实时操作系统的提供商引用那些一般情况、或向你展示改善了的事件分布，则实际上，或者是他们想使的数字看起来更好一些，或者是由于他们的操作系统根本就是一个软实时系统。FSMLab守目信，如果要保证代码的绝对可: 那就必须在一个硬实时的系统当中，而系统的边界条件必须是最坏的情况。如果不是这样，那这样的操作系统就要归结到GPOST,通常这样的GPOSfB是非实时的或者充其量是软实时的。首先，改变测试例子来跟踪最坏情况下期望执行时间和实际执行时间之间的延迟。加入以下代码到线程代码中，同时声明结构体timespec 以跟踪最坏的情况：clock_nanosleep(CLOCK_REALTIME, TIMER_ABSTIME,&next, NULL);clock_gettime(CLOCK_REALTIME, &sample);timespec_sub(&sample, &next);if (timespec_gt(&sample,&worst) worst.tv_sec = sample.tv_sec;worst.tv_nsec = sample.tv_nsec;printf(Worst case - %lds, %ldns , worst.tv_sec,worst.tv_nsec);.每一个测试都将跟踪该程序体并且打印出新出现的最坏情况。因为我们关心的是处理器的预留和中断控制，所有的测试都是在RTCore下面做的，普通的 Linux 测试都是没有用的。无处理器预留的实时代码首先我们看一下上面讲过的无处理器预留的测试例子。例子涉及到实时线程每 1 毫秒跟踪其最坏情况偏移 ( 测试硬件是一个成熟的 1.2G 双核 Athlon) 。定时器中断将直接用来测量中断延迟。因为定时器中断延迟影响了进入调度器以及最后进入线程代码的总延迟，测试中最坏情况下的延迟是这三个因素的总和。因此，在本测试中最坏情况下的中断延迟保证要比最后的结果要低。测试例子经过了几天的运行，在极其高的磁盘负载、虚拟机负荷、网络负载以及开发者的使用下的得到的最坏情况下的值为16.299us 。通过对比该值与下一步将要得到的结果，你很容易发现高速缓存和Linux 之间的密切关系将影响系统，常常迫使Linux从RAMB新装载回Cache实际上，测试表明使用NetBSD(乍为GPOS!使得最坏情况数值降低，因为 NetBSD总体上比较小，不 像Linux运行起来要占用大量的 CACHE有处理器预留的实时代码在相同的一组条件下，处理器预留开启，并且程序运行周期相同，进行了同样的测试，得到的最坏情况值是2.079us ，情况得到了大幅改善。其它 的如高 IDE 使用率、以太网和其它的中断负载都对系统没有影响，因为它们都不是关注的焦点。总之，在初始化阶段计算出来Cache 的影响后，就可以找到最坏情况值了。这就是测试的整个过程，没有神秘的设置或者要费神的思考，也没有统计数据、规则或者其他之类的，就只是一个最坏情况值。在一个预留的处理器上运行一个周期性的线程，然后测量调度偏差并把最坏情况值打印出来。RTCore 的最坏情况下，时间延迟2.079us ，而实际上，在新的硬件上该值更小，同时仍然能够提供所需要的 Linux 系统的所有正常服务。进一步减小最坏情况值在一些应用当中，可能2us 的延迟也嫌太长。在这些情况下， RTCore提供预先定时器功能，它会告诉调度器有多少的内在硬件执行时间必须要考虑在内。在这种情况下，还有多达2.709us 的时间可以减小。所以，我们作如下的改动：struct timespec worst = 0, 0 ;struct timespec advance = 0, 2500 ;void *thread_code(void *t) .这个新的预先结构体表明了在此硬件上考虑的最坏情况补偿时间是2.5us( 如果需要，可以把该值设定为 2.709us) ，下面的代码就告诉调度器在调度一个任务的时候要把这个时间考虑在内：.timespec_add_ns(&next, 1000*1000);clock_nanosleep(CLOCK_REALTIME, TIMER_ABSTIME|TIMER_ADVANCE, &next, &advance);clock_gettime(CLOCK_REALTIME, &sample);.在和以前一样的负载下，运行同样的测试例子，我们看到的最坏情况值为143纳秒。最坏情况值开始于16us,然后伴随着处理器预留减小到 2us, 最后在加入3行预先调度代码后减小到0.1ms左右。这种预先调度法所带来的 减小是这样的，在预先时间的一部分调度器被激活，虽然这个过程要花费额外的几个周期，但是所带来了的好处是要求的线程活动能够在预定的几个时间片( 每个为 10 亿分之一秒) 内发生。超线程英特尔的超线程为实时处理器预留提供了一些方法。超线程本质上是在一个核内的多处理器，因此对于像 Linux这样的GPOS就有两个逻辑处理 器，但实际中只有一个物理处理器。从逻辑上讲这样做的一个优势就是可以隐藏CPUff有的复杂细节，然而处理器核仍然在共享着内部的一些资源而不是去复制这些资源。对于 Linux ，这一点显得不那么重要，因为对于一些应用而言带来的是好处，但对于其它的则变成了损失了。从实时的观点来看，如果一个线程运行在逻辑处理器0 上（物理处理器0） ，则它可能会做片刻的停留以等待处理器在逻辑处理器1（ 物理处理器0） 上处理 Linux 的工作。虽然这样做的结果是确定的，但是代价却增加了，在一个板子上最坏情况值不是原来的15us 了，超线程将该值提高到了 35us。而处理器预留技术 则可以使该值重新处于可以控制之下。对于有2 个超线程的处理器（4 个有效处理器 ） ，问题就成了在逻辑处理器0 上面生成一个预留的实时线程，在逻辑处理器 1 上生成另外一个线程，该线程或者阻塞在一个信号量上或者和其它的处理器异步处理实时工作。这样的话，还有2 个逻辑处理器（1 个物理处理器） 留给了 Linux ，因此还可以得到对称多处理器Linux 和在其它的超线程处理器上面很好的响应。当一个硬实时的应用软件运行达到或接近硬件的极限时，如果让Linux作为一个空闲线程运行就足以使Cache崩溃，并且运行实时代码会超出最坏情况响应时间。通过预留处理器和 Linux 分离开来以后，就可以使中断响应时间固定下来，Cache的命中率增加了，在硬件的极限下运行代码的性能也 提高了。通过预先调度，固有的硬件延迟也最小化了。特别指出的是RTCore是POSIX RTOS支持上面所说的一切。市场上 其它的一些解决方案能够在一定程度上提高中断响应时间，但除此之外不能保 证硬实时或许多服务功能。即使上面提供的只有一个实时线程的基本例子也不 是只有一个中断的方法所能够提供的。