你好,我用 RT-Patch 修补了 Linux 内核,并用监控延迟的 Cyclinctest 对其进行了测试。内核并不好,也不比 Vanilla 内核好。 https://rt.wiki.kernel.org/index.php/Cyclictest
我检查了 RT 的 uname,看起来不错。
所以我检查了 cyclinctest 的要求,它指出我必须确保在内核配置中配置以下内容:
CONFIG_PREEMPT_RT=y
CONFIG_WAKEUP_TIMING=y
CONFIG_LATENCY_TRACE=y
CONFIG_CRITICAL_PREEMPT_TIMING=y
CONFIG_CRITICAL_IRQSOFF_TIMING=y
现在出现的问题是配置不包含此类条目。也许有旧的,它们可能会在新的补丁版本 (3.8.14) 中重命名?
我找到了如下选项:
CONFIG_PREEMPT_RT_FULL=y
CONFIG_PREEMPT=y
CONFIG_PREEMPT_RT_BASE=y
CONFIG_HIGH_RES_TIMERS=y
3.x 内核是否足以提供上述要求?有人提示吗?
最佳答案
要在 PREEMPT_RT 下获得硬实时性能,必须做很多工作。以下是我所知道的事情。标有星号的条目适用于您当前的职位。
- 用 PREEMPT_RT 修补内核(就像您已经做的那样),并启用 CONFIG_PREEMPT_RT_FULL(它曾经被称为 CONFIG_PREEMPT_RT,正如您正确推导的那样)。
- 禁用处理器频率缩放(通过将其从内核配置中删除或通过更改调控器或其设置)。 (*)
- 推理:更改内核的频率需要一段时间,在此期间内核不会做任何有用的工作。这会导致高延迟。
- 要删除它,请查看内核设置中的 ACPI 选项。
- 如果您不想从内核中删除此功能,您可以将 cpufreq 调控器设置为“性能”以将其锁定在最高频率。
- 禁用深度 CPU sleep 状态
- 推理:就像切换频率一样,将 CPU 从深度 sleep 中唤醒可能需要一段时间。
- Cyclictest 为您做这件事(查看/dev/cpu_dma_latency 以了解如何在您的应用程序中做这件事)。
- 或者,您可以禁用内核中的“cpuidle”基础设施以防止这种情况发生。
- 为实时线程设置高优先级,高于 50(最好是 99)(*)
- 推理:您需要将您的优先级置于大多数内核之上——大部分 PREEMPT_RT 内核(包括 IRQ)以 50 的优先级运行。
- 对于循环测试,您可以使用“-p#”选项来执行此操作,例如“-p99”。
- 您的应用程序的内存必须被锁定。 (*)
- 推理:如果您的应用程序的内存未锁定,则内核可能需要在执行期间重新映射您的应用程序的某些地址空间,从而引发高延迟。
- 对于循环测试,这可以通过“-m”选项完成。
- 要在您自己的应用程序中执行此操作,请参阅 the RT_PREEMPT howto .
- 如果加载了 nvidia、nouveau 和 i915 模块,则必须卸载它们(或者首先不构建它们)(*)
- 推理:已知这些会导致高延迟。希望你不需要在实时系统上使用它们 :P
- 您的实时任务必须编码为实时的
- 例如,您不能通过 malloc() 进行文件访问或动态内存分配。许多系统调用都是禁止的(很难找到哪些是可以接受的,IMO)。
- cyclictest 大部分已经针对实时操作进行了编码,许多实时音频应用程序也是如此。但是,您确实需要使用“-n”标志运行它,否则它不会使用实时安全的 sleep 调用。
cyclictest的实际执行至少应该有如下一组参数:
sudo cyclictest -p99 -m -n
关于linux - RT 修补的 Linux 内核的循环测试,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/17812548/