指南

作者： Matt Connor 2026-08-18 · 已更新 2026-09-04

Linux kernel 7.2 VPS 有哪些新功能？

Q: 如何確認 kernel 是否包含 CONFIG_SCHED_CACHE？

執行 grep -E '^CONFIG_SCHED_CACHE' /boot/config-$(uname -r)。CONFIG_SCHED_CACHE=y 表示功能已內建，# CONFIG_SCHED_CACHE is not set 表示您的 distribution 已停用此功能，而沒有輸出則表示 kernel 早於此選項。如果 image 沒有 /boot/config-* 檔案，請嘗試 zcat /proc/config.gz；此檔案只存在於以 CONFIG_IKCONFIG_PROC 建置的 kernel。功能存在時，可以使用 sudo ls /sys/kernel/debug/sched/ | grep -i llc 在執行階段確認；該指令會列出 llc_* 可調整參數。

Q: 如何在不重新開機的情況下停用快取感知排程？

將 0 寫入 tolerance knob：sudo sh -c 'echo 0 > /sys/kernel/debug/sched/llc_aggr_tolerance'。這會在執行階段停用功能，適合用作 benchmark 的 A/B 開關。先使用 sudo cat /sys/kernel/debug/sched/llc_aggr_tolerance 讀取目前值，之後再寫回原值，因為不同 build 的預設值可能不同。寫入 debugfs 的內容不會在重新開機後保留。如果 cat 回報 No such file or directory，表示 kernel 未編譯此功能，因此沒有可停用的內容。

Q: Ubuntu 或 Debian 何時會發布以 7.2 為基礎的 kernel？

Fedora 會將穩定版本 rebase 到新的 mainline kernel，因此通常會先透過一般的 dnf upgrade 及重新開機取得。Ubuntu 會在每次六個月版本發布時提供新的 kernel，並透過 HWE stack 將其移植到前一個 LTS；歷史上的時間差接近一年：截至 2026 年 8 月，24.04 LTS HWE stack 使用 2026 年 2 月發布的 6.17，而其 GA kernel 仍為 6.8。Debian stable 會在該版本中維持一個 kernel，並透過 trixie-backports 提供較新的 kernel；您可以使用 apt install -t trixie-backports linux-image-amd64 依 package 安裝。

Linux kernel 7.2 新增 cache aware scheduling 與 CONFIG_SCHED_CACHE。了解工作執行緒如何配置到同一個 LLC，以及 VPS guest 為何通常看不到效益。

Linux kernel 7.2 的新功能

Linux kernel 7.2 於 16 August 2026 發行，值得注意的變更是 cache aware scheduling，這項功能由新的 CONFIG_SCHED_CACHE 選項建置。scheduler 現在會嘗試將同一個程序的執行緒配置在共用同一個 last level cache (LLC) 的 CPU 上。此版本沒有其他變更會影響工作負載配置到 CPU 的方式。

7.2 的其餘變更可概括為：重新設計 ext4 fast commit 路徑、改進 MGLRU（multi-generational least recently used 記憶體回收程式碼）、新增用於 inline block device encryption 的 dm-inlinecrypt device mapper target，以及從 kernel 原始碼移除最後一個 strncpy() 呼叫。

有一項事實會決定這項主要功能是否能對你發揮作用，因此先行說明。只有在 NUMA（non-uniform memory access）節點包含多個 LLC 時，cache aware load balancing 才會啟用。VPS guest 通常不會呈現這種配置，因此在多數 guest 中，相關程式碼雖然會編譯進去，卻不會實際啟用。下方的「VPS guest 能看到這些功能嗎」會使用兩個命令檢查這一點。

本頁的所有技術說明都來自 7.2 changelog，以及截至 18 August 2026 閱讀的 cache aware scheduling patch series。來源列在接近本文末尾的位置，你可以將其與自己的 kernel 實際行為進行比對。

為什麼排程器需要了解快取

現代伺服器 socket 並不只有一個最後層級快取。AMD EPYC 封裝由多個核心複合體組成，每個複合體都有自己的 L3。近期的 Intel Xeon 產品也會將一個 socket 分割成多個快取網域。因此，單一 NUMA 節點可能包含 4、8 個或更多彼此獨立的 LLC，而同一個程式的兩個執行緒可能會被安排到不同的 LLC。

這種配置會增加執行時間。當兩個執行緒從不同的 LLC 共用同一個頁面時，每個快取都會保留該快取列的副本。一側寫入時，另一側的副本會失效，因此下一次讀取必須經過互連，或前往主記憶體。這就是快取抖動。它會表現為等待所消耗的週期，而不是 CPU 閒置時間，因此監看負載平均值時很容易忽略。

在 7.2 之前，負載平衡器會根據負載、使用率與閒置 CPU 來配置工作。它沒有任何資訊指出「這兩個工作會讀取相同的記憶體」。7.2 新增了這項資訊，並採用幾乎不增加計算成本的近似方式：程序的執行緒共用同一個位址空間，因此可將它們視為可能共用資料。

核心如何選擇偏好的 LLC

追蹤資訊附加在程序的 mm_struct 中。這是代表一個位址空間的核心結構。核心會定期取樣該程序的執行緒目前在哪些 CPU 上執行，並以 LLC 為單位，計算該程序有多少部分位於各個 LLC。承載該程序最多內容的 LLC，會成為整個程序的偏好 LLC。後續決策讀取的就是這個單一值。

接著有兩條路徑會使用這項資訊。喚醒程序時，排程器會優先選擇程序偏好的 LLC 中的 CPU，而不是在該節點中任意選擇閒置 CPU。進行負載平衡時，若必須在排程器群組之間移動工作，排程器會優先移動已偏好目的地 LLC 的工作，也會避免將工作從其偏好的 LLC 移走。

限制條件與這項功能同樣重要。若將忙碌程序的所有執行緒集中到一個快取網域，可能導致該網域過載，而 socket 的其餘部分卻處於閒置狀態。可調整參數位於 debugfs，也就是核心的除錯檔案系統中，路徑為 /sys/kernel/debug/sched/：

llc_aggr_tolerance 的值範圍為 0 到 100，用於設定核心進行聚合的程度。0 會在執行期間關閉快取感知排程。1 是較保守的設定：若程序的 RSS（resident set size，常駐記憶體大小）大於 LLC，或執行緒數量多於 LLC 的核心數，便維持原位置。100 不論大小或執行緒數量，都會進行聚合。
llc_overload_pct 的預設值為 50，表示偏好 LLC 被視為忙碌前的平均使用率門檻。
llc_imb_pct 的預設值為 20，用於限制偏好 LLC 超過該過載門檻後，聚合遷移可能造成的負載不平衡程度。
llc_epoch_period 的預設值為 10 ms，表示收集使用狀況的間隔。
llc_epoch_affinity_timeout 的預設值為 50 ms，表示非作用中程序在核心捨棄其偏好前，保留該偏好的時間。

變更前，請先讀取目前使用的值。不同 distribution 可能提供不同的預設值：sudo cat /sys/kernel/debug/sched/llc_aggr_tolerance。

哪些工作負載可能受益，哪些不會

以下數字是修補程式系列隨附的發布數據，測試使用伺服器級硬體，其中部分測試將容忍度旋鈕調至較激進的設定。請將這些數字視為裸機環境下的理想結果，不是對您環境的保證。

ChartReported gains from cache aware scheduling, server hardware, percent

label

gain_pct

hackbench, 1 group, Xeon Sapphire Rapids

30.57

schbench, 4 threads, p99 wakeup latency, Sapphire Rapids

37.78

ChaCha20 throughput, AMD Genoa, aggressive tolerance

The data behind this chart

[
  {
    "label": "hackbench, 1 group, Xeon Sapphire Rapids",
    "gain_pct": 30.57
  },
  {
    "label": "schbench, 4 threads, p99 wakeup latency, Sapphire Rapids",
    "gain_pct": 37.78
  },
  {
    "label": "ChaCha20 throughput, AMD Genoa, aggressive tolerance",
    "gain_pct": 44
  }
]

單一群組的 Hackbench 效能提升 30.57%，AMD Genoa 上的 ChaCha20 throughput 測試提升 44%。全部 3 項結果，都是在測試人員可完全控制的多 LLC 伺服器硬體上取得。

能夠受益的工作負載通常具備以下特徵：

單一程序中有多個執行緒，因此存在可分組的對象。
這些執行緒之間確實共享資料，因此快取行在處理器之間來回移動會產生成本。
工作集可容納於單一 LLC 內，因為工作集大於快取的程序，無法透過搬移來獲得快取區域性。
機器仍有可用容量，因此排程器確實能選擇下一個執行緒的放置位置。

以下情況則沒有可獲得的效益：

機器已達滿載。每個 CPU 都在忙碌，因此執行緒放置位置已被迫決定，所報告的效能提升會減弱。
單執行緒程序，以及彼此獨立且不共享資料的程序集區。
工作集遠大於 LLC；謹慎的 llc_aggr_tolerance 設定會刻意略過這類工作集。
回報只有一個 LLC 的節點；此功能完全不會啟用。

這項功能也有成本，而修補程式系列對此有明確說明。收集佔用資訊需要在工作執行的 context 中處理，部分測試顯示請求延遲變差，原因是這項工作延後了工作返回 user space 的時間。即使平均 throughput 提升，彙總處理也可能增加延遲變異。如果您關注的是尾端延遲，而不是平均值，請測量自己的尾端延遲。

VPS 客體能看見其中任何內容嗎？

答案取決於兩個事實。

首先，這項功能受拓撲限制。只有在同一個 NUMA node 內存在多個 LLC 時，才會啟用快取感知負載平衡；kernel 會在設定拓撲時記錄這項資訊。如果某個 node 回報只有單一 LLC，無論如何設定 tunable，快取感知路徑都會維持停用。

其次，客體讀取到的快取拓撲不是主機的拓撲，而是 hypervisor 所呈現的 CPU model。預設的 KVM（kernel based virtual machine）客體通常不會取得主機實際的 L3 配置，因此客體只能根據簡化後的拓撲進行判斷。

請檢查你的客體實際看見的內容：

systemd-detect-virt
lscpu --caches
cat /sys/devices/system/cpu/cpu*/cache/index3/shared_cpu_list | sort -u

index3 是多數 x86 CPU 上的 L3 cache。如果一行列出所有 vCPU，表示客體看見單一 LLC，因此沒有可供此功能安排的內容。No such file or directory 表示客體完全沒有看見 L3；此時客體會將較低層級的 cache 視為最後一層，而其邊界是由 hypervisor 建立，不是由實體晶片提供。

接著還有雙重排程，這是任何租戶都必須正視的限制。客體 kernel 會將執行緒配置到 vCPU。主機 kernel 則會將這些 vCPU 執行緒配置到實體核心。客體若將四個執行緒仔細分組到 vCPU 0 到 3，表達的是對四個主機執行緒的偏好；主機仍可將它們配置到不同的實體快取網域，也可以之後重新移動它們。客體的決策並沒有錯，只是它不是最後的決策。這也是造成吵鬧鄰居在你的 vCPU 上留下的 steal time的同一層邊界。

那麼，這項功能會在哪些地方影響 VPS 租戶？有兩個地方。在拓撲是真實而非合成的方案中，例如 dedicated core，或提供直通拓撲的大型 instance，客體 scheduler 所做的決策會對應到實際存在的硬體。另一個地方是 provider 自己的主機 kernel；由 provider 決定是否對你的 vCPU 執行緒採用快取感知配置，這是 provider 能取得的效益，不是你的效益。快取配置也會因架構而異；比較Arm VPS 與 x86 VPS時，這又是另一項變數。

在客體內測量快取行為，比在實體主機上更困難。perf stat -e cache-misses 通常會回報 <not supported>，因為 hypervisor 不會將 PMU（performance monitoring unit）提供給客體。請改為測量自己應用程式的吞吐量與延遲，並使用 debugfs knob 作為兩次測試之間的切換開關。

檢查 kernel 是否包含 CONFIG_SCHED_CACHE

uname -r
grep -E '^CONFIG_SCHED_CACHE' /boot/config-$(uname -r) || echo 'not set in this build'
sudo ls /sys/kernel/debug/sched/ | grep -i llc

若輸出 CONFIG_SCHED_CACHE=y，表示 kernel 建置時已啟用此功能。若輸出內容包含 # CONFIG_SCHED_CACHE is not set，表示該版本存在此選項，但你的 distribution 已將其關閉。完全沒有輸出通常表示 kernel 版本早於此選項；uname -r 可以確認這一點。部分精簡的 cloud image 沒有 /boot/config-* 檔案，此時請改讀取 zcat /proc/config.gz。但只有在 kernel 建置時啟用 CONFIG_IKCONFIG_PROC 的情況下，這個檔案才可用。

啟用此功能時，ls 行會顯示 llc_* 可調整參數。如果 CONFIG_SCHED_CACHE=y 時沒有輸出，請先使用 sudo mount -t debugfs none /sys/kernel/debug 掛載 debugfs。

若要比較啟用和停用此功能時的工作負載，請先記錄目前值，因為稍後必須還原：

sudo cat /sys/kernel/debug/sched/llc_aggr_tolerance
sudo sh -c 'echo 0 > /sys/kernel/debug/sched/llc_aggr_tolerance'

執行基準測試，將記錄的值寫回，再重新執行一次。Debugfs 的寫入內容在重新開機後不會保留，這正適合測試用途。

發行版核心何時會包含 7.2

Mainline 並不是 VPS 實際開機使用的核心。uname -r 中的版本來自你的發行版，而每個發行版都有各自將 mainline 發行版帶入伺服器的流程。

Fedora 會在支援期間，將穩定版本重新建立在較新的 mainline 核心上。因此，在 Fedora 中，sudo dnf upgrade --refresh 加上重新開機就是完整流程，通常也是租戶最早能嘗試新核心的地方。執行 VPS 上的 Fedora Server 時，這項更新週期就是你所選擇的一部分。

Ubuntu 每 6 個月發行一個新版本，並透過 HWE（hardware enablement）堆疊，將新核心帶入先前的長期支援（LTS）版本。截至 August 2026，Ubuntu 24.04 LTS 仍會將 2024 年 4 月的 6.8 安裝為 GA 核心；其 HWE 堆疊則在 August 2025 更新至 6.14，並在 February 2026 更新至 6.17。實際時程大致如此：2026 年 8 月的 mainline 發行版，約在一年後才會進入 LTS 的 HWE 堆疊。

apt-cache policy linux-generic-hwe-24.04
sudo apt install --install-recommends linux-generic-hwe-24.04

Debian stable 在整個發行版生命週期中維持同一個核心，較新的核心則透過 backports 提供，必須逐一套件選擇啟用：

echo 'deb http://deb.debian.org/debian trixie-backports main' | sudo tee /etc/apt/sources.list.d/backports.list
sudo apt update
sudo apt install -t trixie-backports linux-image-amd64

完成上述任一流程後，重新開機，再使用 uname -r 和上方的 grep 確認。新核心無法即時載入：VPS 上的即時核心修補只能替換執行中核心內個別函式的程式碼，無法變更結構配置或新增 debugfs 檔案。快取感知排程同時涉及這兩項變更，因為它會在 mm_struct 中新增欄位，因此只能透過啟動新核心來套用。

接下來有兩項實務工作。保留舊核心以供開機，直到新核心穩定承載工作負載一段時間；設定 VPS 開機使用的核心就是用來處理這件事。另請監控 /boot，因為小型 VPS 的開機分割區在幾次核心升級後就可能填滿；在 Ubuntu 清理舊核心說明了相關處理方式。

最後要釐清所有權。在 KVM VPS 上，來賓核心由你管理：你選擇核心、啟動核心，也可以回復到舊版本。主機核心則由供應商管理，來賓系統內的任何設定都無法變更虛擬機器監控程式所執行的排程器。因此，關於排程器放置的發行說明，對租戶而言只涵蓋一半；你能控制的是來賓端。

本頁使用的來源

kernelnewbies.org 的 7.2 變更日誌摘要，用於確認 16 August 2026 的發布日期及非排程器變更。
LWN 對快取感知排程系列的報導：lwn.net/Articles/1041668 與 lwn.net/Articles/1058288，用於確認 debugfs 可調參數、每個程序的偏好設定機制及報導中的基準測試數據。
限制此功能只能在特定拓撲啟用的修補程式 "sched/cache: Introduce sched_cache_present"，用於確認快取感知負載平衡必須在 NUMA 節點中具備超過一個 LLC 的規則。

如需查看上一個版本，請參閱 Linux kernel 7.1 的變更內容。如需了解版本號的由來，請參閱 Linux kernel 歷史時間軸。

FAQ

Linux 7.2 中的快取感知排程會讓 VPS 變快嗎？

通常不會單靠這項功能變快。只有在 NUMA node 回報多個 last level cache 時，這項功能才會啟用；而典型的 KVM guest 不會呈現這種配置，因此程式碼根本不會生效。即使功能生效，guest 仍會經過兩次排程：您的 kernel 會選擇 vCPU，host kernel 再決定該 vCPU thread 執行在哪個實體核心上，因此 guest 端的快取決策可能被 host 覆寫。在 guest 中執行 cat /sys/devices/system/cpu/cpu*/cache/index3/shared_cpu_list | sort -u。如果所有 vCPU 都集中在同一行，表示沒有可供這項功能安排的內容。

如何確認 kernel 是否包含 CONFIG_SCHED_CACHE？

執行 grep -E '^CONFIG_SCHED_CACHE' /boot/config-$(uname -r)。CONFIG_SCHED_CACHE=y 表示功能已內建，# CONFIG_SCHED_CACHE is not set 表示您的 distribution 已停用此功能，而沒有輸出則表示 kernel 早於此選項。如果 image 沒有 /boot/config-* 檔案，請嘗試 zcat /proc/config.gz；此檔案只存在於以 CONFIG_IKCONFIG_PROC 建置的 kernel。功能存在時，可以使用 sudo ls /sys/kernel/debug/sched/ | grep -i llc 在執行階段確認；該指令會列出 llc_* 可調整參數。

如何在不重新開機的情況下停用快取感知排程？

將 0 寫入 tolerance knob：sudo sh -c 'echo 0 > /sys/kernel/debug/sched/llc_aggr_tolerance'。這會在執行階段停用功能，適合用作 benchmark 的 A/B 開關。先使用 sudo cat /sys/kernel/debug/sched/llc_aggr_tolerance 讀取目前值，之後再寫回原值，因為不同 build 的預設值可能不同。寫入 debugfs 的內容不會在重新開機後保留。如果 cat 回報 No such file or directory，表示 kernel 未編譯此功能，因此沒有可停用的內容。

Ubuntu 或 Debian 何時會發布以 7.2 為基礎的 kernel？

Fedora 會將穩定版本 rebase 到新的 mainline kernel，因此通常會先透過一般的 dnf upgrade 及重新開機取得。Ubuntu 會在每次六個月版本發布時提供新的 kernel，並透過 HWE stack 將其移植到前一個 LTS；歷史上的時間差接近一年：截至 2026 年 8 月，24.04 LTS HWE stack 使用 2026 年 2 月發布的 6.17，而其 GA kernel 仍為 6.8。Debian stable 會在該版本中維持一個 kernel，並透過 trixie-backports 提供較新的 kernel；您可以使用 apt install -t trixie-backports linux-image-amd64 依 package 安裝。

#linux-kernel#scheduler#releases#performance #vps