worldpress 建站,聚名网域名备案,项目网手游,服务类网站怎么做作者简介顺刚(网名:沐多)#xff0c;一线码农#xff0c;从事工控行业#xff0c;目前在一家工业自动化公司从事工业实时现场总线开发工作#xff0c;喜欢钻研Linux内核及xenomai#xff0c;个人博客 wsg1100#xff0c;欢迎大家关注#xff01;本文讲述一些有利于提高x… 作者简介顺刚(网名:沐多)一线码农从事工控行业目前在一家工业自动化公司从事工业实时现场总线开发工作喜欢钻研Linux内核及xenomai个人博客 wsg1100欢迎大家关注本文讲述一些有利于提高xenomai实时性的配置建议部分针对X86架构但它们的底层原理相通同样适用于其他CPU架构和系统希望对你有用。一、前言1. 什么是实时“实时”一词在许多应用领域中使用人们它有不同的解释并不总是正确的。人们常说如果控制系统能够对外部事件做出快速反应那么它就是实时运行的。根据这种解释如果系统速度快则系统被认为是实时的。然而“快”具有相对含义并未涵盖表征这些类型系统的主要属性。我们来看一下在自然界中生物在栖息地中的实时行为这些行为与它们的速度无关。例如乌龟对来自其栖息地的外部刺激的反应与猫对其栖息地的外部反应一样有效。虽然乌龟比猫慢很多但就绝对速度而言它要处理的事件与它可以协调的动作成正比这是任何动物在环境中生存的必要条件。相反如果生物系统所处的环境引入了速度超过其处理能力的事件其行为将不再有效动物的生存也会受到损害。比如一只苍蝇可以被苍蝇拍捕捉到一只老鼠可以被陷阱捕捉到或者一只猫可以被高速行驶的汽车撞倒。在这些例子中苍蝇拍、陷阱和汽车代表了动物的异常和异常事件超出了它们的实时能力范围可能严重危及它们的生存。前面的例子表明实时并没有人们想象的那样快而是与系统运行的环境严格相关。实时系统是必须在设置的截止时间内对环境中的事件做出反应的系统否则会产生严重的后果。再比如船舶的制导系统可能看起来是一个非实时系统因为它的速度很低而且通常有“足够”的时间大约几分钟来做出控制决定。尽管如此根据我们的定义它实际上是一个实时系统。2. 实时分类根据错过截止时间产生的后果实时任务可以分为三类硬实时(Hard real time system)如果在截止时间之后产生结果可能对受控系统造成灾难性后果则该任务是硬实时任务。硬任务的例子可以在安全关键系统中找到并且通常与传感、驱动和控制活动有关例如汽车安全气囊的检测与控制反导弹系统要求硬实时。反导弹系统由一系列硬实时任务组成。反导系统必须首先探测所有来袭导弹正确定位反导炮然后在导弹来袭之前将其摧毁。所有这些任务本质上都是硬实时的如果反导弹系统有任何一个任务失败都将无法成功拦截来袭导弹。强实时(Firm real time system)如果在截止日期之后产生结果对系统无用但不会造成任何损害则该任务是强实时任务。在网络应用程序和多媒体系统中找到在这些系统中跳过一个数据包或一个视频帧比长时间延迟处理更重要。因此它们包括以下内容视频播放音/视频编解码中没有在设置的码率时序范围内执行完产生结果都是无用的丢弃即可继续下一轮读取在线图像处理软实时(Soft real time system)如果实时任务在截止日期之后产生结果仍然对系统有用尽管会导致性能下降则该任务是软实时任务。软任务通常与系统-用户交互有关有点延迟什么的并不影响只是体验稍差点。因此它们包括用户界面的命令解释器处理来自键盘的输入数据在屏幕上显示消息网页浏览等3.常见的RTOS小型实时操作系统 UCOS、FreeRTOS、RT-Thread…大型实时操作系统 RT linux、VxWorks、QNX、sylixOS…4. latency和jitter硬实时系统是必须在设置的截止时间内对环境中的事件做出反应的系统。硬实时操作系统应具备的最重要特性之一是确定性、可预期性。操作系统的实时性能通常用latency或jitter来表示。事件预期发生与实际发生的时间之间的时间称为延迟(latency)实际发生的最大时间与最小时间之间的差值称为抖动(Jitter)两者均可表示实时性。根据实时性的定义延迟必须是确定的不能超过deadline否则将会产生严重的后果。当我们针对实时应用场景评估硬件和实时系统时通常可以简化为对实时性能和硬件资源的考量即对于一个应用场景实时性满足的情况下硬件性能也满足。在否决定使用一个实时系统时需要结合具体应用场景来评估该实时系统是否符合若不符合则需要考虑对现有系统优化或者更换方案。二、实时性的影响因素硬实时操作系统应具备的最重要特性之一是确定性、可预测性系统应该保证满足所有关键时序约束。然而这取决于一系列因素这些因素涉及硬件的架构特征、内核中采用的机制和策略以及用于实现应用程序的编程语言、软件设计等。1.硬件CPU架构硬件方面第一个影响调度可预测性的是处理器本身。处理器的内部特性是不确定性的第一个原因例如指令预取、流水线操作、分支预测、高速缓存存储器和直接存储器访问DMA机制。这些特性虽然改善了处理器的平均性能但它们引入了非确定性因素这些因素阻止了对最坏情况执行时间WCETWorst-caseExecutionTime的精确估计。高端CPU如I5、I7实时性不一定有低端的赛扬、atom系列的好芯片的设计本身定位就是高吞吐量而不是实时性。CacheCPU 里的 L1 Cache 或者 L2 Cache访问延时是内存的 1/15 乃至 1/100想要追求极限性能需要尽可能地多从 CPU Cache 里面拿数据减少cache miss上面的分配CPU专门对实时任务服务就是对非共享的L1 、L2 Cache的充分优化。对于L3 Cache多个cpu核与GPU共享无法避免非实时任务及GUI争抢L3 Cache对实时任务的影响。为此intel 推出了资源调配技术(Intel RDT)提供了两种能力监控和分配。Intel RDT提供了一系列分配(资源控制)能力包括缓存分配技术(Cache Allocation Technology, CAT)代码和数据优先级(Code and Data Prioritization, CDP) 以及 内存带宽分配(Memory Bandwidth Allocation, MBA)。该技术旨在通过一系列的CPU指令从而允许用户直接对每个CPU核心附加了HT技术后为每个逻辑核心的L2缓存、L3缓存LLC--Last Level Cache 以及内存带宽进行监控和分配。RDT一开始是为解决云计算的问题在云计算领域虚拟化环境中宿主机的资源包括CPU cache和内存带宽都是共享的。这带来一个问题就是如果有一个过度消耗cache的应用耗尽了L3缓存或者大量的内存带宽将无法保障其他虚拟机应用的性能。这种问题称为 noisy neighbor。同样对于我们的实时系统也是类似由于L3 Cache多核共享如果有一个过度消耗cache的非实时应用耗尽了L3缓存或者大量的内存带宽将无法保障xenomai实时应用的性能。以往虚拟化环境中解决方法是通过控制虚拟机逻辑资源(cgroup)但是调整粒度太粗并且无法控制处理器缓存这样敏感而且稀缺的资源。为此Intel推出了RDT技术。在Intel中文网站的 通过英特尔® 资源调配技术优化资源利用视频形象介绍了RDT的作用。Intel的Fenghua Yu在Linux Foundation上的演讲 Resource Allocation in Intel® Resource Director Technology 可以帮助我们快速了解这项技术。总的来说RDT让我们实现了控制处理器缓存这样敏感而且稀缺的资源对我们对实时性能提升有很大帮助(不仅限于xenomaiRTAI、PREEMPT-RT均适用)。CAT缓存分配技术Cache Alocation Technology对最后一级缓存L3 Cache实现分区用户可以通过限制每个核心能够向其中分配缓存行的LLC数量将LLC的部分分配给特定核心使用该技术可以提升实时任务Cahe命中率减少MSI延迟和抖动进而提升实时性能。不是所有intel处理器具有该功能一开始只有服务器CPU提供该支持,据笔者了解6代以后的CPU基本支持CAT。关于CAT 见github)对于大多数Linux发行版可直接安装使用该工具具体的cache分配策略可根据后面的资源隔离情况进行。sudo apt-get install intel-cmt-catTLB与cache性质一致。分支预测现代 CPU 的流水线级数非常长一般都在10级以上指令分支判断错误Branch Mispredict的时间代价昂贵。如果判断预测正确可能只需要一个时钟周期如果判断错误就还是需要10-20 左右个时钟周期来重新提取指令。如下为对同一随机组数排序与未排序情况下for循环测试数据有规律和无规律两种情况下同一段代码执行时间相差巨大。现代 CPU 的分支预测正确率已经可以在一般情况下维持在 95% 以上所以当分支存在可预测的规律的时候还是以性能测试的结果为最终的优化依据。Hyper-Threading人们对CPU的性能的追求是无止境的在CPU性能不断优化提高过程中对于单一流水线最佳情况下IPC 也只能到 1。无论做了哪些流水线层面的优化即使做到了指令执行层面的乱序执行CPU 仍然只能在一个时钟周期里面取一条指令。为使IPC1诞生了多发射Mulitple Issue和超标量Superscalar技术伴随的是每个CPU流水线上各种运算单元的增加。但是当处理器在运行一个线程执行指令代码时一方面很多时候处理器并不会使用到全部的计算能力另一方面由于CPU在代码层面运行前后依赖关系的指令会遇到各种冒险问题这样CPU部分计算能力就会处于空闲状态。为了进一步“压榨”处理器那就找没有依赖关系的指令来运行好即另一个程序。一个核可以分成几个逻辑核来执行多个控制流程这样可以进一步提高并行程度这一技术就叫超线程又称同时多线程Simultaneous Multi-Threading简称 SMT。由于超线程技术通过双份的 PC 寄存器、指令寄存器、条件码寄存器在逻辑层面伪装为2个CPU但指令译码器和ALU是公用的这就造成实时任务运行时在CPU执行层面的不确定性造成非实时线程与实时线程在同一物理核上对CPU执行单元的竞争影响实时任务实时性。电源管理与调频我们知道CPU场效应晶体管FET构成其简单示意图如下。当输入高低电平时CL被充放电假设充放电a焦耳的能量。因为CL很小这个a也十分的小几乎可以忽略不计。为了提高CPU性能不断提高处理器的时钟频率但如果我们以1GHz频率翻转这个FET则能量消耗就是a × 10^9这就不能忽略了再加上CPU中有几十亿个FET消耗的能量变得相当可观。详细的参考https://zhuanlan.zhihu.com/p/56864499为了省电让操作系统随着工作量不同动态调节CPU频率和电压。但是调频会导致CPU停顿CPU停顿时间10us~500us不等运行速度降低导致延迟增加严重影响实时性能。除了调频以外另一个严重影响实时性的是系统进入更深层次的省电睡眠状态这时的唤醒延迟长达几十毫秒。Multi-Core接收 IRQ 的 CPU 可能不是响应者休眠的 CPU在这种情况下前者必须向后者发送重新调度请求以便它恢复响应者。这通常是通过处理器间中断完成的也就是IPIIPI的发送和处理进一步增加了延迟。中断周期及测试时长最小平均最大100us 21h0.086us0.184us4.288us此外多核LLC共享NUMA架构远端内存访问等均会导致访问延迟不确定。other其他影响因素有内存、散热。提升内存频率可降低内存访问延时使用双通道内存这两个内存CPU可分别寻址、读取数据从而使内存的带宽增加一倍数据存取速度也相应增加一倍理论上内存访问延时得到缩短进而提升系统的实时性能处理器散热设计不好温度过高时会引发CPU降频保护系统运行频率降低影响实时性热设计应确保在高工作量时的温度不会引发降频。对于X86 CPU双通道内存性能是单通道内存的2. 5倍以上正确的热设计可使实时性提升1.4倍以上。2.BISOX86平台BISO需要针对实时系统进行配置。优化的BIOS设置与使用默认BISO设置的实时性能差距高达9倍。3.软件操作系统调度算法同步机制信号量类型内存管理策略通信语义和中断处理等。资源的分配隔离分配CPU专门对实时任务服务、将多余中断隔离到非实时任务CPU上分配CPU专门对实时任务服务可使L1 、L2 Cache只为实时任务服务。实时任务的设计良好的软件设计能更好的发挥实时性能。其他虚拟化、GUI等 。4. GPU硬件上GPU与CPU共享L3 Cache 因此GUI会影响实时任务的实时性。intel建议根据GUI任务的工作负载来固定GPU的运行频率且频率尽可能低。减小GPU对实时任务实时性的影响。三、优化措施原则降低不确定性提高可预期性在此基础上再提高速度降低延时。比如我们需要在确定的时间内从广州到深圳如果驾车途中会遇到多少个红绿灯有无堵车 等等有很多不确定性。但是如果我们换坐动车就比驾车更具确定性在此基础上我们提高速度换坐高铁广州到深圳的延时将变得更小。1. BIOS[x86]Disable FeaturesIntela Hyper-Threading Technology.Intel SpeedStep.Intel Speed Shift TechnologyC-States: Gfx RC6.GT PM Support.PCH Cross Throttling.PCI Express* Clock Gating.Delay Enable DMI ASPM,DMI Link ASPM Control.PCle *ASPM and SATA Aggressive LPM Support.For Skylake and Kaby Lake, also consider disabling Gfx Low Power Mode and USB Periodic SMl in BIOS.Enable FeaturesLegacy lO Low LatencyGfx FrequencySet to fixed value as low as possible according to proper workloadMemory FrequencySA GV Fixed High2. 硬件除处理器外内存方面使用双通道内存尽可能高的内存频率。散热当面针对处理器工作负载设计良好的散热结构, 否则芯片保护会强制降频频率调整CPU会停顿几十上百us。3. Linuxxenomai基于linuxxenomai作为一个小的实时核与linux共存xenomai并未提供完整的硬件管理机制许多硬件配置是linux 驱动掌管的必须让linux配置好给xenomai提供一个好的硬件环境让xenomai充分发挥其RTOS的优势主要宗旨尽可能的不让linux非实时部分影响xenomai无论是软件还是硬件。3.1 Kernel CMDLINEcpu隔离多核情况下设置内核参数 isolcpus[cpu列表],将列表中的CPU从linux内核SMP平衡和调度算法中剔除将剔除的CPU用于RT应用。如4核CPU平台将第3、4核隔离来做RT应用。CPU编号从0开始列表的表示方法有三种numA,numB,...,numN numA-numN 以及上述两种表示方法的组合numA,...,numM-numN 例如isolcpus0,3,4-7表示隔离CPU0、3、4、5、6、7.GRUB_CMDLINE_LINUXisolcpus2,3以上只是linux不会调度普通任务到CPU2和3上运行,这是基础此时还需要设置xenomai方面的CPU隔离方法一任务通过函数 pthread_attr_setaffinity_np()设置xenomai任务只在CPU3和4上调度隔离后的CPU的L1、L2缓存命中率相应的也会得到提高cpu_set_t cpus;
CPU_ZERO(cpus);
CPU_SET(2, cpus);//将线程限制在指定的cpu2上运行
CPU_SET(3, cpus);//将线程限制在指定的cpu3上运行
ret pthread_attr_setaffinity_np(tattr, sizeof(cpus), cpus);方法二向xenomai设置内核参数 supported_cpus,指定xenomai支持的CPUxenomai任务会自动放到cpu2、cpu3上运行。xenomai 内核参数 supported_cpus与linux不同 supported_cpus是一个16进制数每bit置位表示支持该CPU要支持CPU2、CPU3需要置置位bit2、bit3即 supported_cpus0x06(00000110b。GRUB_CMDLINE_LINUXisolcpus2,3 xenomai.supported_cpus0x06注linux内核参数 isolcpusCPU编号列表是基础否则若不隔离linux任务后面的xenomai设置将没任何意义。Full Dynamic Tick将CPU2、CPU3作为xenomai使用后由于xenomai调度是完全基于优先级的调度器并且我们已将linux任务从这两个cpu上剔除CPU上Tick也就没啥用了避免多余的Tick中断影响实时任务的运行需要将这两个cpu配置为Full Dynamic Tick模式即关闭tick。通过添加linux内核参数 nohz_full[cpu列表]配置。nohz_full[cpu列表]在使用 CONFIG_NO_HZ_FULLy构建的内核中才生效。GRUB_CMDLINE_LINUXisolcpus2,3 xenomai.supported_cpus0x06 nohz_full2,3为什么是linux内核参数呢双核下时间子系统中分析过每个CPU的时钟工作方式是linux初始化并配置工作模式的xenomai最后只是接管而已所以这里是通过linux内核参数配置。注意boot CPU(通常是0号CPU)会无条件的从列表中剔除。这是一个坑~start_kerel()-tick_init()-tick_nohz_init()
void __init tick_nohz_init(void)
{.......cpu smp_processor_id();if (cpumask_test_cpu(cpu, tick_nohz_full_mask)) {pr_warn(NO_HZ: Clearing %d from nohz_full range for timekeeping\n,cpu);cpumask_clear_cpu(cpu, tick_nohz_full_mask);}......
}Offload RCU callback从引导选择的CPU上卸载RCU回调处理,使用内核线程 “rcuox / N”代替通过linux内核参数 rcu_nocbs[cpu列表]指定的CPU列表设置。这对于HPC和实时工作负载很有用这样可以减少卸载RCU的CPU上操作系统抖动。rcuox / N,N表示CPU编号‘x’b是RCU-bh的b,p是RCU-preempt‘s’是RCU-sched。rcu_nocbs[cpu列表]在使用 CONFIG_RCU_NOCB_CPUy构建的内核中才生效。除此之外需要设置RCU内核线程 rcuc/n和 rcub/n线程的SCHEDFIFO优先级值RCUKTHREADPRIORCUKTHREADPRIO设置为高于最低优先级线程的优先级也就是说至少要使该优先级低于xenomai实时应用的优先级避免xenomai实时应用迁移到linux后由于优先级低于RCUKTHREAD的优先级而实时性受到影响如下配置RCUKTHREADPRIO0。General setup ---RCU Subsystem ---(0) Real-time priority to use for RCU worker threads[*] Offload RCU callback processing from boot-selected CPUs (X) No build_forced no-CBs CPUs( ) CPU 0 is a build_forced no-CBs CPU( ) All CPUs are build_forced no-CBs CPUs
GRUB_CMDLINE_LINUXisolcpus2,3 xenomai.supported_cpus0x06 nohz_full2,3 rcu_nocbs2,3中断中断隔离xenomai用户态实时应用运行时中断优先级最高CPU必须响应中断虽然有ipipe会简单将非实时设备中断挂起但是频繁的非实时设备中断产生可能引入无限延迟也会影响实时任务的运行。因此多核情况下通过内核参数 irqaffinity[cpu列表]设置linux设备中断的亲和性设置后默认由这些cpu核来处理中断。避免了非实时linux中断影响cpu2、cpu3上的实时应用将linux中断指定到cpu0、cpu1处理添加参数GRUB_CMDLINE_LINUXisolcpus2,3 xenomai.supported_cpus0x06 nohz_full2,3 rcu_nocbs2,3 irqaffinity0,1以上只是设置linux中断的affinity只能确保运行实时任务的CPU2、cpu3不会收到linux非实时设备的中断请求保证实时性。要指定cpu来处理xenomai实时设备中断需要在实时驱动代码中通过函数 xnintr_affinity()设置,绑定实时驱动中断由CPU2、CPU3处理代码如下。cpumask_t irq_affinity;...cpumask_clear(irq_affinity);cpumask_set_cpu(2, irq_affinity);cpumask_set_cpu(3, irq_affinity);...if (!cpumask_empty(irq_affinity)){xnintr_affinity(pIp-irq_handle,irq_affinity); /*设置实时设备中断的affinity*/}虽然ipipe会保证xenomai 实时中断在任何CPU都会优先处理在实时设备中断比较少的场合我觉得把linux中断与实时中断分开比较好如果实时设备中断数量较多如果隔离就会造成实时中断间相互影响中断处理的实时性这时候不指定实时中断处理CPU比较好。编写xenomai实时设备驱动程序时中断处理程序需要尽可能的短。禁用irqbanlancelinux irqbalance 用于优化中断分配它会自动收集系统数据以分析使用模式并依据系统负载状况将工作状态置于 Performance mode 或 Power-save mode。简单来说irqbalance 会将硬件中断分配到各个CPU核心上处理。处于 Performance mode 时irqbalance 会将中断尽可能均匀地分发给各个 CPU core以充分利用 CPU 多核提升性能。处于 Power-save mode 时irqbalance 会将中断集中分配给第一个 CPU以保证其它空闲 CPU 的睡眠时间降低能耗。禁用irqbanlance避免不相干中断发生在RT任务核。发行版不同配置方式不同以Ubuntu为例停止/关闭开机启动如下。systemctl stop irqbalance.service
systemctl disable irqbalance.service必要的话直接卸载irqbalance。apt-get remove irqbalancex86平台还可添加参数acpi_irq_nobalance禁用ACPI irqbalance.GRUB_CMDLINE_LINUXisolcpus2,3 xenomai.supported_cpus0x06 nohz_full2,3 rcu_nocbs2,3 irqaffinity0,1 acpi_irq_nobalance noirqbalanceintel 核显配置[x86]主要针对intel CPU的核显配置intel核显驱动模块i915内核参数如下。GRUB_CMDLINE_LINUXi915.enable_rc60 i915.enable_dc0 i915.disable_power_well0 i915.enable_execlists0 i915.powersave0nmi_watchdog[x86]NMI watchdog是Linux的开发者为了debugging而添加的特性但也能用来检测和恢复Linux kernel hang现代多核x86体系都能支持NMI watchdog。NMINon Maskable Interrupt即不可屏蔽中断之所以要使用NMI是因为NMI watchdog的监视目标是整个内核而内核可能发生在关中断同时陷入死循环的错误此时只有NMI能拯救它。Linux中有两种NMI watchdog分别是I/O APIC watchdognmiwatchdog1和Local APIC watchdognmiwatchdog2。它们的触发机制不同但触发NMI之后的操作是几乎一样的。一旦开启了I/O APIC watchdognmi_watchdog1那么每个CPU对应的Local APIC的LINT0线都关联到NMI这样每个CPU将周期性地接到NMI接到中断的CPU立即处理NMI用来悄悄监视系统的运行。如果系统正常它啥事都不做仅仅是更改 一些时间计数如果系统不正常默认5秒没有任何普通外部中断那它就闲不住了会立马跳出来且中止之前程序的运行。该出手时就出手。避免周期中断的NMI watchdog影响xenomai实时性需要关闭NMI watchdog传递内核参数 nmi_watchdog0.GRUB_CMDLINE_LINUXisolcpus2,3 xenomai.supported_cpus0x06 nohz_full2,3 rcu_nocbs2,3 irqaffinity0,1 acpi_irq_nobalance noirqbalance i915.enable_rc60 i915.enable_dc0 i915.disable_power_well0 i915.enable_execlists0 i915.powersave0 nmi_watchdog0nosoftlockuplinux内核参数禁用 soft-lockup检测器。GRUB_CMDLINE_LINUXisolcpus2,3 xenomai.supported_cpus0x06 nohz_full2,3 rcu_nocbs2,3 irqaffinity0,1 acpi_irq_nobalance noirqbalance i915.enable_rc60 i915.enable_dc0 i915.disable_power_well0 i915.enable_execlists0 i915.powersave0 nmi_watchdog0 nosoftlockupCPU特性[x86]intel处理器相关内核参数nosmapnohalt。告诉内核在空闲时,不要使用省电功能PALHALTLIGHT。这增加了功耗。但它减少了中断唤醒延迟这可以提高某些环境下的性能例如联网服务器或实时系统。mceignore_ce,忽略machine checkerrors (MCE).idlepoll,不要使用HLT在空闲循环中进行节电而是轮询以重新安排事件。这将使CPU消耗更多的功率但对于在多处理器基准测试中获得稍微更好的性能可能很有用。它还使使用性能计数器的某些性能分析更加准确。clocksourcetsc tscreliable,指定tsc作为系统clocksource.intel_idle.max_cstate0 禁用intelidle并回退到acpiidle.processor.max_cstate0intel.max_cstate0processor_idle.max_cstate0 限制睡眠状态c-state。GRUB_CMDLINE_LINUXisolcpus2,3 xenomai.supported_cpus0x06 nohz_full2,3 rcu_nocbs2,3 irqaffinity0,1 acpi_irq_nobalance noirqbalance i915.enable_rc60 i915.enable_dc0 i915.disable_power_well0 i915.enable_execlists0 nmi_watchdog0 nosoftlockup processor.max_cstate0 intel.max_cstate0 processor_idle.max_cstate0 intel_idle.max_cstate0 clocksourcetsc tscreliable nmi_watchdog0 nosoftlockup intel_pstatedisable idlepoll nohalt nosmap mceignore_ce3.2 内核构建配置系统构建时除以上提到的配置外CONFIGNOHZFULL y、CONFIGRCUNOCBCPUy、RCUKTHREADPRIO0其他实时性相关配置如下CONFIGMIGRATIONn、CONFIGMCORE2y[x86]、CONFIGPREEMPTy、ACPIPROCESSOR n[x86]、CONFIGCPUFREQ n、CONFIGCPUIDLE n经过以上配置后可以使用latency测试观察配置前后的变化。关于latency需要注意的是测试timer-IRQ的latency时即用 latency-t2命令来测试时xenomai默认使用cpu0的timer上面提到boot CPU(通常是0号CPU)会无条件的从 nohz_full[cpu列表]列表中剔除所以 latency-t2测试时你会发现没什么变化还可能会变差了(最坏情况差不多一致平均值变大了)另外我们将linux中断affinity全都设置为CPU0处理这些中断或多或少也会影响timer-IRQ的latency。2021.5添加-- 最近发现xenomai内核定时器affinity为cpu0的问题已被社区修复。四、软件方面使用静态编译语言编写高性能的代码尽量让分支有规律性使用likely()/unlikely()或编写无分支代码利用cache局部性原理防止伪共享合理分配任务优先级等待驱动程序中断处理尽可能短等等五、优化结果对比笔者对以上各个条件配置前后对比过实时性改善效果均有不同程度的优化效果大家有兴趣也可自行测试。以下结果基于 i5-7200U 8GB单通道DDR4,64GB emmc5.0未使用RDT技术。1-3 在已裁剪桌面下压力加了内存。1. 原始性能测试。只使用了xenomaiCONFIGMIGRATIONn、CONFIGMCORE2y[x86]、CONFIGPREEMPTy、ACPIPROCESSOR n[x86]、CONFIGCPUFREQ n、CONFIGCPUIDLE n。优化项配置与否BISONOLinuxNOFull Dynamic TickNOOffload RCU callbackNOFull desktopNOstress-c 10 -m 42. 优化BIOS设置。优化项配置与否BISOYESLinuxNOFull Dynamic TickNOOffload RCU callbackNOFull desktopNOstress-c 10 -m 43. Linux配置优化。优化项配置与否BISOYESLinuxYESFull Dynamic TickYESOffload RCU callbackYESFull desktopNOstress-c 10 -m 44-6 未添加内存压力4. 裁剪桌面。保留完整Ubuntu桌面前且经所有配置优化项配置与否BISOYESLinuxYESFull Dynamic TickYESOffload RCU callbackYESFull desktopNO—YESstress-c 10裁剪桌面后裁剪前后对比5. Full Dynamic Tick启用前后对比裁剪桌面后配置cpu0未启用Full Dynamic Tickcpu1启用Full Dynamic Tick加压与未加压对比。优化项配置与否BISOYESLinuxYESFull Dynamic TickCPU0:NO;CPU1:YESOffload RCU callbackCPU0NO;CPU1:NOFull desktopNOstress-c 10对比cpu0与cpu1最坏情况没有改善但4us以上的latency改善明显。6.桌面、rcu、tick前后比对带桌面、未启用rcunocb、未启用Full Dynamic Tick--------裁桌面、启用rcunocb、启用Full Dynamic Tick优化项配置与否BISOYES -- YESLinuxYES -- YESFull Dynamic TickNO -- YESOffload RCU callbackNO--YESFull desktopYES - NOstress-c 107.总对比优化项配置与否BISONO -- YESLinuxNO -- YESFull Dynamic TickNO -- YESOffload RCU callbackNO -- YESFull desktopYES -- NOstress-c 10 -m 4六、实时性能测试下面直接给出最终的应用空间任务Jitter测试结果使用的环境如下CPUintel 赛扬 3865U1.8GHZKernelLinux 4.4.200操作系统Ubuntu 16.04内存8GB DDR3-1600 双通道存储64GB EMMC测试条件在stress压力下测试同时一个QT应用程序绘制2维曲线图QT CPU占用率99%。stress -c 10 -m 4测试时间211:04:55 测试命令latency -t0 -p 100 -P 99 -h -g result.txt测试应用空间程序优先级99任务周期100us测试结果输出到文件result.txt。经过接近10天的测试后文件result.txt中latency分布结果如下# 211:04:55 (periodic user-mode task, 100 us period, priority 99)
# ----lat min|----lat avg|----lat max|-overrun|---msw|
# 0.343| 1.078| 23.110| 0| 0|
# Xenomai version: Xenomai/cobalt v3.1
# Linux 4.4.200-xeno
......
# I-pipe releagese #20 detected
# Cobalt core 3.1 detected
# Compiler: gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.12)
# Build args: --enable-smp --enable-pshared --enable-tls
PKG_CONFIG_PATH:/usr/xenomai/lib/pkgconfig:/usr/xenomai/lib/pkgconfig0 1
0.5 1599357037
1.5 1621130106
2.5 56618753
3.5 4386985
4.5 3848531
5.5 3556704
6.5 3353649
7.5 3033218
8.5 2560133
9.5 2035075
10.5 1516866
11.5 1038989
12.5 680815
13.5 417124
14.5 224296
15.5 115165
16.5 58075
17.5 27669
18.5 11648
19.5 4648
20.5 1646
21.5 467
22.5 38
23.5 1其中第一列数据表示latency的值第二列表示该值与上一个值之间这个范围的latency出现的次数最小0.343us平均latency 1.078us最大23.110us。可见xenomai的实时性还是挺不错的。以上只是xenomai应用空间任务的实时性表现如果使用内核空间任务会更好。当然这只能说明操作系统能提供的实时性能具体的还要看应用程序的设计等。此外该测试基于X86平台X86处理器的实时性与BIOS有很大关系通常BIOS配置CPU具有更高的吞吐量例如超线程、电源管理、CPU频率等毕竟BIOS不是普通开发者能接触到的如果能让BIOS对CPU针对实时系统配置的话实时性会更好。如下图所示平均抖动几乎在100纳秒以内。相关链接https://www.intel.com/content/dam/www/public/us/en/documents/white-papers/cache-allocation-technology-white-paper.pdf
