SSD Nodes Learn 🎉 VPS $5.50/月起
指南 Matt Connor作者： Matt Connor · 更新于 2026-08-21

Linux内核7.2缓存感知调度对VPS有用吗

Linux内核7.2新增CONFIG_SCHED_CACHE缓存感知调度。了解它如何按共享LLC放置线程，以及为何大多数VPS guest不会获得实际收益。

Linux kernel 7.2 的新变化

Linux kernel 7.2 于 16 August 2026 发布，值得关注的变化是缓存感知调度。该功能由新的 CONFIG_SCHED_CACHE 选项启用。调度器现在会尝试将同一进程的线程保持在共享同一个末级缓存（LLC）的 CPU 上。此版本没有其他变化会影响工作负载在 CPU 上的放置方式。

7.2 的其他变化可概括为：重新实现 ext4 快速提交路径；改进 MGLRU（多代最近最少使用内存回收代码）；新增用于块设备内联加密的 dm-inlinecrypt device mapper target；以及从内核源代码中移除最后一个 strncpy() 调用。

有一个事实决定了这个主要功能是否能为您提供帮助，因此先说明这一点。只有在一个 NUMA（非统一内存访问）节点包含多个 LLC 时，缓存感知负载均衡才会启用。VPS guest 通常看不到这种布局，因此在大多数 guest 中，该代码虽然会被编译进去，但不会实际启用。下面的“VPS guest 能看到这些变化吗”一节会使用两条命令进行检查。

本页的所有技术结论均来自 7.2 changelog，以及截至 18 August 2026 查阅的缓存感知调度补丁系列。文末附近列出了来源，您可以将其与自己的 kernel 实际行为进行对照。

调度器为何需要了解缓存

现代服务器套接字并不只有一个末级缓存。AMD EPYC 封装由多个核心复合体组成，每个复合体都有自己的 L3 缓存。近期的 Intel Xeon 处理器也会将一个套接字划分为多个缓存域。因此，一个 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（常驻集大小，即其常驻内存）大于 LLC，或其运行线程数多于 LLC 中的核心数，则保持进程当前位置不变。100 不考虑大小或线程数，直接进行聚合。
  • llc_overload_pct 的默认值为 50，用于设置首选 LLC 被视为繁忙时所需的平均利用率阈值。
  • llc_imb_pct 的默认值为 20，用于限制首选 LLC 超过该过载阈值后，聚合迁移可能造成的不平衡程度。
  • llc_epoch_period 的默认值为 10 ms，用于设置收集占用情况的间隔。
  • llc_epoch_affinity_timeout 的默认值为 50 ms，用于设置非活动进程保留其首选 LLC 的时长，超过该时长后内核会将其清除。

修改任何参数前，先读取当前值。不同发行版可能提供不同的默认值：sudo cat /sys/kernel/debug/sched/llc_aggr_tolerance。

哪些工作负载可能受益，哪些不会

下面的数字来自该补丁系列发布的结果。测试使用服务器级硬件，其中部分测试将容差参数调到了激进设置。请将这些数字视为裸机上的理想情况，而不是对您的服务器的承诺。

ChartReported gains from cache aware scheduling, server hardware, percent
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 吞吐量测试提升了 44%。全部 3 项结果均在测试人员端到端控制的多 LLC 服务器硬件上取得。

能够受益的工作负载通常具备以下特征：

  • 单个进程中有多个线程，因此存在可分组的对象。
  • 这些线程之间存在实际共享，因此缓存行来回迁移确实会产生开销。
  • 工作集能够放入一个 LLC，因为超过缓存容量的进程无法通过迁移来获得缓存局部性。
  • 机器存在空闲容量，因此调度器确实可以选择下一个线程的放置位置。

以下情况则没有收益：

  • 机器已经满负载运行。所有 CPU 都处于忙碌状态，因此线程放置位置被迫确定，报告的收益会减弱。
  • 单线程进程，以及互不共享数据的独立进程池。
  • 工作集远大于 LLC 的情况，谨慎的 llc_aggr_tolerance 设置会主动跳过这类工作负载。
  • 只报告一个 LLC 的节点，因为该功能根本不会启用。

该系列也明确说明了成本。收集占用信息需要在任务上下文中执行额外工作，部分测试显示请求延迟变差，因为这项工作延迟了任务返回用户空间。即使平均吞吐量提高，聚合也可能增加延迟方差。如果您关注的是尾延迟而不是平均值，请测量自己的尾延迟。

VPS 客户机能看到其中哪些内容

有两个事实决定答案。

首先，该功能取决于拓扑。只有在一个 NUMA 节点内存在多个 LLC 时，缓存感知负载均衡才会启用；内核会在设置拓扑时记录这一点。如果某个节点报告只有一个 LLC，无论如何设置可调参数，缓存感知路径都不会激活。

其次，客户机读取到的缓存拓扑不是宿主机的拓扑，而是 hypervisor 的 CPU 模型呈现的拓扑。默认的 KVM（基于内核的虚拟机）客户机通常不会获得宿主机真实的 L3 布局，因此客户机实际处理的是一个简化后的拓扑。

检查当前客户机看到的内容：

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

index3 表示大多数 x86 CPU 上的 L3 缓存。一行列出所有 vCPU，表示客户机看到的是单个 LLC，因此该功能没有可安排的内容。No such file or directory 表示客户机完全看不到 L3，随后会将更低级别的缓存视为最后一级缓存；其边界由 hypervisor 虚拟，而不是由硬件实际结构决定。

此外，还存在双重调度问题，这是任何租户都必须面对的实际限制。客户机内核会将线程放置到 vCPU 上。宿主机内核再将这些 vCPU 线程放置到物理核心上。客户机将 4 个线程精确分组到 vCPU 0 到 3，只是表达了对 4 个宿主机线程的偏好；宿主机仍可将它们放置到不同的物理缓存域中，也可以稍后移动它们。客户机的决定并没有错，只是它不是最终决定。这与 嘈杂邻居在你的 vCPU 上造成的 steal time 属于同一个层次边界。

那么，VPS 租户能从该功能中获得什么？主要有两个方面。对于拓扑真实存在而非虚拟生成的方案，例如专用核心，或传递实际布局的大型实例，客户机调度器作出的决定对应的是实际硬件。另一方面，在服务提供商自己的宿主机内核中，缓存感知的 vCPU 线程放置由服务提供商获得收益，而不是由你控制。缓存布局也因架构而异，因此比较 Arm VPS 与 x86 VPS 时还要考虑这一变量。

在客户机内测量缓存行为，比在裸机上更困难。perf stat -e cache-misses 通常会报告 <not supported>，因为 hypervisor 不会向客户机暴露 PMU（性能监控单元）。应改为测量自有应用的吞吐量和延迟，并使用 debugfs 开关控制两次测试之间的切换。

检查内核是否包含 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 表示内核编译时启用了该功能。输出 # CONFIG_SCHED_CACHE is not set 表示该选项存在于此版本中，但发行版将其关闭。完全没有输出通常表示内核版本早于该选项的引入版本，使用 uname -r 可确认这一点。某些精简版云镜像不提供 /boot/config-* 文件，此时应改为读取 zcat /proc/config.gz；但只有在内核编译时启用了 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（硬件启用）堆栈将其提供给之前的长期支持（LTS）版本。截至 2026 年 8 月，Ubuntu 24.04 LTS 仍将 2024 年 4 月发布的 6.8 作为 GA 内核安装，而其 HWE 堆栈已在 2025 年 8 月迁移到 6.14，并在 2026 年 2 月迁移到 6.17。实际时间尺度大致如此：2026 年 8 月发布的 mainline 内核，大约 1 年后才会进入 LTS 的 HWE 堆栈。

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

Debian stable 在整个发行版生命周期内保持一个内核，并通过 backports 提供更新版本。你需要按软件包单独启用 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 上，客户机内核属于你：你可以选择、启动并回滚它。宿主机内核属于服务提供商，客户机内的任何设置都无法改变虚拟机监控程序运行的调度器。因此，关于调度器放置的发行说明对租户来说只说明了一半情况，而你能控制的只有客户机这一侧。

本页使用的来源

如需了解上一版本，请参阅 Linux kernel 7.1 中有哪些变化。如需了解版本号的由来，请参阅 Linux kernel 历史时间线。

FAQ

Linux 7.2 中的缓存感知调度会让 VPS 更快吗？

通常不会单独带来提升。只有当 NUMA 节点报告存在多个末级缓存时，该功能才会启用；而典型的 KVM 客体不会显示这种布局，因此相关代码根本不会运行。即使功能启用，客体仍会经历两次调度：您的内核选择一个 vCPU，主机内核再决定该 vCPU 线程运行在哪个物理核心上，因此客体侧的缓存决策可能被主机覆盖。在客体中运行 cat /sys/devices/system/cpu/cpu*/cache/index3/shared_cpu_list | sort -u。如果所有 vCPU 都显示在同一行，说明该功能没有可供安排的内容。

如何检查内核是否启用了 CONFIG_SCHED_CACHE？

运行 grep -E '^CONFIG_SCHED_CACHE' /boot/config-$(uname -r)。CONFIG_SCHED_CACHE=y 表示该功能已内置，# CONFIG_SCHED_CACHE is not set 表示您的发行版已禁用该功能；没有输出则表示内核版本早于该选项的引入版本。如果镜像中没有 /boot/config-* 文件，请尝试 zcat /proc/config.gz；该文件只存在于使用 CONFIG_IKCONFIG_PROC 构建的内核中。您还可以使用 sudo ls /sys/kernel/debug/sched/ | grep -i llc 在运行时确认；如果功能存在，该命令会列出 llc_* 可调参数。

如何在不重启的情况下关闭缓存感知调度？

将 0 写入容差旋钮：sudo sh -c 'echo 0 > /sys/kernel/debug/sched/llc_aggr_tolerance'。这会在运行时禁用该功能，适合用作基准测试的干净 A/B 开关。先使用 sudo cat /sys/kernel/debug/sched/llc_aggr_tolerance 读取当前值，并在测试后写回该值，因为不同构建的默认值可能不同。写入 debugfs 的内容在重启后不会保留。如果 cat 报告 No such file or directory，说明您的内核未编译该功能，因此没有可关闭的内容。

Ubuntu 或 Debian 何时会发布基于 7.2 的内核？

Fedora 会将稳定版本重新基于新的主线内核构建，因此通常会通过正常的 dnf upgrade 和重启最先获得该功能。Ubuntu 会在每个半年版本中发布新内核，并通过 HWE 堆栈将其提供给之前的 LTS 版本；历史上的时间差接近 1 年：截至 August 2026，24.04 LTS 的 HWE 堆栈使用 6.17，该版本发布于 February 2026，而其 GA 内核仍为 6.8。Debian stable 在整个发行版生命周期内保留一个内核，并通过 trixie-backports 提供更新版本；您可以按软件包使用 apt install -t trixie-backports linux-image-amd64 安装这些内核。

#linux-kernel#scheduler#releases#性能#vps