performance是服务器主流cpu governor，因其强制最高频运行以消除频率切换开销，保障数据库、低延迟服务、容器化部署及基准测试的稳定性与可复现性。
在服务器场景下，performance 是最常被推荐的 CPU governor，尤其对延迟敏感、吞吐稳定或计算密集型服务（如数据库、实时交易、高性能 Web 服务）；schedutil 是现代内核（≥4.12）中更智能的替代方案，兼顾响应与能效，在多数通用服务器上表现均衡；powersave 一般不推荐用于生产服务器，除非明确以节能为第一目标且可接受性能波动。
为什么 performance 仍是主流选择？
它强制 CPU 频率始终运行在最高可用档位，消除频率切换开销和调度延迟不确定性。这对以下场景至关重要：
- 数据库（postgresql/mysql）：避免查询因降频导致的偶发毛刺或长尾延迟
- 低延迟服务（如金融行情推送、实时风控）：确保硬实时响应能力
- 容器化高密度部署：避免不同 Pod 因频率动态调整互相干扰
- 基准测试或性能调优阶段：排除 governor 引入的变量，让结果更可复现
schedutil 的适用边界在哪？
它由调度器直接驱动，基于 CFS 运行队列负载实时决策频率，响应更快、更精准。适合：
- 混合负载服务器（例如同时跑 nginx + Python 后端 + 日志处理）
- 云环境中的虚拟机或裸金属实例（内核 ≥5.4 更成熟）
- 希望降低功耗但不能牺牲太多稳定性的场景（如边缘计算节点）
- 已启用 Intel Speed select 或 AMD CPPC 的新平台，能更好发挥其协同能力
注意：某些旧 BIOS/UEFI 或特定微码版本下，schedutil 可能触发异常升频或滞后，上线前建议用 stress-ng --cpu 4 --timeout 60s 搭配 watch -n1 'cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freq' 观察响应一致性。
为什么 powersave 要谨慎使用？
它依赖硬件反馈（如 APERF/MPERF）被动调节，策略保守，容易出现：
- 突发流量到来时升频延迟明显（几十毫秒级），引发请求堆积
- 在周期性轻载—重载切换的服务中（如定时批处理），频率“追不上”负载变化
- 与 tickless idle（NO_HZ_IDLE）叠加时，可能加剧调度抖动
仅建议用于非关键后台任务服务器（如归档日志、离线转码集群），且需配合 cpupower 设置最小频率兜底（如 cpupower frequency-set -d 1.2GHz）防止过低降频。
实操建议
检查当前 governor：cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
临时切换（所有 CPU）：echo performance | sudo tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
持久化设置（推荐方式）：
修改 /etc/default/grub，在 GRUB_CMDLINE_linux 中添加：intel_idle.max_cstate=1 intel_idle.states_off=0-3 cpupower=performance（Intel）
或amd_pstate=passive（AMD Zen3+，内核 ≥6.1，默认启用 schedutil）
重启后验证：cpupower frequency-info 和 cat /proc/sys/kernel/sched_latency_ns（确认调度器未被意外限制）