In de wereld van systeemprestaties leiden niet altijd grote herschreven codes tot de grootste verbeteringen. Soms is het verschil slechts een detail dat schoon genoeg lijkt: waar “onderbrekingen” vallen. Juist daar zijn ingenieurs bij Intel bezig met een wijziging in de Linux-kernel om de opslagprestaties van NVMe op moderne servers met hoge kerntelling te verbeteren.
Het probleem ontstaat wanneer het aantal IRQs voor NVMe kleiner is dan het aantal CPU’s, wat op huidige platforms vaak voorkomt. In dat geval delen meerdere cores dezelfde onderbreking, en als de affiniteit voor deze IRQ niet goed is afgestemd op de topologie van de processor, betaal je dat met hogere latentie en verminderde prestaties. Intel vat het samen met een simpele gedachte: wanneer de onderbreking en de “groep” van CPU niet dicht bij elkaar liggen (qua caches en localiteit), ontstaan er nadelen.
Het knelpunt: gedeelde IRQs en de “echte” CPU-topologie
De Linux-kernel heeft al mechanismen om affiniteiten te verdelen, maar de realiteit van moderne processoren is dat “NUMA” niet alles meer verklaart. Binnen één NUMA-domein kunnen cores georganiseerd worden in clusters (bijvoorbeeld groepen cores die een gedeelde cache hebben). Afhankelijk van de werkverdeling kan een “platte” aanpak leiden tot het overschrijden van interne grenzen die niet zouden moeten worden overschreden.
In een praktijkvoorbeeld uit de Linux-kernel mailinglijst wordt beschreven dat op een CPU 4 cores een L2-cache delen, wat een cluster vormt. Indien Linux affiniteit verdeelt zonder rekening te houden met dat clustering, kan een onderbreking “springen” tussen clusters en de lokaleertie verslechteren.
Met andere woorden: het is niet voldoende om de IRQ “binnen hetzelfde NUMA” te plaatsen. In systemen met meerdere clusters binnen één NUMA-domein kan het zelfs beter zijn dat de onderbreking wordt afgehandeld door een “buur” core.
Wat verandert er door de patch: Linux wordt “clustergedreven”
De voorgestelde verbetering zorgt ervoor dat de code in de kernel, die CPU’s groepeert voor affiniteiten (in lib/group_cpus.c), bewuster wordt van clusters binnen elk NUMA-domein. Het doel is om cores slimmer te groeperen, zodat de toewijzing van IRQs voor NVMe een betere localiteit behoudt tussen CPU en onderbreking.
De Intel-ingenieur Wangyang Guo legt uit: naarmate het aantal cores toeneemt, kunnen er minder IRQs voor NVMe beschikbaar zijn dan cores, waardoor meerdere cores een onderbreking delen. Wanneer de affiniteit niet overeenkomt met het juiste cluster, ontstaat er een prestatiepenalty. Deze patch probeert dat te verbeteren door cores binnen hetzelfde NUMA te clusteren.
Opvallend resultaat: +15% bij willekeurige reads met FIO
Uit publieke tests bleek dat deze wijziging ongeveer 15% betere prestaties liet zien bij willekeurige leesbewerkingen met FIO en libaio op een Intel Xeon E-server.
Het is een veelbelovende uitkomst, al moet opgemerkt worden dat dit resultaat voorlopig geldt voor een specifiek geval. Er ontbreken nog gegevens voor andere I/O-profielen (sequentieel, gemengd, schrijfoperaties) en voor een breed scala aan hardwareplatforms. Toch sluit dit aan bij een duidelijke trend: de systeemprestaties worden niet alleen bepaald door het apparaat, maar ook door de “mentale route” die elk evenement aflegt binnen het systeem.
Waarom dit belangrijk is voor systeembeheerders en architecten
Voor systeembeheerders is de praktische conclusie helder: de affiniteit voor IRQ geen cosmetisch detail in NVMe-omgevingen met hoog parallelisme. Bij veel cores, NVMe-queues en intensieve I/O-belasting (databases, virtualisatieopslag, ingest quelen, analytics) kan een suboptimale toewijzing stilletjes voor een knelpunt zorgen.
Deze optimalisaties passen ook bij de operationele realiteit: in veel infrastructuren is NVMe niet langer “de snelle component”, maar een onderdeel dat vereist dat de rest (scheduler, affiniteiten, queues, NUMA, caches) goed is afgestemd om geen prestatieverlies te lijden.
Wat kun je nu al controleren, zonder te wachten op nieuwe kernels
Terwijl deze wijziging zich verder ontwikkelt, zijn er al praktische controles die in systemen met NVMe kunnen aangeven waar verbetering mogelijk is:
- Verdeling van onderbrekingen: controleer of één of meerdere IRQs voor NVMe de belasting te veel concentreren of tussen CPU’s “springen”.
- Afhankelijkheid en NUMA: kijk of IRQs van NVMe worden afgehandeld door CPU’s binnen het meest logische NUMA-knooppunt voor dat apparaat (vooral bij systemen met meerdere sockets).
- Gedrag van
irqbalance: in sommige omgevingen kan standaardbeleid niet optimaal zijn voor deterministische werkbelasting; elders helpt het juist om concentraties te voorkomen.
Hoewel er geen universeel recept bestaat, wordt duidelijk dat in systemen met veel cores topologie een grote rol speelt. Elke generatie processor voegt meer interne lagen toe (clusters, chiplets, CCX/tiles), die niet altijd goed worden weergegeven door oudere heuristieken.
Status van de verandering: in “mm-everything” en klaar voor integratie
Volgens de beschikbare informatie bevindt de patch zich in de “mm-everything”-tak, onder beheer van Andrew Morton. Het heeft potentieel voor een volgende integratieronde in de kernel (waarschijnlijk in Linux 6.20 of zelfs 7.0, afhankelijk van verdere ontwikkeling en goedkeuring).
Zoals vaak bij dergelijke optimalisaties, zal de daadwerkelijke impact het beste zichtbaar worden zodra meer gebruikers het testen onder verschillende configuraties: diverse CPU-topologieën, meerdere sockets, uiteenlopende NVMe controllers en echte workloads (geen microbenchmarks alleen). Het uitgangspunt is echter correct: verbeteren betekent niet altijd meer IOPS, maar soms juist minder interne frictie.
Veelgestelde vragen
Voor wie is deze NVMe-verbetering in Linux vooral relevant?
Voor systemen met veel cores waar het aantal IRQs/queues niet mee schommelt, wat leidt tot gedeelde IRQs en mogelijk prestatie-penalties door een slechte topologie-afstemming.
Wat betekent “CPU cluster-aware” in dit geval?
Dat het kernel probeert CPU’s te groeperen op clusters binnen elk NUMA-domein voor een betere toewijzing van IRQ-affiniteiten, bijvoorbeeld door het vermijden van sprongen tussen groepen cores die interne caches delen.
Is het +15% prestatiewinst algemeen toepasbaar op elke server?
Nee, dat resultaat werd gemeten op een Intel Xeon E met FIO/libaio bij willekeurige reads. Er zijn nog geen uitgebreide tests voor andere workloads of hardware waarop dat percentage gegarandeerd kan worden.
Wanneer zou deze verandering in de stabiele kernel kunnen verschijnen?
De patch staat in de “mm-everything”-tak en wordt als kandidaat voor een volgende kernel-release gezien, mogelijk in Linux 6.20 of 7.0 (afhankelijk van verdere review en acceptatie).