What's new in Linux kernel 7.2 for a VPS

What's new in Linux kernel 7.2

Linux kernel 7.2 was released on 16 August 2026, and the change worth your attention is cache aware scheduling, built behind the new CONFIG_SCHED_CACHE option. The scheduler now tries to keep the threads of one process on CPUs that share the same last level cache (LLC). Nothing else in the release changes how your workload is placed on a CPU.

The rest of 7.2, in one line: a rework of the ext4 fast commit path, improvements to MGLRU (the multi-generational least recently used memory reclaim code), a new dm-inlinecrypt device mapper target for inline block device encryption, and the removal of the last strncpy() call from the kernel source.

One fact decides whether the headline feature can do anything for you, so it comes first. Cache aware load balancing activates only when a NUMA (non-uniform memory access) node contains more than one LLC. A VPS guest is usually not shown that layout, so on most guests the code is compiled in and never engages. Checking that takes two commands, in "Does a VPS guest see any of this" below.

Every technical claim on this page comes from the 7.2 changelog and from the cache aware scheduling patch series itself, read on 18 August 2026. The sources are listed near the end so you can check them against what your own kernel does.

Why the scheduler needed to know about caches

A modern server socket does not have one last level cache. An AMD EPYC package is built from several core complexes, and each complex has its own L3. Recent Intel Xeon parts also split a socket into more than one cache domain. So a single NUMA node can hold four, eight or more separate LLCs, and two threads of the same program can end up in different ones.

That placement costs time. When two threads share a page from different LLCs, each cache keeps its own copy of the line. A write on one side invalidates the copy on the other side, so the next read has to cross the interconnect or go out to main memory. This is cache bouncing. It shows up as cycles spent waiting, not as CPU idle time, which is why it is easy to miss when you are watching a load average.

Before 7.2 the load balancer placed tasks using load, utilisation and idle CPUs. It had no input that said "these two tasks read the same memory". 7.2 adds one, using an approximation that costs nothing to compute: the threads of a process share one address space, so treat them as likely to share data.

How the kernel picks a preferred LLC

The tracking hangs off the process, in mm_struct, the kernel structure that represents one address space. The kernel periodically samples where the threads of that process are running and counts, per LLC, how much of the process is sitting in each one. The LLC holding the most becomes the preferred LLC for the whole process, and that single number is what later decisions read.

Two paths then use it. On wakeup, the scheduler biases its CPU choice toward the process's preferred LLC instead of taking any idle CPU in the node. During load balancing, when tasks must move between scheduler groups, it prefers to move tasks that already prefer the destination LLC, and it avoids dragging a task away from the LLC it prefers.

The guardrails matter as much as the feature does, because packing every thread of a busy process into one cache domain can leave that domain overloaded while the rest of the socket sits idle. The tunables live in debugfs, the kernel's debug filesystem, under /sys/kernel/debug/sched/:

• llc_aggr_tolerance, a value from 0 to 100, sets how hard the kernel aggregates. 0 turns cache aware scheduling off at runtime. 1 is the careful setting: a process whose RSS (resident set size, its resident memory) is larger than the LLC, or which runs more threads than the LLC has cores, is left where it is. 100 aggregates whatever the size or the thread count.
• llc_overload_pct, default 50, is the average utilisation above which the preferred LLC counts as busy.
• llc_imb_pct, default 20, caps the imbalance an aggregating migration may create once the preferred LLC is past that overload point.
• llc_epoch_period, default 10 ms, is how often occupancy is collected.
• llc_epoch_affinity_timeout, default 50 ms, is how long an inactive process keeps its preference before the kernel drops it.

Read your own values before changing any of them, because a distribution can ship different defaults: sudo cat /sys/kernel/debug/sched/llc_aggr_tolerance.

Which workloads plausibly gain, and which do not

The numbers below are the figures published with the patch series, measured on server class hardware, and some of them with the tolerance knob pushed to an aggressive setting. Read them as the good case on bare metal, not as a promise for your box.

[
  {
    "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 with a single group improved by 30.57%, and the ChaCha20 throughput run on AMD Genoa improved by 44%. All 3 results were taken on multi-LLC server hardware that the tester controlled end to end.

The shape of a workload that gains looks like this:

• More than one thread in a single process, so there is something to group.
• Real sharing between those threads, so a bounced cache line is a cost you are actually paying.
• A working set that fits inside one LLC, because a process larger than the cache cannot be given cache locality by moving it.
• Spare capacity on the machine, so the scheduler has a real choice about where to put the next thread.

And the cases where there is nothing to win:

• A machine already at full capacity. Every CPU is busy, so placement is forced and the reported gains fade.
• Single threaded processes, and pools of independent processes that share no data.
• A working set much larger than the LLC, which the careful llc_aggr_tolerance setting deliberately skips.
• A node that reports one LLC, where the feature never turns on at all.

There is a cost side, and the series is open about it. Collecting occupancy is work done in the context of the task, and some runs showed request latency getting worse because that work delayed the task's return to user space. Aggregation can also raise latency variance even where average throughput improves. If you care about the tail rather than the average, measure your own tail.

Does a VPS guest see any of this

Two facts decide the answer.

First, the feature is gated on topology. Cache aware load balancing is only enabled when more than one LLC exists inside one NUMA node, and the kernel records that during topology setup. Where a node reports a single LLC, the cache aware path stays inactive no matter how the tunables are set.

Second, the cache topology your guest reads is not the host's. It is whatever the hypervisor's CPU model presents. A default KVM (kernel based virtual machine) guest is normally not handed the host's real L3 layout, so the guest is reasoning about a simplified picture.

Check what your own guest sees:

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

index3 is the L3 cache on most x86 CPUs. One line listing every vCPU means the guest sees a single LLC, so the feature has nothing to arrange. No such file or directory means no L3 was exposed to the guest at all, and the guest then treats a lower cache level as its last level, with boundaries the hypervisor invented rather than boundaries the silicon has.

Then there is double scheduling, which is the honest caveat for any tenant. Your guest kernel places threads on vCPUs. The host kernel places those vCPU threads on physical cores. A guest that carefully groups four threads onto vCPU 0 to 3 has expressed a preference about four host threads, and the host is free to place them on different physical cache domains and to move them later. The guest decision is not wrong, it just is not the final one. That is the same layer boundary that produces the steal time a noisy neighbour leaves on your vCPUs.

So where does this feature reach a VPS tenant? Two places. On plans where the topology is real rather than synthetic, such as dedicated cores or larger instances with a passed-through layout, the guest scheduler is making a decision about hardware that exists. And on the provider's own host kernel, where cache aware placement of your vCPU threads is the provider's win to take, not yours. Cache layout also differs by architecture, which is one more variable when you compare an Arm VPS against an x86 VPS.

Measuring cache behaviour inside a guest is harder than on metal. perf stat -e cache-misses often reports <not supported> because the hypervisor does not expose the PMU (performance monitoring unit) to guests. Measure the throughput and latency of your own application instead, and use the debugfs knob as the switch between the two runs.

Check whether your kernel has 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 means your kernel was built with it. A line reading # CONFIG_SCHED_CACHE is not set means the option exists in that version and your distribution turned it off. No output at all usually means the kernel predates the option, and uname -r will confirm that. Some minimal cloud images ship no /boot/config-* file, and there you read zcat /proc/config.gz instead, which works only when the kernel was built with CONFIG_IKCONFIG_PROC.

The ls line prints the llc_* tunables when the feature is compiled in. If it prints nothing while CONFIG_SCHED_CACHE=y, mount debugfs first with sudo mount -t debugfs none /sys/kernel/debug.

To compare your workload with the feature on and off, record the current value first, since you have to put it back:

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

Run your benchmark, write the value you noted back, and run it again. Debugfs writes do not survive a reboot, which is what you want while testing.

When will a distribution kernel carry 7.2

Mainline is not what your VPS boots. The version in uname -r came from your distribution, and each distribution has its own path from a mainline release to your server.

Fedora rebases its stable releases onto new mainline kernels during their supported life, so sudo dnf upgrade --refresh plus a reboot is the whole process there, and it is usually the first place a tenant can try a new kernel. That cadence is part of what you are choosing when you run Fedora Server on a VPS.

Ubuntu ships a new kernel with each six month release, then carries it to the previous long term support (LTS) release through the HWE (hardware enablement) stack. As of August 2026, Ubuntu 24.04 LTS still installs 6.8 from April 2024 as its GA kernel, while its HWE stack moved to 6.14 in August 2025 and to 6.17 in February 2026. That is the realistic timescale: a mainline release from August 2026 reaches an LTS HWE stack about a year later.

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

Debian stable keeps one kernel for the life of the release and offers newer ones through backports, which you opt into per package:

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

After any of these, reboot and confirm with uname -r and the grep above. A new kernel is not live-loadable: live kernel patching on a VPS replaces the code of individual functions in the running kernel, and it cannot change structure layouts or add debugfs files. Cache aware scheduling does both, because it adds fields to mm_struct, so it arrives only by booting a new kernel.

Two practical follow-ups. Keep the old kernel bootable until the new one has carried your load for a while, which is what pinning which kernel boots on a VPS is for. And watch /boot, since a small VPS boot partition fills up after a few kernel upgrades, as covered in cleaning up old kernels on Ubuntu.

One last piece of realism about ownership. On a KVM VPS the guest kernel is yours: you pick it, you boot it, you roll it back. The host kernel is your provider's, and no setting inside your guest changes which scheduler the hypervisor runs. So a release note about scheduler placement is only half a story for a tenant, and the half you control is the guest side.

Sources used for this page

• The 7.2 changelog summary at kernelnewbies.org, for the release date of 16 August 2026 and the non-scheduler changes.
• LWN's coverage of the cache aware scheduling series at lwn.net/Articles/1041668 and lwn.net/Articles/1058288, for the debugfs tunables, the per process preference mechanism and the reported benchmark figures.
• The patch that gates the feature on topology, "sched/cache: Introduce sched_cache_present", for the rule that cache aware load balancing needs more than one LLC in a NUMA node.

For the previous release, see what changed in Linux kernel 7.1. For how the version numbers got here, see the Linux kernel history timeline.

FAQ

Does cache aware scheduling in Linux 7.2 make a VPS faster?

Usually not by itself. The feature only activates when a NUMA node reports more than one last level cache, and a typical KVM guest is not shown that layout, so the code never engages. Where it does engage, the guest is still scheduled twice: your kernel picks a vCPU, and the host kernel decides which physical core that vCPU thread runs on, so a guest side cache decision can be undone by the host. Run cat /sys/devices/system/cpu/cpu*/cache/index3/shared_cpu_list | sort -u in your guest. One line covering every vCPU means there is nothing for the feature to arrange.

How do I check whether my kernel has CONFIG_SCHED_CACHE?

Run grep -E '^CONFIG_SCHED_CACHE' /boot/config-$(uname -r). CONFIG_SCHED_CACHE=y means it is built in, # CONFIG_SCHED_CACHE is not set means your distribution disabled it, and no output means the kernel is older than the option. If the image has no /boot/config-* file, try zcat /proc/config.gz, which exists only on kernels built with CONFIG_IKCONFIG_PROC. You can confirm at runtime with sudo ls /sys/kernel/debug/sched/ | grep -i llc, which lists the llc_* tunables when the feature is present.

How do I turn cache aware scheduling off without rebooting?

Write 0 to the tolerance knob: sudo sh -c 'echo 0 > /sys/kernel/debug/sched/llc_aggr_tolerance'. That disables the feature at runtime, which makes it a clean A/B switch for a benchmark. Read the current value first with sudo cat /sys/kernel/debug/sched/llc_aggr_tolerance and write it back afterwards, because defaults vary between builds. Nothing written to debugfs survives a reboot. If cat reports No such file or directory, your kernel does not have the feature compiled in and there is nothing to turn off.

When will Ubuntu or Debian ship a 7.2 based kernel?

Fedora rebases stable releases onto new mainline kernels, so it arrives there first through a normal dnf upgrade and a reboot. Ubuntu ships new kernels with each six month release and carries them to the previous LTS through the HWE stack, and the historical gap is close to a year: as of August 2026 the 24.04 LTS HWE stack is on 6.17 from February 2026 while its GA kernel is still 6.8. Debian stable keeps one kernel for the release and offers newer ones through trixie-backports, which you install per package with apt install -t trixie-backports linux-image-amd64.