企业官网建设流程全解析

Linux 实时内核（PREEMPT_RT）配置完全指南：影响最坏延迟的 CONFIG 选项详解

【免费下载链接】linuxLinux kernel source tree项目地址: https://gitcode.com/GitHub_Trending/li/linux

本文档面向系统集成工程师，系统梳理了 Linux 实时内核（PREEMPT_RT）中所有会显著影响**最坏情况延迟（worst-case latency）**的内核配置选项：从 CPU 频率调节器、C 状态（C-states）、EFI 运行时服务，到抢占模型、无时钟（tickless）模式、跟踪器与内核调试选项，逐一给出期望值、严重等级、禁用理由与替代方案。读完本文，你将能够依据系统实时需求，制定并验证一套可复现的实时内核 .config 基线，并理解每个选项背后的源码实现逻辑。

概述：实时内核配置的目标

与追求"尽可能快"的通用内核不同，实时内核的核心指标是延迟的可预测性与有界性——即最坏情况下任务仍能在截止时间（deadline）内得到响应。因此，实时内核配置的全部工作可以归结为一句话：识别并消除所有可能引入非确定性延迟（jitter）或延迟尖峰（latency spike）的机制。

正如本指南结尾总结的，并不存在"放之四海而皆准"的实时内核配置方案。集成工程师必须从系统的实时需求出发，综合考虑硬件、内核与用户空间三个层面，任何一个错误的配置都可能制造出一个"在错误的时间点出现且对实时系统是灾难性的"新最大延迟。

仓库中的源码直接印证了实时内核的本质。在 kernel/Kconfig.preempt 中，CONFIG_PREEMPT_RT的帮助文本说明：该选项通过将各种锁原语（spinlock、rwlock 等）替换为可抢占的、带优先级继承的变体、强制中断线程化（interrupt threading）、并引入分解长不可抢占区间的机制，使内核除极底层关键路径（入口代码、调度器、底层中断处理）外全部可抢占，将大多数执行上下文纳入调度器控制之下。

下文按严重等级与主题分节给出每个选项的配置指引。严重等级定义如下：

CPU 频率调节器（CPUFreq Governors）

CONFIG_CPU_FREQ：期望启用，严重等级 high

CPU 频率调节子系统确保处理器能够运行在其支持的最大频率上。虽然通常由 bootloader 在启动时负责将 CPU 时钟设置为最高速，但部分 bootloader 并不会这样做，因此建议保持此选项启用。

注意：实时内核的意义不在于"尽可能快"，但实时需求可能要求 CPU 运行在某个特定频率上。

从源码看，drivers/cpufreq/Kconfig 中CONFIG_CPU_FREQ帮助文本指出：该选项允许在运行中动态改变 CPU 时钟速度，但驱动本身不会自动调频，需要启用动态 governor（或使用用户空间工具）。

CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE：期望启用，严重等级 high

实时工作负载期望在执行期间 CPU 频率恒定不变。将performancegovernor 设为默认，是从纯内核配置层面实现这一点的最简便方式。该 governor 将频率静态设定为 CPU 支持的最高频率（见 drivers/cpufreq/Kconfig）。

但这并非绝对规则：某些场景可能出于散热封装或其他需求将 CPU 降频运行。关键原则是——频率一旦设定，就应保持不变。

非 performance 频率调节器：期望禁用，严重等级 medium

为保证系统延迟测量的可复现性，应尽可能禁用除PERFORMANCE之外的 CPU 频率调节器。这避免了未知用户空间任务在系统运行期间隐式或显式地切换 governor，从而改变延迟行为。

若无法禁用其他 governor，则应选用能保持 CPU 频率固定的调节器，例如：

• CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE：适用于由用户空间在系统初始化期间设定稳定频率的场景；
• CONFIG_CPU_FREQ_DEFAULT_GOV_POWERSAVE：适用于希望保持低 CPU 频率的场景（该 governor 将频率静态设定为最低值，见 drivers/cpufreq/Kconfig）。

ONDEMANDgovernor 绝不应在实时系统上启用——其频率变化依赖于工作负载行为，会显著破坏确定性。

源码佐证：在 drivers/cpufreq/Kconfig 的"Default CPUFreq governor"选择菜单中可以看到，默认 governor 会根据平台自动选择（如 ARM/ARM64 或 Intel/AMD pstate 平台默认schedutil，其余默认performance）。实时系统集成时需显式覆盖为performance（或userspace固定频率方案）。

更多信息参见 cpufreq 文档。

CONFIG_CPU_IDLE：期望启用，严重等级 info

CPU 空闲状态（C-states）允许处理器在空闲期间进入低功耗模式。但非常深的 C 状态可能需要冲刷 CPU 缓存、降低或关闭时钟，虽能降低功耗，却会增加进入/退出这些状态的延迟。

虽然禁用此选项可消除 cpuidle 相关延迟，但这样做可能显著影响硬件寿命、保修与散热表现。推荐的做法是将最大 C 状态限制到 C1。对 ACPI 平台，可使用以下内核启动参数：

processor.max_cstate=1

根据工作负载的延迟要求，较深的 C 状态也可能是可接受的。对 ACPI 平台，可使用cpupower idle-info命令检查可用的空闲状态。

补充：仓库中 cpupower 工具位于 tools/power/cpupower，它是检查与配置 CPU 空闲状态、频率状态的官方用户空间工具。

更多信息参见：

• cpuidle 文档
• PM 子系统文档索引

CONFIG_DRM：期望禁用，严重等级 info

GPU 加速工作负载可能与 CPU 共享系统资源，包括末级缓存（LLC）与内存带宽。现代集成 GPU 往往以牺牲 CPU 确定性为代价优化图形性能。

受影响的典型平台包括：

• 带集成显卡的 Intel 处理器（Gen9 及之后）
• 带 Radeon Graphics 的 AMD APU
• Xilinx Zynq UltraScale+ MPSoC EG/EV 系列

如果图形工作负载必须与实时任务并行运行，用户必须使用glmark2等工具进行充分的压力测试，同时测量整体系统延迟。

补充说明：实时与图形并存的挑战还涉及资源竞争控制。仓库中的 resctrl 文档 描述了通过资源控制（如 LLC 与内存带宽分配）来隔离实时负载与图形负载的方法；实时硬件考量文档（"Regarding hardware" 一节）则从硬件选型角度给出了分析框架。

CONFIG_EFI_DISABLE_RUNTIME：期望启用，严重等级 medium

EFI 是多种架构的标准引导与固件接口。EFI 运行时服务向内核提供回调函数，例如CONFIG_EFI_VARS*或CONFIG_RTC_DRV_EFI会调用 EFI 更新 EFI 变量。调用 EFI 意味着调用固件回调，在此类调用期间，系统可能无法响应中断，因而无法执行上下文切换——这会给实时系统带来显著的延迟尖峰。

CONFIG_PREEMPT_RT会默认启用此选项。源码印证了这一点：drivers/firmware/efi/Kconfig 中CONFIG_EFI_DISABLE_RUNTIME的默认值为default y if PREEMPT_RT，其帮助文本说明：测量表明某些 EFI 函数调用耗时过长，会产生对实时内核不利的大延迟。该默认行为可通过efi=runtime启动参数覆盖。

若在构建时手动禁用了此选项，可在启动时使用以下参数禁用 EFI 运行时服务：

efi=noruntime

另一种折中方案是：将efi_runtimeworkqueue 的 CPU 亲和性限制到某个 housekeeping CPU（例如 CPU #0），并将 RT 任务固定到其他 CPU 区间，从而把 EFI 运行时服务调用限制在隔离的 CPU 上。参见 workqueue 文档。

CONFIG_NO_HZ/CONFIG_NO_HZ_FULL：期望禁用，严重等级 medium

无时钟（tickless）模式会因额外的统计与状态簿记工作而增加内核到用户空间的转换延迟。按实时工作负载类型给出指引：

• 周期性工作负载（例如每 100 µs 执行一次的控制循环）：应避免NO_HZ模式，一致的周期性内核 tick 更可取；
• 计算密集型工作负载（例如长时间的用户空间执行）：NO_HZ_FULL可能有利，此时应将内核 housekeeping 卸载到专用 CPU，并隔离计算核心。

背景补充：即使不使用 tickless 模式，定时器中断频率本身也会影响实时响应。仓库中的 kernel/Kconfig.hz 提供 100/250/300/1000 Hz 四档选择，其中HZ_1000是桌面及需要快速交互响应的系统的首选；而HZ_100更适合服务器与大规模 SMP/NUMA 系统（tick 在 SMP 下会产生 NR_CPUS × HZ 次中断/秒）。文档虽未对此强制规定，但从源码结构看，实时系统通常需要在此与 NO_HZ 之间根据工作负载形态做权衡。

更多信息参见 no_hz 文档。

CONFIG_PREEMPT_RT：期望启用，严重等级fatal

此选项必须启用，否则构建出的内核不是完全可抢占的，也就不具备实时能力。它是整个实时内核的基石。

从 kernel/Kconfig.preempt 的定义可以深入理解其实现机制：

• 依赖EXPERT && ARCH_SUPPORTS_RT（需在支持实时特性的架构上、且开放 EXPERT 菜单时才能选择）；
• 将 spinlock、rwlock 等锁原语替换为可抢占的、优先级继承感知的变体；
• 强制中断线程化（interrupt threading），把中断处理纳入调度器管理；
• 引入机制分解长的不可抢占区间，使除入口代码、调度器、底层中断处理外的内核代码全部可抢占。

该选项与抢占模型菜单中的其他选项（PREEMPT_NONE、PREEMPT_VOLUNTARY、PREEMPT、PREEMPT_LAZY）互斥，共同构成"Preemption Model"选择（见 kernel/Kconfig.preempt）。此外，同文件中CONFIG_PREEMPT_DYNAMIC（kernel/Kconfig.preempt）允许在启动时通过内核命令行参数覆盖编译期抢占模型，主要用于发行版用单一内核二进制服务多种场景——但对于要求严格实时保证的系统，仍建议编译期直接选定PREEMPT_RT。

CONFIG_TRACING（及跟踪选项）：期望启用，严重等级 info

强烈建议发布带跟踪支持（但不在运行期主动启用）的内核，以便在出现延迟问题时提取更多诊断信息。不过，部分跟踪器仅仅因为被编译启用就会引入延迟开销。

警告：在生产实时内核运行期间，不应使用跟踪器或跟踪事件，它们会带来可观的额外开销并劣化系统延迟。

CONFIG_IRQSOFF_TRACER与CONFIG_PREEMPT_TRACER：期望禁用，严重等级 high

这两个跟踪器即使在跟踪未激活时也会带来可测量的延迟开销，因此在实时内核中应被禁用。这一警告同样适用于任何此类"静态开销"型跟踪器——判断标准是：编译启用即产生运行时成本。

内核调试选项（Kernel Debug Options）

大多数内核调试选项会引入运行时开销，从而提高最坏情况延迟。

重要建议：在开发与早期测试阶段，应长时间地以 lockdep（CONFIG_PROVE_LOCKING）及其他内核调试选项运行实时工作负载与外围设备。此类负载可能触发 Linux 实时内核内部开发期间未触达的代码路径，从而帮助发现锁及其他类型的内核缺陷。也就是说：开发阶段开启调试，生产阶段关闭调试。

CONFIG_DEBUG_ATOMIC_SLEEP：期望允许

此健全性检查（sanity check）能以可容忍的延迟代价捕获常见的内核编程错误。注意它也会增加整体调度开销，因为每次might_sleep()都可能引发一次上下文切换。定义位于 lib/Kconfig.debug。

CONFIG_DEBUG_BUGVERBOSE与CONFIG_DEBUG_INFO*：期望允许

这些选项会增加内核镜像体积，但对延迟没有影响。它们对于有意义的 BUG 日志、崩溃转储（crash dump）与性能剖析（profiling）不可或缺，因此建议保留。对应定义见 lib/Kconfig.debug。

CONFIG_DEBUG_FS：期望允许

只要保证生产运行期间不访问 debugfs，将其包含在实时内核中是安全的。定义见 lib/Kconfig.debug。

CONFIG_DEBUG_KERNEL：期望允许

这是允许启用各种调试特性的元选项（meta-option），本身没有运行时影响，但要警惕它可能隐式启用的其他调试特性。定义见 lib/Kconfig.debug。

CONFIG_LOCKUP_DETECTOR：期望禁用，严重等级 high

lockup 检测器会创建每几秒执行一次、运行在硬中断（hard-IRQ）上下文的内核定时器回调——即使在实时内核上也是如此。这些周期性中断可能造成延迟尖峰。应改用硬件看门狗，它能提供类似功能而不引入软件延迟。定义见 lib/Kconfig.debug。

CONFIG_PROVE_LOCKING（lockdep）：期望禁用，严重等级 high

证明所有内核锁的正确性会带来可观的额外开销，显著增加最坏情况延迟。因此生产实时内核必须禁用。不过如前所述，在开发与早期测试阶段强烈建议启用它来排查锁缺陷。定义见 lib/Kconfig.debug。

配置速查表

将上文整理为一张可快速对照的速查表，方便集成工程师在裁剪 .config 时逐项核对：

总结：从实时需求出发做系统性配置

实时内核配置不存在"一刀切"的银弹。正确的路径是：

1. 明确系统的实时需求（最坏延迟目标、工作负载形态是周期性还是计算密集型）；
2. 逐项审视硬件、内核与用户空间三个层面的特性与功能（可对照本文速查表）；
3. 建立并约束系统的最大延迟——所有组件都必须被正确配置。

任何错误的实时内核配置，都可能制造出一个在错误时间出现、对实时系统延迟是灾难性的新最大延迟。因此，配置完成后务必结合真实的实时工作负载做长时间压力验证（开发期保留 lockdep 等调试手段，生产期切换到最小化配置）。

参考资源

• 本文档原始出处：Documentation/core-api/real-time/kernel-configuration.rst
• 抢占模型与CONFIG_PREEMPT_RT定义：kernel/Kconfig.preempt
• CPUFreq 子系统与 governor 定义：drivers/cpufreq/Kconfig
• 定时器中断频率选择：kernel/Kconfig.hz
• CONFIG_EFI_DISABLE_RUNTIME定义：drivers/firmware/efi/Kconfig
• 调试选项定义：lib/Kconfig.debug
• 内核启动参数参考（processor.max_cstate、efi=noruntime等）：kernel-parameters 文档
• 实时内核系列文档：硬件考量 hardware.rst、实时理论 theory.rst、与普通内核的差异 differences.rst
• cpufreq / cpuidle / no_hz 子系统文档：cpufreq.rst、cpuidle.rst、no_hz.rst
• 资源控制（LLC/内存带宽隔离）：resctrl.rst

【免费下载链接】linuxLinux kernel source tree项目地址: https://gitcode.com/GitHub_Trending/li/linux