Le mode « tickless » du planificateur du noyau expliqué : avantages, risques et réglages

Je vais expliquer le mode sans tick du noyau Linux de manière compréhensible et j'explique dans quels cas il a un impact positif sur les performances, la latence et la consommation d'énergie. À cet effet, j'énumère les avantages évidents, les risques potentiels et les étapes concrètes d'optimisation que j'utilise moi-même et qui ont fait leurs preuves dans la pratique.

Points centraux

Je résume les principaux Thèmes principaux résumés de manière concise pour que tu saches immédiatement à quoi tu dois faire attention. Le planificateur Linux et le « dynamic tick » sont étroitement liés et déterminent le comportement de ton CPUs. En fonction de la charge de travail, je décide si le mode « Tickless Idle » suffit ou si j’utilise le mode « Full Tickless » avec des cœurs isolés. Pour obtenir des résultats reproductibles, je planifie soigneusement les processeurs de gestion interne, l’affinité IRQ et les callbacks RCU. Au final, ce qui compte, ce sont les valeurs mesurées en matière de latence, de consommation d'énergie et de débit dans ton Configuration montrer vraiment.

• Ralenti sans impulsion: moins de cliquetis au ralenti
• NO_HZ_FULL: des quartiers calmes et isolés
• Affinité IRQ: Regrouper les sources de perturbations
• Épinglage du CPU: Attribuer définitivement des threads
• Valeurs mesurées: latence, énergie, gigue

Cette liste répertorie les leviers de commande que je vérifie et combine en premier lieu. Cela me permet d'identifier rapidement où se situe le plus grand Levier et dans quelle mesure je personnalise le noyau.

Ce que le « tick » du noyau implique concrètement

Un tick périodique déclenche, au niveau du noyau, la mesure du temps, la gestion des temporisateurs et de nouvelles planification-décisions. Il est simple, mais il réveille les noyaux même lorsqu'aucune tâche utile n'est en attente. Avec le mode « tickless », le noyau planifie le prochain réveil en fonction des besoins et évite ainsi les Interruptions. Ainsi, les processeurs restent plus longtemps dans des états C profonds et génèrent moins de jitter pour les tâches où la latence est critique. J'utilise ce mécanisme pour créer des fenêtres d'exécution calmes pour les threads sensibles.

Variantes : aperçu de « Tickless Idle » et « NO_HZ_FULL »

Ralenti sans impulsion (CONFIG_NO_HZ_IDLE) désactive le tick régulier dès qu'un processeur est inactif. Cela réduit la consommation électrique et la chaleur, car le processeur est moins souvent sorti de son état de veille profonde. NO_HZ_FULL Cela va plus loin et réduit même le nombre de ticks sur les cœurs actifs lorsqu'une seule tâche y est exécutée. Pour ce faire, j'isole strictement ces cœurs et je transfère les tâches système vers des processeurs dédiés à la gestion interne. Une isolation rigoureuse permet d'obtenir des cœurs très silencieux et donc une meilleure prévisibilité sous charge.

Tableau comparatif et scénarios d'utilisation

Le tableau suivant m'aide à trouver le bon Mode choisir en fonction de l'objectif visé et préparer correctement l'environnement nécessaire. Je m'intéresse d'abord aux caractéristiques de la charge de travail, puis aux objectifs énergétiques et enfin à la tolérance à la gigue. D'après mon expérience, une isolation claire des processeurs s'avère particulièrement utile pour le trading, le calcul haute performance (HPC) et les applications à très faible latence Réseau-Stacks. Dans un centre de données où la charge varie, le mode « Tickless Idle » permet en revanche souvent de réaliser des économies plus rapidement. Je réserve le mode « Full Tickless » aux hôtes strictement contrôlés, sur lesquels je sépare de manière fiable les tâches système.

Mode	Quand est-il actif ?	Avantage	Risque	Convient pour
Tick périodique	Toujours, fréquence fixe en Hz	Simple Administration	Plus de jitter et de réveils	Serveurs généraux
Ralenti sans impulsion d'horloge (NO_HZ_IDLE)	Uniquement au ralenti	Moins d'énergie, plus de fraîcheur CPUs	Gain de latence limité	Hôtes VM, Web, Mixte
Full Tickless (NO_HZ_FULL)	Même en cas de charge de travail mono-tâche	Des quartiers très calmes, peu de Jitter	Une isolation complexe est nécessaire	HPC, trading, temps quasi réel

Quand le mode « tickless » fait des étincelles

J'active le mode « Full Tickless » sur des cœurs isolés lorsqu'une application est extrêmement faible latence doit réagir. Parmi celles-ci figurent la mise en correspondance des ordres, le traitement par paquets avec file d’attente unique ou la localisation NUMA stricte dans les codes scientifiques. Lorsque les objectifs énergétiques concernent des hôtes mixtes, le mode « Tickless Idle » suffit souvent pour obtenir des gains mesurables Économies. Ceux qui constatent de nombreuses phases de veille en tirent un grand avantage, car les états C sont moins souvent quittés par les ticks. N'hésite pas à consulter mon guide sur Efficacité énergétique avec Tickless, surtout si tu souhaites réduire tes factures d'électricité.

Avantages et effets secondaires au quotidien

Moins de ticks périodiques, c'est moins Changement de contexte und oft gleichmäßere Laufzeiten. In Isolations-Setups sinkt OS-Rauschen, sodass sensibler Code konsistenter reagiert. Laut Linux Foundation und Kernel-Dokumentation liefert NO_HZ_IDLE deutliche Idle-Gewinne, während NO_HZ_FULL die Störimpulse weiter reduziert. HPC-Unterlagen bestätigen die Wirkung in Kombination mit Pinning und IRQ-Bündelung auf Housekeeping-Kernen. Wer Messungen sauber aufsetzt, erkennt diese Effekte klar in Latenz- und Energieprofilen der Hôtes.

Risiken durch falsches Tuning

Ich sehe Probleme, wenn IRQs oder RCU-Callbacks doch auf isolierten Kernen landen und die Silence zerstören. Dann kippt der Vorteil, weil Störlast unkoordiniert auftritt und Jitter erzeugt. Ungeplante Hintergrunddienste, Timer oder Watchdogs auf isolierten CPUs wirken ähnlich störend. Auch Mixed-Workloads mit vielen kurzen Tasks verteilen Unruhe so breit, dass Full Tickless wenig bringt. Deshalb plane ich Housekeeping-Kerne klar ein und teste jeden Schritt mit realistischen Profils.

Wesentliche Kernel-Optionen verständlich

Avec CONFIG_NO_HZ_IDLE schalte ich den Tick im Leerlauf ab und erziele schnelle Zugewinne ohne großen Umbau. CONFIG_NO_HZ_FULL aktiviere ich nur, wenn ich Kerne strikt isoliere und saubere Housekeeping-CPUs definiere. Der Boot-Parameter nohz_full legt fest, welche Cores tickless laufen; isolcpus entkoppelt sie vom allgemeinen Scheduling. rcu_nocbs verlagert RCU-Callbacks weg von diesen Kernen, während irqaffinity die Interrupt-Zuständigkeit setzt. Erst im Zusammenspiel wirkt das Setup konstant und damit wirklich nützlich.

Housekeeping-Kerne planen

Ich reserviere ein bis zwei noyaux je NUMA-Node als Housekeeping-Zone für IRQs, Kernel-Threads und RCU. Diese Cores tragen die unvermeidlichen Systemaufgaben und halten isolierte Kerne frei. Dazu pinne ich Services und IRQ-Queues bewusst auf die Housekeeping-CPUs und sperre sie auf den leisen Cores. Wer die CPU-Scheduler-Klassen versteht, steuert Prioritäten und Fairness zuverlässig. So bleiben Latenzpfade kurz, und die ruhigen Kerne liefern berechenbare Temps de réponse.

Guide pratique : Pas à pas

Je commence chaque projet avec une vision claire Ligne de base-Run: Latenz, Energie, Durchsatz, Jitter. Danach prüfe ich, ob NO_HZ_IDLE aktiv ist und ob der Kernel NO_HZ_FULL unterstützt. Als Nächstes ordne ich IRQ-Affinity zu, setze rcu_nocbs und plane Housekeeping-CPUs. Erst dann isoliere ich wenige Kerne testweise mit nohz_full und vergleiche die Resultate. Für die Feinanalyse hilft mir dieser Leitfaden zu Latenz messen, damit ich jede Änderung sauber bewerte.

Messmethoden und KPIs

Ich messe End-to-End-Latence mit Histogrammen und quantiliere Ausreißer, statt nur Durchschnittswerte zu betrachten. PPS und Tail-Latency bewerte ich gemeinsam, damit ruhige Kerne nicht den Durchsatz drücken. Energie messe ich per RAPL, IPMI oder gestecktem Zähler und rechne die Ersparnis in Euro pro Monat um. Beispiel: Spart ein Host 12 W im 24/7-Betrieb, ergeben sich bei 0,30 €/kWh rund 3,15 € pro Monat pro Maschine. Bei 200 Hosts summiert sich das zu spürbaren 630 € pro Monat.

Tieferer Blick: Wie der Kernel Ticks wirklich abstellt

Hinter Tickless steckt die Umstellung vom periodischen Tick auf einen Oneshot-Clockevent: Der Kernel programmiert das nächste „Ereignis“ exakt auf die früheste Fälligkeit eines Timers oder einer Scheduler-Entscheidung. High-Resolution-Timer (hrtimer) ermöglichen feine Granularität. Auf einer NO_HZ_FULL-CPU fällt der periodische Scheduler-Tick weg, solange nur ein Task läuft und keine Kernelarbeit anfällt. Sobald zwei oder mehr Tasks runnable sind, startet der Kernel den Tick wieder, damit Fairness und Timeslicing stimmen. Genau diese Dynamik macht das System leiser, ohne Scheduling-Korrektheit zu verlieren.

HZ, High-Res-Timer und Zeitkonto

Die Kernel-Konstante HZ (typisch 250 oder 1000) bestimmt die Frequenz des klassischen Ticks. Mit Tickless verliert HZ an praktischer Bedeutung für laufzeitkritische Kerne, bleibt aber für jiffies-basierte Logik relevant. Wichtig ist auch die Zeitkontierung (VTIME/Context Tracking): Damit Nutz- und Systemzeit korrekt verbucht werden, trackt der Kernel präzise, wann ein Task im Kernel oder im Userspace ist – ohne permanenten Tick. Wer viel mit Profiling arbeitet, sollte das im Hinterkopf haben, um Messungen richtig zu interpretieren.

Stromsparmechanismen und Tickless

Tickless entfaltet seinen Energiespareffekt nur, wenn die Plattform tiefe États C zuverlässig erreicht. Ich prüfe daher die Firmware- und Kernel-Settings rund um intel_pstate/amd-pstate, Turbomodi und cpufreq-Governor. Ein aggressiver Performance-Governor kann Latenzen senken, aber Energieziele konterkarieren. Umgekehrt kann ein zu träger Powersave-Governor Durchsatz kosten. Mein Vorgehen: Erst Tickless-Setup stabilisieren, dann systematisch P- und C-State-Tuning testen, jeweils mit identischen Workload-Profilen.

Virtualisation et conteneurs

Auf Hypervisor-Hosts bringt Ralenti sans impulsion oft sofort spürbare Einsparungen, weil ruhende vCPUs seltener geweckt werden. Für NO_HZ_FULL isoliere ich physische Kerne und pinne vCPUs der kritischen VMs exakt dorthin. Wichtig: Steal-Time und Host-IRQs dürfen diese Kerne nicht stören. In Gästen ist Full Tickless nur dann sinnvoll, wenn der Host die CPU-Zeit deterministisch bereitstellt. In Container-Umgebungen repliziere ich die Isolationslogik mit cgroups CPUsets und verhindere, dass Systempods oder Sidecars die leisen Kerne belegen.

Netzwerk- und Storage-Pfade beruhigen

Für ultra-niedrige Latenzen bündele ich RX/TX-Queues und ihre IRQs auf Housekeeping-CPUs. Auf den ruhigen Cores arbeite ich bevorzugt mit Userspace-Polling oder dezidierten Completion-Threads, statt IRQs zuzulassen. Bei NVMe kann IO-Queue-Affinity ähnlich helfen. NAPI-Busy-Polling lässt sich gezielt einsetzen, wenn Polling-Jitter berechenbarer ist als Interrupt-Jitter. Ziel ist, dass die isolierten Kerne nie unerwartet von externen Ereignissen aufgeweckt werden.

Beispiel: Boot-Parameter und Pinning

So skizziere ich ein Minimal-Setup (Beispiel 16 Kerne, CPU 0-1 als Housekeeping; 2-7 und 10-15 als Kandidaten für Last; 8-9 für Systemdienste):

GRUB_CMDLINE_LINUX="nohz_full=2-7,10-15 rcu_nocbs=2-7,10-15 isolcpus=2-7,10-15 irqaffinity=0-1"

Après le démarrage, j'applique Affinity et les CPUsets de manière cohérente :

Regrouper les IRQ #
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

# Épingler un service sensible à la latence
taskset -c 2-3 /usr/bin/mon_service

# cgroup-cpuset pour les services système (exemple)
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.procs

Dans les unités systemd, j'utilise également CPUAffinity= ou AllowedCPUs=, afin que les services utilisent systématiquement les bons noyaux.

Diagnostic : vérifier si les cœurs sont réellement silencieux

Je vérifie l'état de repos de mes cœurs en quelques étapes simples : – /proc/interrupts : le compteur augmente-t-il sur des processeurs isolés ? Si oui, corriger l'affinité IRQ. – /proc/timer_list : identifier les timers inattendus sur les cœurs NO_HZ_FULL. – ftrace/perf : afficher les réactivations, les softirqs et les événements de planification. – turbostat : vérifier les durées de séjour dans les états C. Si des Softirqs (NET_RX, TIMER) surviennent encore sur des cœurs inactifs, cela indique presque toujours un problème de répartition ou de pilote.

Interaction avec PREEMPT_RT et les threads RT

PREEMPT_RT réduit les latences en intégrant la préemption au cœur même du noyau. Associé à NO_HZ_FULL, cela peut donner d’excellents résultats lorsque les IRQ s’exécutent sous forme de threads et restent strictement sur des processeurs dédiés à la gestion interne. Important : ne pas disperser les threads RT, mais les ancrer étroitement et contrôler leurs chemins d’accès mémoire (NUMA, page faults). Je maintiens toujours les threads RT „ seuls “ sur des cœurs isolés, afin qu’aucun tick ne revienne en raison de l’apparition d’une deuxième tâche exécutable.

Quand le « Full Tickless » n'est pas intéressant

Je renonce à NO_HZ_FULL lorsque : – De nombreuses tâches éphémères sont créées en permanence (par exemple, des rafales de Fork/Exec). – La charge de travail est fortement synchronisée et impose des changements de cœur constants. – La plateforme n’atteint pas d’états C propres ou le TSC est instable. Dans de tels cas, un fonctionnement propre Configuration des broches IRQ et CPU souvent plus que le coût d'une isolation complète.

Les subtilités de la production : suivi et exploitation

Dans les environnements de production, je mets en garde contre les changements „ insidieux “ : une mise à jour du noyau, un nouvel agent ou une modification du mappage des IRQ peuvent perturber le bon fonctionnement des cœurs. Je mets donc en place : – Un script „ Guardrail “ qui vérifie l’affinité, les CPUsets et les paramètres RCU après chaque redémarrage. – Des métriques sur les réveils par seconde, les séjours en C-State et la latence p99,9. – Des contrôles périodiques Tests de régression avec des charges de travail identiques. C'est la seule façon de préserver de manière fiable l'avantage du mode « tickless ».

Neutraliser de manière ciblée les sources de gigue

Outre les IRQ, ce sont souvent Minuterie dans l'espace utilisateur (sleep/usleep/timerfd) pour les modèles instables. Je travaille avec délai de temporisation (prctl ou /proc) et regroupe les échéances afin que le noyau planifie moins de réveils individuels. Je planifie également les GC en arrière-plan dans les environnements d'exécution gérés (JVM, Go) ou je les isole sur des noyaux de maintenance. L'objectif est toujours de n'autoriser que les réveils absolument nécessaires sur les cœurs NO_HZ_FULL.

Interprétation des indicateurs clés de performance : mettre en évidence les compromis

Je n'évalue pas seulement les moyennes, mais aussi les Distribution: p50, p95, p99,9 et maximum. Un schéma de réussite typique : la latence de queue diminue nettement, le débit moyen reste stable ou augmente légèrement, et la durée de séjour en C-State diminue. En revanche, si je constate une amélioration de la gigue mais un débit sensiblement inférieur, j’ajuste la politique de fréquence du processeur ou j’augmente prudemment le nombre de cœurs inactifs afin d’éviter l’engorgement des files d’attente.

Liste de contrôle avant l'activation de NO_HZ_FULL

– Fonctionnalités du noyau : CONFIG_NO_HZ_FULL, temporisateur haute résolution activé
– Rôles clairs des processeurs : processeurs de gestion interne définis pour chaque nœud NUMA
– Délestage IRQ et RCU : les paramètres `irqaffinity` et `rcu_nocbs` sont définis de manière cohérente
– Placement des services : documentation et tests du « pinning » de systemd/cgroups
– Configuration de mesure : charges de travail reproductibles, indicateurs clés de performance pertinents, comparaison avant/après
– Plan de restauration : entrée de démarrage disponible sans NO_HZ_FULL

Problèmes courants et solutions

Je constate souvent que les services système s'exécutent sur des cœurs isolés et que les Isolation Cela nuit aux performances. Pour y remédier, on peut recourir à systemd-Affinity, aux CPUsets des cgroups et à une documentation claire des services. Les erreurs de placement NUMA entraînent également des accès à distance inutiles et des pics de latence. J'associe strictement la mémoire et les threads au nœud concerné, afin que les chemins d'accès soient courts et cohérents restent. Une répartition floue des IRQ est le troisième problème classique ; c'est pourquoi je regroupe les files d'attente très sollicitées sur des processeurs dédiés à la gestion interne.

Bilan succinct pour la pratique

Le sans tic-tac Le noyau réduit les ticks gênants, économise de l'énergie et crée des créneaux temporels fiables pour les charges de travail sensibles. Avec « Tickless Idle », j’obtiens rapidement des gains d’efficacité, tandis que « Full Tickless » apporte un silence supplémentaire sur les cœurs isolés. C’est lorsque je regroupe proprement les IRQ, les RCU et les tâches en arrière-plan sur des processeurs dédiés à la gestion interne que j’observe le plus grand effet. Rien ne va sans mesure : la latence, la gigue, la consommation d’énergie et le débit m’indiquent si ce réglage porte ses fruits. C’est ainsi que j’utilise le mode « tickless » de manière ciblée et que je tire le maximum du planificateur dehors.