Ga naar de inhoud 
Ik leg het uit tickless-modus van de Linux-kernel op een begrijpelijke manier uitleggen en laten zien wanneer deze een positieve invloed heeft op prestaties, latentie en energieverbruik. Daarbij noem ik duidelijke voordelen, mogelijke risico’s en concrete afstemmingsstappen die ik in de praktijk toepas.
Centrale punten
Ik vat de belangrijkste samen Kernonderwerpen kort samengevat, zodat je meteen weet waar je op moet letten. De Linux-scheduler en de dynamische tick zijn nauw met elkaar verweven en bepalen het gedrag van je CPU's. Afhankelijk van de workload beslis ik of ‘Tickless Idle’ voldoende is of dat ik ‘Full Tickless’ met geïsoleerde kernen gebruik. Voor reproduceerbare resultaten plan ik housekeeping-CPU’s, IRQ-affiniteit en RCU-callbacks zorgvuldig in. Uiteindelijk telt wat de meetwaarden voor latentie, energieverbruik en doorvoer in je Setup echt laten zien.
- Tickless-stationair draaien: minder tics bij stationair draaien
- NO_HZ_FULL: rustige, afgelegen buurten
- IRQ-affiniteit: Storingsbronnen bundelen
- CPU pinning: Threads vast toewijzen
- Gemeten waarden: latentie, energie, jitter
De lijst toont de bedieningshendels die ik als eerste controleer en combineer. Zo kan ik snel zien waar de grootste Hendel ligt en in hoeverre ik de kernel aanpas.
Wat de kernel-tick in de praktijk teweegbrengt
Een periodieke tick activeert in de kernel de tijdmeting, het timerbeheer en nieuwe Planning-beslissingen. Het is eenvoudig, maar het wekt de kernel ook op als er geen zinvol werk te doen is. Met ‘tickless’ plant de kernel het volgende ontwaken op basis van de behoefte en voorkomt zo onnodige Onderbrekingen. Zo blijven CPU's langer in diepe C-states en veroorzaken ze minder jitter bij latentiegevoelige taken. Ik maak gebruik van dit mechanisme om rustige uitvoeringsvensters te creëren voor gevoelige threads.
Varianten: Tickless Idle en NO_HZ_FULL in een oogopslag
Tickless-stationair draaien (CONFIG_NO_HZ_IDLE) schakelt de regelmatige tick uit zodra een CPU inactief is. Dit vermindert het stroomverbruik en de warmteontwikkeling, omdat de processor minder vaak uit de diepe slaapstand wordt gehaald. NO_HZ_FULL gaat verder en vermindert zelfs het aantal ticks op actieve kernen wanneer daar slechts één taak draait. Hiervoor isoleer ik deze kernen strikt en verplaats ik systeemwerk naar speciale housekeeping-CPU's. Wie zorgt voor een goede isolatie, krijgt zeer stille kernen en daarmee een betere voorspelbaarheid onder belasting.
Vergelijkingstabel en toepassingsscenario’s
Het volgende overzicht helpt me om de juiste Modus afhankelijk van het doel te kiezen en de benodigde omgeving correct voor te bereiden. Ik kijk eerst naar de kenmerken van de workload, vervolgens naar de energiedoelstellingen en ten slotte naar de jitter-tolerantie. Uit ervaring blijkt dat duidelijke CPU-isolatie vooral bij trading, HPC en toepassingen met zeer lage latentie Netwerk-Stacks uit. In het datacenter, waar de belasting varieert, levert Tickless Idle daarentegen vaak de snelste besparing op. Full Tickless bewaar ik voor streng gecontroleerde hosts, waarop ik systeembewerkingen betrouwbaar afscherm.
| Modus | Wanneer actief | Voordeel | Risico | Geschikt voor |
|---|---|---|---|---|
| Periodieke tik | Altijd een vaste frequentie | Eenvoudig Administratie | Meer jitter en wake-ups | Algemene servers |
| Tickless Idle (NO_HZ_IDLE) | Alleen bij stationair draaien | Minder energie, koeler CPU's | Beperkte verbetering van de latentie | VM-hosts, web, gemengd |
| Volledig tickloos (NO_HZ_FULL) | Ook bij single-task-belasting | Zeer rustige kernen, weinig Jitter | Uitgebreide isolatie nodig | HPC, handel, bijna realtime |
Wanneer de tickless-modus uitblinkt
Ik schakel Full Tickless in op geïsoleerde cores wanneer een toepassing extreem Lage latentie moet reageren. Hiertoe behoren order-matching, pakketverwerking met single-queue of strikte NUMA-lokalisatie in wetenschappelijke codes. Bij energiedoelstellingen op gemengde hosts volstaat vaak tickless idle voor meetbare Besparingen. Wie veel slaapfasen ziet, heeft daar veel baat bij, omdat C-states minder vaak door ticks worden verlaten. Lees gerust mijn handleiding over Energie-efficiëntie met Tickless, vooral als je de elektriciteitskosten wilt verlagen.
Voordelen en bijwerkingen in het dagelijks leven
Minder periodieke ticks betekenen minder Contextverandering en vaak gelijkmatigere looptijden. In isolatieopstellingen neemt het OS-ruis af, waardoor gevoelige code consistenter reageert. Volgens de Linux Foundation en de kernel-documentatie levert NO_HZ_IDLE aanzienlijke voordelen op bij inactiviteit, terwijl NO_HZ_FULL de storingsimpulsen verder vermindert. HPC-documentatie bevestigt het effect in combinatie met pinning en IRQ-bundeling op housekeeping-kernen. Wie metingen zorgvuldig opzet, ziet deze effecten duidelijk terug in de latentie- en energieprofielen van de Hosts.
Risico’s door verkeerde tuning
Ik zie problemen ontstaan als IRQ's of RCU-callbacks toch op geïsoleerde kernels terechtkomen en de Rust vernietigen. Dan keert het voordeel zich om, omdat storingsbelasting ongecoördineerd optreedt en jitter veroorzaakt. Ongeplande achtergronddiensten, timers of watchdogs op geïsoleerde CPU’s hebben een vergelijkbaar storend effect. Ook gemengde workloads met veel korte taken verspreiden de onrust zo wijd dat ‘Full Tickless’ weinig oplevert. Daarom plan ik housekeeping-kernen duidelijk in en test ik elke stap met realistische Profielen.
Belangrijke kernelopties op een begrijpelijke manier uitgelegd
Met CONFIG_NO_HZ_IDLE schakel ik de tick in de vrijloop uit en boek ik snel winst zonder ingrijpende aanpassingen. CONFIG_NO_HZ_FULL Ik activeer dit alleen als ik cores strikt isoleer en ‘schone’ housekeeping-CPU’s definieer. De opstartparameter `nohz_full` bepaalt welke cores tickless draaien; `isolcpus` koppelt ze los van de algemene scheduling. rcu_nocbs verplaatst RCU-callbacks weg van deze kernen, terwijl irqaffinity de interrupt-verantwoordelijkheid instelt. Pas in combinatie werkt de opstelling consistent en dus echt nuttig.
Housekeeping-kernactiviteiten plannen
Ik reserveer één of twee kernen per NUMA-node als ‘housekeeping’-zone voor IRQ’s, kernel-threads en RCU. Deze cores nemen de onvermijdelijke systeemtaken voor hun rekening en houden de geïsoleerde kernen vrij. Daartoe koppel ik services en IRQ-wachtrijen bewust aan de ‘housekeeping’-CPU’s en blokkeer ik ze op de stille cores. Wie de CPU-schedulerklassen begrijpt, stuurt prioriteiten en eerlijkheid op betrouwbare wijze aan. Zo blijven de latentiepaden kort en leveren de rustige kernen voorspelbare Reactietijden.
Praktische gids: Stap voor stap
Ik begin elk project met een duidelijk Basislijn-Run: latentie, energieverbruik, doorvoersnelheid, jitter. Daarna controleer ik of NO_HZ_IDLE actief is en of de kernel NO_HZ_FULL ondersteunt. Vervolgens wijs ik IRQ-affiniteit toe, stel ik rcu_nocbs in en plan ik housekeeping-CPU’s in. Pas daarna isoleer ik bij wijze van test enkele kernen met nohz_full en vergelijk ik de resultaten. Voor de gedetailleerde analyse helpt deze handleiding mij bij Latentie meten, zodat ik elke wijziging zorgvuldig kan beoordelen.
Meetmethoden en KPI's
Ik meet end-to-end-Latency met histogrammen en kwantileer uitschieters, in plaats van alleen naar gemiddelde waarden te kijken. PPS en tail-latency beoordeel ik samen, zodat rustige kernen de doorvoer niet drukken. Energie meet ik via RAPL, IPMI of een aangesloten meter en bereken de besparing in Euro per maand. Voorbeeld: als een host 12 W bespaart bij 24/7-bedrijf, komt dat bij 0,30 €/kWh neer op ongeveer 3,15 € per maand per machine. Bij 200 hosts loopt dat op tot een aanzienlijk bedrag van 630 € per maand.
Een diepere blik: hoe de kernel ticks werkelijk uitschakelt
Achter Tickless schuilt de overstap van de periodieke tick naar een Oneshot-klokevenement: De kernel programmeert de volgende „gebeurtenis“ precies op het vroegste tijdstip waarop een timer afloopt of een schedulerbeslissing wordt genomen. High-Resolution-Timers (hrtimer) maken een fijne granulariteit mogelijk. Op een NO_HZ_FULL-CPU: de periodieke scheduler-tick wordt overgeslagen zolang er slechts één taak draait en er geen kernelwerk is. Zodra twee of meer taken uitvoerbaar zijn, start de kernel de tick weer op, zodat de eerlijkheid en de tijdsverdeling kloppen. Juist deze dynamiek maakt het systeem stiller, zonder dat dit ten koste gaat van de juistheid van de planning.
HZ, High-Res-timer en tijdrekening
De kernelconstante HZ (meestal 250 of 1000) bepaalt de frequentie van de klassieke tick. Met ‘tickless’ verliest Hz zijn praktische betekenis voor kernen waarbij de looptijd cruciaal is, maar blijft het relevant voor op jiffies gebaseerde logica. Belangrijk is ook de Tijdtoewijzing (VTIME/Context Tracking): Om ervoor te zorgen dat de gebruikstijd en de systeemtijd correct worden bijgehouden, houdt de kernel nauwkeurig bij wanneer een taak zich in de kernel of in de gebruikersruimte bevindt – zonder permanente tick. Wie veel met profilering werkt, moet dit in gedachten houden om metingen correct te kunnen interpreteren.
Energiebesparingsmechanismen en tickless
Tickless levert alleen een energiebesparend effect op als het platform diep C-staten betrouwbaar bereikt. Daarom controleer ik de firmware- en kernelinstellingen met betrekking tot intel_pstate/amd-pstate, turbomodi en cpufreq-Governor. Een agressieve performance-governor kan de latentie verlagen, maar energie-doelstellingen in de weg staan. Omgekeerd kan een te trage powersave-governor ten koste gaan van de doorvoersnelheid. Mijn aanpak: eerst de tickless-configuratie stabiliseren, daarna systematisch P- en C-state-tuning testen, telkens met identieke workloadprofielen.
Virtualisatie en containers
Op hypervisor-hosts zorgt Tickless-stationair draaien vaak direct merkbare besparingen, omdat inactieve vCPU's minder vaak worden geactiveerd. Voor NO_HZ_FULL Ik isoleer fysieke kernen en wijs vCPU’s van de kritieke VM’s precies daar toe. Belangrijk: Steal-Time en host-IRQ’s mogen deze kernen niet verstoren. In gasten heeft Full Tickless alleen zin als de host de CPU-tijd deterministisch toewijst. In containeromgevingen repliceer ik de isolatielogica met cgroups CPU-sets en voorkom dat Systempods of Sidecars de stille kernen bezetten.
Netwerk- en opslagpaden optimaliseren
Voor ultralage latenties bundel ik RX/TX-wachtrijen en hun IRQ’s op housekeeping-CPU’s. Op de rustige cores werk ik bij voorkeur met userspace-polling of speciale completion-threads, in plaats van IRQ’s toe te staan. Bij NVMe kan IO-wachtrij-affiniteit op dezelfde manier helpen. NAPI-Busy-Polling kan doelgericht worden ingezet wanneer polling-jitter beter voorspelbaar is dan interrupt-jitter. Het doel is dat de geïsoleerde kernen nooit onverwacht door externe gebeurtenissen worden geactiveerd.
Voorbeeld: opstartparameters en pinning
Zo schets ik een minimale configuratie (bijvoorbeeld 16 cores, CPU 0-1 voor huishoudelijke taken; 2-7 en 10-15 als kandidaten voor de werklast; 8-9 voor systeemservices):
GRUB_CMDLINE_LINUX="nohz_full=2-7,10-15 rcu_nocbs=2-7,10-15 isolcpus=2-7,10-15 irqaffinity=0-1"Na de boot pas ik Affinity en CPUsets consequent toe:
# IRQ's bundelen
for i in $(grep -E 'eth0|nvme' /proc/interrupts | awk -F: '{print $1}'); do
echo 3 > /proc/irq/$i/smp_affinity_list # CPU 0-1
done
# Een latentiegevoelige dienst vastpinnen
taskset -c 2-3 /usr/bin/mijn_service
# cgroup-cpuset voor systeemservices (voorbeeld)
mkdir -p /sys/fs/cgroup/cpuset/housekeeping
echo 0-1,8-9 > /sys/fs/cgroup/cpuset/housekeeping/cpuset.cpus
echo 0 > /sys/fs/cgroup/cpuset/housekeeping/cpuset.mems
echo $$ > /sys/fs/cgroup/cpuset/housekeeping/cgroup.procsIn systemd-units gebruik ik daarnaast CPUAffiniteit= of AllowedCPUs=, zodat diensten altijd de juiste kernels gebruiken.
Diagnose: controleren of de kernen echt stil zijn
Ik controleer de ruststatus van mijn cores in een paar eenvoudige stappen: – /proc/interrupts: Stijgt de teller op geïsoleerde CPU’s? Zo ja, corrigeer dan de IRQ-affiniteit. – /proc/timer_list: identificeer onverwachte timers op NO_HZ_FULL-kernen. – ftrace/perf: maak wake-ups, softirqs en sched-events zichtbaar. – turbostat: controleer de verblijftijden in C-state. Als er op rustige cores nog steeds softirqs (NET_RX, TIMER) binnenkomen, is er vrijwel altijd sprake van een distributie- of stuurprogramma-probleem.
Interactie met PREEMPT_RT en RT-Threads
PREEMPT_RT vermindert latentie door preemptie diep in de kernel te integreren. In combinatie met NO_HZ_FULL kan dit zeer goede resultaten opleveren wanneer IRQ’s als threads draaien en strikt op housekeeping-CPU’s blijven. Belangrijk: verspreid RT-threads niet te wijd, maar pin ze strak vast en houd hun geheugenpaden (NUMA, page-faults) onder controle. Ik houd RT-threads op geïsoleerde kernen altijd „alleen“, zodat er geen tick terugkeert omdat er een tweede uitvoerbare taak ontstaat.
Wanneer ‘Full Tickless’ niet de moeite waard is
Ik zie af van NO_HZ_FULL als: – Er voortdurend veel kortstondige taken ontstaan (bijv. Fork/Exec-bursts). – De workload sterk gesynchroniseerd is en voortdurend kernwisselingen afdwingt. – Het platform geen zuivere C-states bereikt of TSC onstabiel is. In dergelijke gevallen levert zuiver IRQ- en CPU-pinning vaak meer dan de kosten van een volledige isolatie.
Fijne details in de productie: monitoring en exploitatie
In productieomgevingen waarschuw ik voor „sluipende“ veranderingen: een kernel-update, een nieuwe agent of een gewijzigde IRQ-toewijzing kan de rust van de kernen verstoren. Daarom implementeer ik: – Een „Guardrail“-script dat na een reboot de affiniteit, CPU-sets en RCU-instellingen controleert. – Metrics voor wake-ups per seconde, C-state-verblijftijden en p99,9-latentie. – Periodieke Regressietests met identieke workloads. Alleen zo blijft het voordeel van de tickless-modus betrouwbaar behouden.
Jitterbronnen doelgericht neutraliseren
Naast IRQ's zorgen vaak Timer in de gebruikersruimte (sleep/usleep/timerfd) voor onregelmatige patronen. Ik werk met timer slack (prctl of /proc) en groepeer vervaldata, zodat de kernel minder afzonderlijke wake-ups inplant. Ook plan ik achtergrond-GC’s in managed runtimes (JVM, Go) in of isoleer ik ze op housekeeping-kernen. Het doel is altijd om op NO_HZ_FULL-kernen alleen de absoluut noodzakelijke wake-ups toe te staan.
Interpretatie van de KPI's: afwegingen zichtbaar maken
Ik beoordeel niet alleen gemiddelden, maar ook de Distributie: p50, p95, p99,9 en maximaal. Een typisch succespatroon: de tail-latentie daalt aanzienlijk, de gemiddelde doorvoer blijft gelijk of stijgt licht, en de C-state-verblijfsduur neemt af. Zie ik daarentegen wel verbeterde jitter, maar merkbaar minder doorvoer, dan pas ik het CPU-frequentiebeleid aan of verhoog ik voorzichtig het aantal inactieve kernen, zodat wachtrijen niet verstopt raken.
Checklist voordat NO_HZ_FULL wordt geactiveerd
– Kernelfuncties: CONFIG_NO_HZ_FULL, High-Res-Timer ingeschakeld
– Duidelijke CPU-rollen: housekeeping-CPU's per NUMA-node gedefinieerd
– IRQ- en RCU-offload: irqaffinity en rcu_nocbs consistent ingesteld
– Plaatsing van diensten: pinning van systemd/cgroups gedocumenteerd en getest
– Meetopstelling: reproduceerbare workloads, zinvolle KPI’s, vergelijking voor/na
– Rollback-plan: opstartvermelding beschikbaar zonder NO_HZ_FULL
Veelvoorkomende struikelblokken en oplossingen
Ik zie vaak dat systeemservices op afzonderlijke cores draaien en dat de Isolatie ontkrachten. Dit kan worden voorkomen met systemd-affinity, cgroups-CPUsets en duidelijke documentatie over services. Ook verkeerde NUMA-toewijzingen leiden tot onnodige toegang op afstand en pieken in de latentie. Ik koppel geheugen en threads strikt aan de betreffende node, zodat paden kort en consistent blijven blijf. Een onduidelijke IRQ-verdeling is de derde veelvoorkomende oorzaak, daarom bundel ik drukke wachtrijen op housekeeping-CPU's.
Korte balans voor de praktijk
De tickless De kernel vermindert storende ticks, bespaart energie en creëert betrouwbare tijdvensters voor gevoelige workloads. Met ‘Tickless Idle’ realiseer ik snel efficiëntiewinst, terwijl ‘Full Tickless’ extra rust brengt op geïsoleerde cores. Het grootste effect zie ik wanneer ik IRQ’s, RCU en achtergrondtaken netjes bundel op housekeeping-CPU’s. Zonder metingen lukt het niet: latentie, jitter, energieverbruik en doorvoer laten me zien of de afstemming vruchten afwerpt. Zo pas ik de tickless-modus doelgericht toe en haal ik het maximale uit de planner uit.
