Linuxeden开源社区一个新补丁发布到 Linux 内核邮件列表，旨在解决现代 Intel Xeon 服务器平台上的高唤醒延迟问题。对于 Sapphire Rapids 及更新的平台，使用 Linux 菜单管理器和 NOHZ_FULL 配置时，”过高的”唤醒延迟会负面影响 Xeon CPU 在延迟敏感型工作负载中的表现，但一个 16 行的补丁旨在改善这一情况。也就是说，只需修改一行实际代码，其余都是代码注释。
来自 Wind River 的云工程师 Ionut Nechita 一直在努力解决自 Sapphire Rapids 以来现代 Intel Xeon 平台上的高唤醒延迟问题，并且这一问题仍然存在于最新一代的 Granite Rapids 处理器上。使用菜单管理器和 NOHZ_FULL 内核构建时，约 150 微秒的唤醒延迟会损害延迟敏感型应用的性能，相比之下，Ice Lake 和 Skylake Xeons 的延迟为 12~21 微秒。
菜单管理器代码中发现一个问题，导致非常深的包 C 状态，由于 DDR5 电源管理开销、现代 Xeon CPU 的每瓦片电源门控、CXL 链路恢复以及现代服务器其他复杂性，这对于现代 Xeon 服务器来说成本过高。
建议的改进是在菜单管理器代码中简单地增加 25%的安全边际，以防止“过度”深的状态，同时不会过多影响电源效率。25%的安全边际旨在减少选择过于浅的状态的风险，同时避免选择不必要深的的状态。
“当计时器已经停止且预测的空闲时长较短（<TICK_NSEC）时，原始代码直接使用 next_timer_ns。这在具有高 C 状态退出延迟的平台上是过于保守的。
在 Intel 服务器平台（2022 年及以后），当实际空闲时长远短于 next_timer_ns 时，这会导致过高的唤醒延迟（约 150 微秒），因为管理器选择了包 C 状态（PC6），而较浅的状态更为合适。”
将预测增加 25%的安全余量，而不是直接使用 next_timer_ns，同时仍然限制在 next_timer_ns 以避免选择不必要的深度状态。
测试显示这将在受影响的平台上将 qperf 延迟从 151 微秒减少到约 30 微秒，同时保持良好的电源效率。具有快速 C 状态转换的平台（Ice Lake：12 微秒，Skylake：21 微秒）影响最小。”
为菜单管理员增加 25%安全余量的基准测试结果不言自明：
在 Sapphire Rapids 上使用 qperf tcp_lat 进行测试：
– 之前：151 微秒平均延迟
– 之后：平均延迟约 30 微秒
– 改进：延迟减少 5 倍在 Ice Lake 和 Skylake 上测试显示影响极小：
– Ice Lake：12 微秒 → 12 微秒（无回归）
– Skylake: 21us → 21us (无回归)功耗测试显示，在混合工作负载期间，封装功耗差异小于 1%，在测量噪声范围内。
在 Xeon Sapphire Rapids 上报告了 5 倍的延迟降低。这同样应该有利于更新的 Xeon CPU，但作为初始补丁提交的一部分没有提供基准测试。
在 16 行的补丁中，它只调整了一行代码，其余的都是代码注释。该补丁现在已在 Linux 内核邮件列表上供审查。
转自 Adjusting One Line Of Linux Code Yields 5x Wakeup Latency Reduction For Modern Xeon CPUs – Phoronix