6.4.0我正在使用Linux内核和补丁定制Linux实时系统patch-6.4.6-rt8。运行时make menuconfig，应该关闭哪些配置以提高实时性能？系统主要作为机械臂控制器。
此时的系统，用来cyclictest测试时延效果，发现抖动有点高，最小值为2，最大值为39。
# cyclictest -t1 -p 80 -n -i 1000 -l 10000
# /dev/cpu_dma_latency set to 0us
policy: fifo: loadavg: 0.27 0.07 0.02 1/122 627
T: 0 ( 577) P:80 I:1000 C: 10000 Min: 2 Act: 2 Avg: 2 Max: 39
#
答案1
一般来说，没有。系统的实时性不是由它所具有的功能决定的，而是由您是否应用 -rt 补丁集以及您是否设计和运行需要适当实时任务的软件决定。打了 rt 补丁的内核中唯一会增加延迟的就是一个驱动程序，它有一个很长的关键部分，在该部分禁用中断，但是，对于大多数设备来说，这可能不会与内核驱动程序一起运行，而且，删除该驱动程序将禁用正在使用的硬件组件。所以，我认为这不是一个选择。
由于您的句柄是“ABeginner”，因此我会向自己提出广泛的建议，即您不应该从头开始构建自己的内核配置，而是使用oldconfigLinux 发行版中的 -rt 内核，或者如果它提供了一个，请使用发行版提供的 -rt 内核。
此时的系统，使用cyclotest测试延迟效果，发现抖动有点高，最小值为2，最大值为39。
在现代 x86_64 或 aarch64 系统的范围内，这些数字看起来不错。你说“抖动有点高”；但作为一名参与实时信号处理的工程师：“有点高”其实并不是什么事情。您的最大延迟要么可以，要么不行。这就是实时系统的意义所在。
因此，要么您得出 39 µs 足够好的结论（而且确实可能是这样！例如，对于与音频相关的任何内容；或者对于机器紧急停止控制器来说可能不够），或者不是 –但然后我会问你为什么要进行nanosleep准确性测试（例如，而不是处理内核空间中的硬件计时器中断）。我想这真的会有点远——它将涉及到弄清楚你将哪些核心固定到你的实时应用程序进程（如果有任何这样的进程，但话又说回来，你正在测量 userland nanosleep，所以必须有一个） ，它们如何与您的事件源相关，以及事件源（假设它不仅仅是一个计时器）和对事件进行操作的系统之间的链中的内容。因此，遗憾的是，改进实时系统的所有困难都适用于 Linux，就像适用于 FreeRTOS 等更简单的操作系统一样。