Wat is nieuw in Linux kernel 7.2 voor een VPS?

Wat is er nieuw in Linux kernel 7.2

Linux kernel 7.2 is uitgebracht op 16 augustus 2026. De wijziging die uw aandacht verdient, is cache-aware scheduling, geïmplementeerd achter de nieuwe CONFIG_SCHED_CACHE-optie. De scheduler probeert nu de threads van één proces op CPU's te houden die dezelfde last level cache (LLC) delen. Niets anders in deze release verandert de manier waarop uw workload op een CPU wordt geplaatst.

De rest van 7.2 in één zin: een revisie van het ext4 fast commit-pad, verbeteringen aan MGLRU (de multi-generational least recently used memory reclaim-code), een nieuw dm-inlinecrypt device mapper-target voor inline block device-encryptie, en het verwijderen van de laatste strncpy()-aanroep uit de kernelbroncode.

Eén feit bepaalt of de belangrijkste functie voor u nuttig is, dus dat komt eerst. Cache-aware load balancing wordt alleen geactiveerd wanneer een NUMA-node (non-uniform memory access) meer dan één LLC bevat. Een VPS-gast krijgt die indeling meestal niet te zien, dus op de meeste gastsystemen wordt de code wel gecompileerd, maar nooit ingeschakeld. Dit controleren vereist twee commando's, zie "Ziet een VPS-gast hier iets van" hieronder.

Elke technische bewering op deze pagina is afkomstig uit de 7.2 changelog en de cache-aware scheduling patch-serie zelf, gelezen op 18 augustus 2026. De bronnen staan onderaan vermeld, zodat u deze kunt vergelijken met wat uw eigen kernel doet.

Waarom de scheduler op de hoogte moet zijn van caches

Een moderne serversocket beschikt niet over één enkele last level cache. Een AMD EPYC-pakket is opgebouwd uit meerdere core complexes, waarbij elk complex over een eigen L3-cache beschikt. Recente Intel Xeon-onderdelen verdelen een socket eveneens in meerdere cachedomeinen. Hierdoor kan een enkele NUMA-node vier, acht of meer afzonderlijke LLC's bevatten, waardoor twee threads van hetzelfde programma in verschillende caches terecht kunnen komen.

Deze plaatsing kost tijd. Wanneer twee threads een pagina delen vanuit verschillende LLC's, houdt elke cache een eigen kopie van de regel bij. Een schrijfactie aan de ene kant maakt de kopie aan de andere kant ongeldig, waardoor de volgende leesactie via de interconnect moet verlopen of naar het hoofdgeheugen moet uitwijken. Dit proces staat bekend als cache bouncing. Dit uit zich in cycli die worden besteed aan wachten, niet als CPU-inactiviteit, waardoor het gemakkelijk over het hoofd wordt gezien bij het monitoren van de load average.

Vóór 7.2 plaatste de load balancer taken op basis van belasting, bezettingsgraad en inactieve CPU's. Er was geen input die aangaf dat "deze twee taken hetzelfde geheugen lezen". Versie 7.2 voegt dit toe met behulp van een benadering die geen rekenkracht kost: de threads van een proces delen dezelfde adresruimte, dus behandel ze als zijnde waarschijnlijk data-delend.

Hoe de kernel een voorkeurs-LLC kiest

De tracering is gekoppeld aan het proces, in mm_struct, de kernelstructuur die één adresruimte vertegenwoordigt. De kernel voert periodiek steekproeven uit om te bepalen waar de threads van dat proces draaien en telt per LLC hoeveel van het proces zich in elk daarvan bevindt. De LLC met de grootste bezetting wordt de voorkeurs-LLC voor het gehele proces, en dit getal wordt gebruikt voor latere beslissingen.

Twee paden maken hier vervolgens gebruik van. Bij het ontwaken (wakeup) geeft de scheduler de voorkeur aan een CPU in de voorkeurs-LLC van het proces, in plaats van een willekeurige inactieve CPU in de node te kiezen. Tijdens load balancing, wanneer taken tussen scheduler-groepen moeten worden verplaatst, geeft de scheduler de voorkeur aan taken die de doel-LLC al als voorkeur hebben, en wordt voorkomen dat een taak wordt weggetrokken bij de LLC waar deze de voorkeur aan geeft.

De randvoorwaarden zijn net zo belangrijk als de functie zelf, omdat het samenvoegen van alle threads van een druk proces in één cachedomein dat domein kan overbelasten, terwijl de rest van de socket inactief blijft. De instelbare parameters bevinden zich in debugfs, het debug-bestandssysteem van de kernel, onder /sys/kernel/debug/sched/:

• llc_aggr_tolerance, een waarde van 0 tot 100, bepaalt hoe agressief de kernel aggregeert. 0 schakelt cache-aware scheduling uit tijdens runtime. 1 is de voorzichtige instelling: een proces waarvan de RSS (resident set size, het resident geheugen) groter is dan de LLC, of dat meer threads draait dan de LLC cores heeft, wordt gelaten waar het is. 100 aggregeert ongeacht de grootte of het aantal threads.
• llc_overload_pct, standaard 50, is de gemiddelde bezettingsgraad waarboven de voorkeurs-LLC als bezet wordt beschouwd.
• llc_imb_pct, standaard 20, begrenst de onbalans die een aggregerende migratie mag creëren zodra de voorkeurs-LLC dat overbelastingspunt is gepasseerd.
• llc_epoch_period, standaard 10 ms, is de frequentie waarmee de bezetting wordt verzameld.
• llc_epoch_affinity_timeout, standaard 50 ms, is de tijdsduur dat een inactief proces zijn voorkeur behoudt voordat de kernel deze verwijdert.

Lees uw eigen waarden uit voordat u deze wijzigt, aangezien een distributie andere standaardwaarden kan hanteren: sudo cat /sys/kernel/debug/sched/llc_aggr_tolerance.

Welke workloads profiteren waarschijnlijk, en welke niet

De onderstaande cijfers zijn gepubliceerd bij de patch-serie, gemeten op hardware van serverklasse, waarbij sommige met de tolerantie-instelling op een agressieve stand zijn gezet. Beschouw deze als het best-case scenario op bare metal, niet als een garantie voor uw eigen systeem.

[
  {
    "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 met een enkele groep verbeterde met 30.57%, en de ChaCha20-doorvoer op AMD Genoa verbeterde met 44%. Alle 3 resultaten zijn behaald op multi-LLC serverhardware die de tester volledig in beheer had.

Het profiel van een workload die profiteert ziet er als volgt uit:

• Meer dan één thread in een enkel proces, zodat er iets is om te groeperen.
• Echte uitwisseling tussen die threads, waardoor een 'bounced cache line' een kostenpost is die u daadwerkelijk betaalt.
• Een werkset die in één LLC past, omdat een proces dat groter is dan de cache geen cache-lokaliteit kan krijgen door verplaatsing.
• Vrije capaciteit op de machine, zodat de scheduler een reële keuze heeft waar de volgende thread geplaatst moet worden.

En de gevallen waarin er niets te winnen valt:

• Een machine die al op volledige capaciteit draait. Elke CPU is bezet, waardoor plaatsing geforceerd is en de gerapporteerde winst verdwijnt.
• Single-threaded processen en pools van onafhankelijke processen die geen data delen.
• Een werkset die veel groter is dan de LLC, wat de zorgvuldige llc_aggr_tolerance-instelling bewust overslaat.
• Een node die één LLC rapporteert, waar de functie helemaal niet wordt ingeschakeld.

Er is ook een kostenkant, en de serie is daar transparant over. Het verzamelen van bezettingsgraad is werk dat wordt uitgevoerd in de context van de taak, en sommige runs lieten een verslechtering van de request-latency zien omdat dat werk de terugkeer van de taak naar de user space vertraagde. Aggregatie kan ook de variantie in latency verhogen, zelfs wanneer de gemiddelde doorvoer verbetert. Als u meer waarde hecht aan de tail-latency dan aan het gemiddelde, meet dan uw eigen tail-latency.

Ziet een VPS-gast iets van deze configuratie?

Twee feiten bepalen het antwoord.

Ten eerste is deze functionaliteit afhankelijk van de topologie. Cache-aware load balancing wordt alleen ingeschakeld wanneer er meer dan één LLC aanwezig is binnen één NUMA-node; de kernel legt dit vast tijdens het instellen van de topologie. Waar een node slechts één LLC rapporteert, blijft het cache-aware pad inactief, ongeacht hoe de instellingen zijn geconfigureerd.

Ten tweede is de cache-topologie die uw gast-OS ziet niet die van de host. Het is de topologie die het CPU-model van de hypervisor presenteert. Een standaard KVM (kernel based virtual machine) gast krijgt doorgaans niet de werkelijke L3-indeling van de host te zien, waardoor de gast werkt met een vereenvoudigd beeld.

Controleer wat uw eigen gast ziet:

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

index3 is de L3-cache op de meeste x86 CPU's. Eén regel die elke vCPU vermeldt, betekent dat de gast één enkele LLC ziet, waardoor de functie niets heeft om te verdelen. No such file or directory betekent dat er helemaal geen L3 aan de gast is blootgesteld; de gast beschouwt dan een lager cache-niveau als het laatste niveau, met grenzen die door de hypervisor zijn verzonnen in plaats van grenzen die door de hardware worden bepaald.

Daarnaast is er sprake van dubbele scheduling, wat de belangrijkste kanttekening is voor elke tenant. Uw gast-kernel plaatst threads op vCPU's. De host-kernel plaatst die vCPU-threads op fysieke cores. Een gast die zorgvuldig vier threads groepeert op vCPU 0 tot 3, heeft een voorkeur uitgesproken voor vier host-threads, maar de host is vrij om deze op verschillende fysieke cache-domeinen te plaatsen en ze later te verplaatsen. De beslissing van de gast is niet onjuist, maar het is simpelweg niet de definitieve beslissing. Dit is dezelfde laag-scheiding die zorgt voor de steal time die een luidruchtige buurman op uw vCPU's achterlaat.

Waar raakt deze functionaliteit dus een VPS-tenant? Op twee punten. Bij abonnementen waar de topologie echt is in plaats van synthetisch, zoals bij dedicated cores of grotere instances met een doorgegeven (passed-through) lay-out, neemt de gast-scheduler een beslissing over hardware die daadwerkelijk bestaat. En op de host-kernel van de provider zelf, waar cache-aware plaatsing van uw vCPU-threads een winst is voor de provider, niet voor u. De cache-indeling verschilt bovendien per architectuur, wat een extra variabele is wanneer u een Arm VPS vergelijkt met een x86 VPS.

Het meten van cache-gedrag binnen een gast is lastiger dan op bare metal. perf stat -e cache-misses rapporteert vaak <not supported> omdat de hypervisor de PMU (performance monitoring unit) niet blootstelt aan gasten. Meet in plaats daarvan de doorvoer en latentie van uw eigen applicatie en gebruik de debugfs-knop als schakelaar tussen de twee runs.

Controleer of uw kernel CONFIG_SCHED_CACHE bevat

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 betekent dat uw kernel hiermee is gebouwd. Een regel met # CONFIG_SCHED_CACHE is not set betekent dat de optie in die versie bestaat, maar dat uw distributie deze heeft uitgeschakeld. Als er helemaal geen uitvoer verschijnt, is de kernel doorgaans ouder dan de optie; uname -r zal dit bevestigen. Sommige minimale cloud-images bevatten geen /boot/config-*-bestand; in dat geval leest u zcat /proc/config.gz, wat alleen werkt als de kernel is gebouwd met CONFIG_IKCONFIG_PROC.

De regel ls toont de llc_*-instellingen wanneer de functie is gecompileerd. Als er niets wordt getoond terwijl CONFIG_SCHED_CACHE=y, koppel dan eerst debugfs met sudo mount -t debugfs none /sys/kernel/debug.

Om uw workload te vergelijken met de functie in- en uitgeschakeld, noteert u eerst de huidige waarde, aangezien u deze later moet terugzetten:

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

Voer uw benchmark uit, schrijf de genoteerde waarde terug en voer de benchmark opnieuw uit. Schrijfacties naar debugfs blijven niet behouden na een herstart, wat gewenst is tijdens het testen.

Wanneer bevat een distributie-kernel versie 7.2

Mainline is niet de kernel waarmee uw VPS opstart. De versie in uname -r is afkomstig van uw distributie, en elke distributie volgt een eigen pad van een mainline-release naar uw server.

Fedora baseert zijn stabiele releases tijdens hun ondersteuningsperiode opnieuw op nieuwe mainline-kernels. Daarom is sudo dnf upgrade --refresh in combinatie met een herstart daar het volledige proces, en dit is meestal de eerste plek waar een gebruiker een nieuwe kernel kan uitproberen. Dat tempo is onderdeel van uw keuze wanneer u Fedora Server op een VPS draait.

Ubuntu levert bij elke release van zes maanden een nieuwe kernel en brengt deze vervolgens naar de voorgaande Long Term Support (LTS)-release via de HWE (hardware enablement)-stack. Sinds augustus 2026 installeert Ubuntu 24.04 LTS nog steeds 6.8 uit april 2024 als de GA-kernel, terwijl de HWE-stack in augustus 2025 naar 6.14 en in februari 2026 naar 6.17 is verplaatst. Dat is de realistische tijdslijn: een mainline-release uit augustus 2026 bereikt een LTS HWE-stack ongeveer een jaar later.

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

Debian stable behoudt één kernel gedurende de levensduur van de release en biedt nieuwere versies aan via backports, waarvoor u per pakket kiest:

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

Start na een van deze acties de server opnieuw op en bevestig dit met uname -r en de grep hierboven. Een nieuwe kernel kan niet live worden geladen: live kernel patching op een VPS vervangt de code van individuele functies in de draaiende kernel, maar kan geen structuurlay-outs wijzigen of debugfs-bestanden toevoegen. Cache-aware scheduling doet beide, omdat het velden toevoegt aan mm_struct, waardoor dit alleen beschikbaar komt door een nieuwe kernel op te starten.

Twee praktische vervolgstappen. Houd de oude kernel opstartbaar totdat de nieuwe kernel uw werklast een tijdje stabiel heeft gedraaid; dit is waar het vastzetten van de opstartkernel op een VPS voor dient. En houd /boot in de gaten, aangezien een kleine VPS-opstartpartitie vol raakt na een paar kernel-upgrades, zoals beschreven in het opschonen van oude kernels op Ubuntu.

Nog één laatste punt van realisme over eigenaarschap. Op een KVM VPS is de gast-kernel van u: u kiest deze, u start deze op en u draait wijzigingen terug. De host-kernel is van uw provider, en geen enkele instelling binnen uw gast-systeem verandert welke scheduler de hypervisor gebruikt. Een release-opmerking over scheduler-plaatsing vertelt voor een gebruiker dus slechts de helft van het verhaal, en de helft die u beheert is de gast-zijde.

Bronnen gebruikt voor deze pagina

• De 7.2 changelog-samenvatting op kernelnewbies.org, voor de releasedatum van 16 augustus 2026 en de wijzigingen buiten de scheduler.
• De berichtgeving van LWN over de cache-aware scheduling-reeks op lwn.net/Articles/1041668 en lwn.net/Articles/1058288, voor de debugfs-instellingen, het voorkeursmechanisme per proces en de gerapporteerde benchmarkcijfers.
• De patch die de functie koppelt aan topologie, "sched/cache: Introduce sched_cache_present", voor de regel dat cache-aware load balancing meer dan één LLC in een NUMA-node vereist.

Zie voor de vorige release wat er veranderde in Linux kernel 7.1. Zie voor de totstandkoming van de versienummers de tijdlijn van de Linux kernel-geschiedenis.

FAQ

Maakt cache-aware scheduling in Linux 7.2 een VPS sneller?

Doorgaans niet op zichzelf. Deze functie wordt alleen geactiveerd wanneer een NUMA-node meer dan één last level cache rapporteert. Een standaard KVM-guest krijgt deze lay-out niet te zien, waardoor de code nooit wordt ingeschakeld. Waar dit wel gebeurt, wordt de guest nog steeds dubbel ingepland: uw kernel kiest een vCPU, en de host-kernel bepaalt op welke fysieke core die vCPU-thread draait. Een beslissing op guest-niveau kan dus door de host ongedaan worden gemaakt. Voer cat /sys/devices/system/cpu/cpu*/cache/index3/shared_cpu_list | sort -u uit in uw guest. Eén regel die alle vCPU's beslaat, betekent dat er niets is voor de functie om te regelen.

Hoe controleer ik of mijn kernel CONFIG_SCHED_CACHE bevat?

Voer grep -E '^CONFIG_SCHED_CACHE' /boot/config-$(uname -r) uit. CONFIG_SCHED_CACHE=y betekent dat het is ingebouwd, # CONFIG_SCHED_CACHE is not set betekent dat uw distributie het heeft uitgeschakeld, en geen uitvoer betekent dat de kernel ouder is dan de optie. Als de image geen /boot/config-*-bestand heeft, probeer dan zcat /proc/config.gz; dit bestaat alleen op kernels die zijn gebouwd met CONFIG_IKCONFIG_PROC. U kunt dit tijdens runtime bevestigen met sudo ls /sys/kernel/debug/sched/ | grep -i llc, dat de llc_*-instellingen toont wanneer de functie aanwezig is.

Hoe schakel ik cache-aware scheduling uit zonder te herstarten?

Schrijf 0 naar de tolerantie-instelling: sudo sh -c 'echo 0 > /sys/kernel/debug/sched/llc_aggr_tolerance'. Dit schakelt de functie tijdens runtime uit, wat het een geschikte A/B-schakelaar maakt voor een benchmark. Lees eerst de huidige waarde met sudo cat /sys/kernel/debug/sched/llc_aggr_tolerance en schrijf deze achteraf terug, omdat standaardwaarden per build verschillen. Niets dat naar debugfs wordt geschreven, overleeft een herstart. Als cat de melding No such file or directory geeft, is de functie niet in uw kernel gecompileerd en is er niets uit te schakelen.

Wanneer brengt Ubuntu of Debian een kernel gebaseerd op 7.2 uit?

Fedora rebaseert stabiele releases op nieuwe mainline-kernels, dus daar komt het als eerste aan via een normale dnf upgrade en een herstart. Ubuntu brengt elke zes maanden nieuwe kernels uit en voert deze door naar de vorige LTS via de HWE-stack. De historische kloof is ongeveer een jaar: per augustus 2026 zit de 24.04 LTS HWE-stack op 6.17 van februari 2026, terwijl de GA-kernel nog 6.8 is. Debian stable behoudt één kernel voor de release en biedt nieuwere aan via trixie-backports, die u per pakket installeert met apt install -t trixie-backports linux-image-amd64.