非RT内核下如何通知CPU/内核优先保障延迟敏感例程性能

API 探路者

2026-8-28

问题现象

你观察到的两段代码存在明显性能差异，判断标准为end - start统计的pseudoFunction()执行耗时：
无sleep的紧循环版本：

while {
        start = now()
        pseudoFunction()
        end = now()
}

加入100ms sleep的版本执行速度会慢数倍：

while {
        start = now()
        pseudoFunction()
        end = now()
        sleep(100ms)
}

该性能差异和你的推测方向完全一致：

无sleep的紧循环会让核心持续处于负载状态，CPU不会进入深C-state节能态，频率会稳定维持在高位，因此pseudoFunction()的执行耗时稳定且偏低。
加入100ms sleep后，循环间隙核心无任务可跑，会自动进入深C-state、同时频率降到节能档，下次唤醒时需要先经历深C-state退出延迟（几微秒到上百微秒不等，看C-state深度）、再经历频率爬升过程，因此单次执行耗时会比紧循环高数倍到一个数量级。

不需要替换RT内核，从频率调控、调度配置、内存优化三个层面做配置即可达到接近RT内核的延迟表现：

基础全局配置：可以直接将CPUfreq governor切到performance模式锁最高基础频率，同时在BIOS/内核启动参数里限制CPU进入的最深C-state为C1/C1E，彻底消除深C-state退出延迟。如果不想改全局配置，可以只给延迟敏感任务绑定的核心单独修改配置。
不存在用户态可直接调用的“手动触发睿频”API，Intel/AMD的睿频/加速频率是硬件根据核心负载、温度、功耗余量自动调整的，不需要手动触发：只要核心有持续可运行任务，且能源性能偏好（EPP）设为性能档，硬件会在数十微秒内将频率拉到最高可用睿频点。你可以通过修改/sys/devices/system/cpu/cpu*/cpufreq/energy_performance_preference节点为performance，让绑定到对应核心的任务获得最快的频率爬升速度。
如果使用Intel处理器的HWP（硬件P-state）功能，可以直接给进程设置性能偏好，不需要修改全局governor。

设置线程优先级对延迟敏感任务的性能提升非常明显，相关系统调用不需要RT内核即可使用：

普通CFS调度场景下，可以通过nice()系统调用将线程的nice值设置为-20（普通进程最高优先级），操作需要CAP_SYS_NICE权限，设置后该线程在CFS调度队列中会获得更高的时间片权重，被调度的优先级高于所有普通优先级进程。
对延迟要求更高的场景，可以通过sched_setscheduler()系统调用给线程配置SCHED_FIFO或SCHED_RR实时调度策略，设置1~10区间的实时优先级即可（优先级不要设到99，否则会抢占内核线程、看门狗等核心系统任务，容易导致系统锁死）。配置实时策略后，只要该线程处于可运行状态，内核会优先将CPU资源分配给它，不会被普通进程抢占。
配合sched_setaffinity()系统调用将延迟敏感线程绑定到1~2个固定核心上效果更好：可以通过内核启动参数isolcpus=将指定核心从普通调度域中隔离，不让普通进程在这些核心上调度，彻底消除其他进程带来的上下文切换开销，同时核心上的CPU缓存命中率会大幅提升，睿频频率也能维持得更稳定。

内存层面：通过mlockall()系统调用将进程的全部地址空间锁在物理内存中，避免换页、缺页异常带来的不可预期延迟；对核心工作集内存通过madvise()标记MADV_HUGEPAGE使用透明大页，降低TLB miss开销。
预热逻辑：正式运行延迟敏感例程前，先空跑3~5次目标函数，提前把函数用到的指令、数据加载到CPU缓存中，同时触发CPU频率爬升，避免冷启动开销。
如果工作逻辑必须加sleep间隔，不要用长sleep后直接跑核心逻辑，可以改用高精度定时器（timer_create配合CLOCK_MONOTONIC时钟源）设置唤醒事件，将唤醒回调绑定到隔离的高优先级核心上，减少唤醒后的调度等待延迟。

内容的提问来源于stack exchange，提问作者kpeteL