linux中调整进程调度延迟敏感参数的核心是修改cfs的sched_latency_ns、sched_min_granularity_ns和sched_wakeup_granularity_ns三个时间类参数，它们共同决定调度周期、最小时间片与唤醒抢占阈值，直接影响低延迟场景下的响应性能；必须通过sysctl安全配置，严禁裸写/proc，且需按负载类型实测调优，避免误配引发抖动或软锁死。
Linux 中调整进程调度延迟敏感参数，核心是修改 CFS（完全公平调度器）的几个关键时间类参数，尤其是 sched_latency_ns 和 sched_min_granularity_ns。它们不控制单个进程优先级，而是决定整个调度周期的节奏和最小时间片长度，直接影响响应延迟、上下文切换频率与 CPU 利用均衡性。
哪些参数真正影响调度延迟敏感性
以下三个参数最直接关联“延迟敏感”场景（如实时音视频、高频交易、低延迟 Web 服务）：
- kernel.sched_latency_ns：一个调度周期总时长，默认约 6ms–24ms。值越小，所有可运行任务轮转越快，单次等待延迟理论上限越低，但可能抬高上下文切换开销。
- kernel.sched_min_granularity_ns：单个任务最小保证运行时间（时间片下限），默认约 2.25ms。设太小（如
- kernel.sched_wakeup_granularity_ns：唤醒后抢占判定阈值。值越小，刚唤醒的任务越容易抢占当前运行任务，提升唤醒响应速度，但可能加剧争抢。
安全修改方法：必须用 sysctl，禁止裸写 /proc
这些参数位于 /proc/sys/kernel/ 下，但不能用 echo xxx > /proc/sys/kernel/xxx 直接覆盖——部分参数有校验逻辑，裸写会被静默忽略或报错。
- 临时生效（重启失效）：
sudo sysctl -w kernel.sched_latency_ns=4000000（设为 4ms） - 永久生效：新建配置文件
/etc/sysctl.d/99-sched-lowlat.conf，内容为：kernel.sched_latency_ns = 4000000<br>kernel.sched_min_granularity_ns = 1000000<br>kernel.sched_wakeup_granularity_ns = 1000000
- 加载配置：
sudo sysctl --system（注意不是sysctl -p，后者不扫描/etc/sysctl.d/全目录） - 验证是否生效：
sysctl kernel.sched_latency_ns并对比cat /proc/sys/kernel/sched_latency_ns
设多少才合理：按负载类型选，不是越小越好
参数效果高度依赖实际业务特征，没有“万能值”。常见参考如下：
- 交互型/低延迟服务（如桌面、实时 API）：sched_latency_ns 可设 4000000–6000000（4–6ms），granularity 设 1000000（1ms），wakeup_granularity 设 500000–1000000
- 计算密集型服务（如批处理、渲染）：latency 可放宽至 10000000（10ms），granularity 保持 1000000–2000000，减少切换开销
- I/O 密集型服务（如数据库）：建议维持默认 latency（如 24ms），granularity 不低于 1000000；更有效的是绑定 CPU + 调整 I/O 调度器，而非激进压低调度延迟
- 严禁踩坑：latency
改完没变化？先确认这三件事
调了参数却看不到延迟改善，大概率是以下原因：
- 你的应用本身不是 CPU-bound 或非多线程——比如单线程 Python 同步服务，再细的调度粒度也无法缩短阻塞等待时间
- 当前 CPU 已长期 100% us 占用，调度器只能在争抢中分配时间片，降低 latency 反而加剧竞争
- 没确认实际使用的是 CFS：运行
cat /sys/kernel/debug/sched_features | grep CFS，无输出说明可能被chrt强制设为 SCHED_FIFO/SCHED_RR，此时 kernel.sched_* 参数不生效
