7

您好，我使用 RT-Patch 修补了 Linux 内核，并使用监控延迟的 Cyclinctest 对其进行了测试。内核做得不好，也不比香草内核好。 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 内核中是否足以提供上面所需的内容？有人提示吗？

4

1 回答 1

11

要在 PREEMPT_RT 下获得硬实时性能，必须做很多事情。以下是我所知道的事情。标有星号的条目适用于您当前的职位。

  • 用 PREEMPT_RT 修补内核（就像你已经做过的那样），并启用 CONFIG_PREEMPT_RT_FULL（它曾经被称为 CONFIG_PREEMPT_RT，因为你正确地派生了）。
  • 禁用处理器频率缩放（通过将其从内核配置中删除或通过更改调控器或其设置）。(*)
    • 推理：改变一个核心的频率需要一段时间，在此期间核心没有有用的工作。这会导致高延迟。
    • 要删除它，请查看内核设置中的 ACPI 选项。
    • 如果您不想从内核中删除此功能，可以将 cpufreq 调控器设置为“性能”以将其锁定在最高频率。
  • 禁用深度 CPU 睡眠状态
    • 推理：与切换频率一样，将 CPU 从深度睡眠中唤醒可能需要一段时间。
    • Cyclictest 为您执行此操作（查找 /dev/cpu_dma_latency 以了解如何在您的应用程序中执行此操作）。
    • 或者，您可以禁用内核中的“cpuidle”基础设施，以防止这种情况发生。
  • 为实时线程设置高优先级，50以上（最好是99）（*）
    • 推理：您需要将优先级置于内核的大部分之上——大部分 PREEMPT_RT 内核（包括 IRQ）以 50 的优先级运行。
    • 对于循环测试，您可以使用“-p#”选项执行此操作，例如“-p99”。
  • 您的应用程序的内存必须被锁定。(*)
    • 推理：如果您的应用程序的内存没有被锁定，那么内核可能需要在执行期间重新映射您的应用程序的一些地址空间，从而触发高延迟。
    • 对于循环测试，这可以使用“-m”选项来完成。
    • 要在您自己的应用程序中执行此操作，请参阅RT_PREEMPT howto。
  • 如果加载了 nvidia、nouveau 和 i915 模块（或首先不构建它们），则必须卸载它们 (*)
    • 推理：已知这些会导致高延迟。希望您在实时系统上不需要它们：P
  • 您的实时任务必须编码为实时
    • 例如，您不能通过 malloc() 进行文件访问或动态内存分配。许多系统调用是禁止的（很难找到哪些是可以接受的，IMO）。
    • 和许多实时音频应用程序一样，循环测试大多已经为实时操作编码。但是，您确实需要使用“-n”标志运行它，否则它将不会使用实时安全的睡眠调用。

循环测试的实际执行至少应该有以下一组参数：

sudo cyclictest -p99 -m -n
于 2013-07-25T02:09:15.253 回答