遊戲 Lag 白皮書 › L7 伺服器 OS（kernel）
伺服器電源管理（C-state、頻率調整）造成延遲飆高 CPU power management latency (C-states, frequency scaling)
原因 ID so-cstate · 主要負責 基礎設施團隊（伺服器基礎設施）
在含圖解與實驗的完整版中開啟卡片 →
閒置的 CPU 核心為了省電，會進入深層省電狀態（C-state）並降低頻率。封包或計時器到來時，喚醒核心並拉高頻率需要時間，處理小封包時就會多出延遲。
為什麼 OS 的頻率調整策略（governor）或 BIOS 電源設定允許深層 C-state 與低頻率 → 於是 閒置核心每次從深層省電狀態喚醒都會慢上最多數百 µs；頻率被鎖在低檔時，tick 計算本身也會變慢 → 畫面上 通常很難察覺，但伺服器之間的呼叫一多就會累積起來，變成人少時回應反而變慢的輸入延遲。頻率被鎖在低檔時，人潮湧入就會讓 tick 延後，出現慢動作
症狀 輸入延遲 , 慢動作 因素 延遲, 抖動, 停滯
誰會遇到 整個伺服器
何時 一直都有, 偶爾隨機發生
負責單位 主要負責 基礎設施團隊（伺服器基礎設施）
基礎設施團隊要做的事 BIOS 電源設定改為效能優先，OS governor 設為 performance（cpufreq 的 scaling_governor）；對延遲敏感的伺服器限制深層 C-state（tuned latency-performance 設定檔、PM QoS 的 /dev/cpu_dma_latency、kernel 參數 intel_idle.max_cstate）；變更後一併比較同一資料中心內的往返時間、tick 時間抖動與耗電量。
數值參考 依 Linux 6.12 的 intel_idle 驅動程式表格，Intel 伺服器 CPU 從淺層 C1 喚醒需要 1～2µs，從深層 C6 需要 133µs（Skylake-SP）～290µs（Sapphire Rapids）。單次很短，但一個請求經過好幾台伺服器時就會跟著累積。kernel 預期的閒置時間越長，就越會選擇深層狀態，所以在封包零星到來的冷清伺服器上更常出現。通用 cpufreq 的 powersave governor 會把頻率固定在允許範圍內的最低值（intel_pstate 中同名的演算法則會依負載調整）。
圖表上 查看位置 用 cpupower monitor 看各核心停留在各 C-state 的比例與實際頻率，確認 /sys/devices/system/cpu/cpu0/cpuidle/ 底下每個 state 的 name、latency（喚醒所需的 µs）、usage 與 cpufreq 的 scaling_governor，並用 tuned-adm active 確認目前的設定檔 符合的跡象 核心閒置時長時間停在最深的 C-state，或頻率被鎖在最低值附近；改用 performance governor 與淺層 C-state 後，小請求的往返時間與抖動減少 不符合的跡象 變更後差異在數十 µs 以內，這個原因可以忽略。以 ms 為單位飆高時是「CPU steal（虛擬機器）」或其他層 確認方式 用基礎設施工具確認（不需要遊戲程式碼）
深入了解 IDC 機房的裸機（bare metal）伺服器要同時檢查 BIOS（韌體）的電源設定與 OS 設定。在雲端上，只有部分執行個體類型能讓 OS 變更 C-state 與頻率，而 AWS 的預設設定偏向最高效能，大多維持原樣即可。Red Hat 系列的 tuned latency-performance 設定檔會把 governor 設為 performance，並透過 PM QoS 只使用淺層 C-state。關閉省電會增加耗電，所以只套用在對延遲敏感的伺服器上。
出處 CPU Idle Time Management Linux kernel 每個省電狀態都有喚醒時間（exit latency）與最短停留時間（target residency），並依預期閒置時間選擇深層狀態；sysfs 中各 state 的 latency、usage、time；以 PM QoS（/dev/cpu_dma_latency）與 intel_idle.max_cstate 限制深層狀態 drivers/idle/intel_idle.c (Linux v6.12) Linux kernel Intel 伺服器 CPU 各 C-state 的喚醒時間：Skylake-SP C1 2µs、C1E 10µs、C6 133µs；Ice Lake C6 170µs；Sapphire Rapids C1 1µs、C6 290µs CPU Performance Scaling Linux kernel 以 scaling_governor 確認與變更 governor；performance 會要求允許範圍內的最高頻率，powersave 則要求最低頻率 intel_pstate CPU Performance Scaling Driver Linux kernel intel_pstate 的 powersave 演算法和通用的 powersave governor 不同，會依負載調整（類似 schedutil、ondemand） Chapter 2. Getting started with TuneD Red Hat latency-performance 設定檔會關閉省電功能、把 governor 設為 performance，並透過 PM QoS 只使用淺層 C-state；以 tuned-adm active 確認目前的設定檔 tools/power/cpupower/man/cpupower-monitor.1 (Linux v6.12) Linux kernel cpupower monitor：各核心的頻率與省電狀態統計 Processor state control for Amazon EC2 Linux instances AWS 只有部分執行個體類型能讓 OS 控制 C-state、P-state，可為了降低延遲而調整；預設設定為最高效能，適合大多數工作負載；Graviton 為固定頻率，不由 OS 控制 相關原因
同一層：L7 伺服器 OS（kernel）
同一症狀（輸入延遲）在其他層的原因
查看含圖解與實驗的完整版卡片