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 et souvent des temps d'exécution plus réguliers. Dans les configurations d'isolation, le bruit du système d'exploitation diminue, ce qui permet au code sensible de réagir de manière plus cohérente. Selon la Linux Foundation et la documentation du noyau, NO_HZ_IDLE apporte des gains significatifs en mode veille, tandis que NO_HZ_FULL réduit encore davantage les impulsions parasites. Des documents HPC confirment cet effet en combinaison avec le pinning et le regroupement d’IRQ sur les cœurs de gestion interne. Si l’on met en place des mesures de manière rigoureuse, on observe clairement ces effets dans les profils de latence et de consommation d’énergie des Hôtes.

Risques liés à un réglage incorrect

Je crains que des problèmes surviennent si des IRQ ou des callbacks RCU finissent par être traités par des noyaux isolés et que les Silence détruire. L'avantage disparaît alors, car la charge parasite survient de manière désordonnée et génère de la gigue. Les services d'arrière-plan non planifiés, les minuteries ou les chiens de garde sur des processeurs isolés ont un effet perturbateur similaire. Les charges de travail mixtes comportant de nombreuses tâches courtes diffusent également les perturbations à un tel point que le mode « Full Tickless » n’apporte que peu d’avantages. C’est pourquoi je prévois clairement des cœurs dédiés à la gestion interne et je teste chaque étape avec des scénarios réalistes Profils.

Les principales options du noyau expliquées de manière claire

Avec CONFIG_NO_HZ_IDLE Je désactive le « tick » en mode veille et réalise ainsi des gains rapides sans avoir à procéder à des modifications importantes. CONFIG_NO_HZ_FULL Je ne l'active que lorsque j'isole strictement des cœurs et que je définis des processeurs dédiés à la gestion interne. Le paramètre de démarrage `nohz_full` détermine quels cœurs fonctionnent en mode « tickless » ; `isolcpus` les dissocie de la planification générale. rcu_nocbs détourne les callbacks RCU de ces cœurs, tandis qu'irqaffinity définit la responsabilité des interruptions. Ce n'est que grâce à cette combinaison que la configuration fonctionne de manière constante et donc réellement utile.

Planifier les noyaux de maintenance

J'en réserve un ou deux noyaux chaque nœud NUMA sert de zone de gestion interne pour les IRQ, les threads du noyau et le RCU. Ces cœurs prennent en charge les tâches système inévitables et libèrent les cœurs isolés. Pour ce faire, j’affecte délibérément les services et les files d’attente d’IRQ aux processeurs de gestion interne et je les bloque sur les cœurs silencieux. Si vous souhaitez Classes de planificateurs de CPU comprend, gère les priorités et l'équité de manière fiable. Ainsi, les chemins de latence restent courts et les cœurs silencieux fournissent des performances prévisibles Temps de réponse.

Guide pratique : Pas à pas

Je commence chaque projet avec une vision claire Ligne de base-Run : latence, consommation d'énergie, débit, gigue. Ensuite, je vérifie si NO_HZ_IDLE est activé et si le noyau prend en charge NO_HZ_FULL. Ensuite, j’attribue l’affinité IRQ, je définis rcu_nocbs et je planifie les tâches de maintenance du processeur. Ce n’est qu’alors que j’isole quelques cœurs à titre d’essai avec nohz_full et que je compare les résultats. Pour l’analyse approfondie, ce guide m’aide à Mesurer la latence, afin que je puisse évaluer correctement chaque modification.

Méthodes de mesure et indicateurs clés de performance

Je mesure de bout en bout-Latence à l'aide d'histogrammes et en quantifiant les valeurs aberrantes, plutôt que de me contenter d'examiner les moyennes. J'évalue conjointement le PPS et la latence de queue afin que les cœurs inactifs ne réduisent pas le débit. Je mesure la consommation d'énergie via RAPL, IPMI ou un compteur branché, et je calcule les économies réalisées en Euro par mois. Exemple : si un serveur permet d'économiser 12 W en fonctionnement 24 h/24 et 7 j/7, cela représente environ 3,15 € par mois et par machine, à un tarif de 0,30 €/kWh. Avec 200 serveurs, cela représente une économie non négligeable de 630 € par mois.

Zoom : comment le noyau désactive réellement les ticks

Derrière le concept de « Tickless » se cache le passage du « tick » périodique à un Événement ponctuel lié à l'horloge: Le noyau programme le prochain „ événement “ exactement à la première échéance d'un temporisateur ou d'une décision du planificateur. Les temporisateurs haute résolution (hrtimer) permettent une granularité fine. Sur une NO_HZ_FULL- Le tick périodique du planificateur est supprimé tant qu’une seule tâche s’exécute et qu’aucune activité du noyau n’est requise. Dès que deux tâches ou plus sont exécutables, le noyau relance le tick afin de garantir l’équité et le partage du temps. C’est précisément cette dynamique qui rend le système plus silencieux, sans pour autant compromettre la justesse de l’ordonnancement.

HZ, minuterie haute résolution et compte de temps

La constante du noyau HZ (généralement 250 ou 1000) détermine la fréquence du « tick » classique. Avec le mode « tickless », HZ perd de son importance pratique pour les noyaux où le temps d'exécution est critique, mais reste pertinent pour la logique basée sur les « jiffies ». Il est également important de noter que la Imputation temporelle (VTIME/Context Tracking) : Afin que le temps utilisateur et le temps système soient correctement enregistrés, le noyau suit avec précision le moment où une tâche se trouve dans le noyau ou dans l'espace utilisateur – sans tick permanent. Ceux qui travaillent beaucoup avec le profilage doivent garder cela à l'esprit pour interpréter correctement les mesures.

Mécanismes d'économie d'énergie et mode « tickless »

Tickless ne permet de réaliser des économies d'énergie que lorsque la plateforme est en état de veille profonde États C de manière fiable. Je vérifie donc les paramètres du firmware et du noyau concernant intel_pstate/amd-pstate, les modes Turbo et cpufreq-Régulateur. Un régulateur de performances agressif peut réduire les latences, mais aller à l'encontre des objectifs énergétiques. À l'inverse, un régulateur d'économie d'énergie trop lent peut nuire au débit. Ma démarche : stabiliser d’abord la configuration « tickless », puis tester systématiquement le réglage des états P et C, à chaque fois avec des profils de charge de travail identiques.

Virtualisation et conteneurs

Sur les hôtes d'hyperviseur, cela permet Ralenti sans impulsion des économies souvent perceptibles immédiatement, car les vCPU inactives sont moins souvent réactivées. Pour NO_HZ_FULL J'isole des cœurs physiques et j'y affecte précisément les vCPU des machines virtuelles critiques. Important : le « steal time » et les IRQ de l'hôte ne doivent pas perturber ces cœurs. Dans les machines invitées, le mode « Full Tickless » n'est pertinent que si l'hôte fournit le temps CPU de manière déterministe. Dans les environnements de conteneurs, je reproduis la logique d'isolation avec cgroups et CPUsets et empêcher les Systempods ou les Sidecars d'occuper les cœurs silencieux.

Optimiser les chemins d'accès au réseau et au stockage

Pour obtenir des latences ultra-faibles, je regroupe Files d'attente RX/TX et leurs IRQ sur des processeurs de gestion interne. Sur les cœurs inactifs, je préfère utiliser le polling en espace utilisateur ou des threads de finalisation dédiés, plutôt que d'autoriser les IRQ. Avec NVMe, il est possible de Affinité de file d'attente d'E/S Cela aide de la même manière. Le NAPI-Busy-Polling peut être utilisé de manière ciblée lorsque la gigue de polling est plus prévisible que la gigue d'interruption. L'objectif est que les cœurs isolés ne soient jamais réveillés de manière inattendue par des événements externes.

Exemple : paramètres de démarrage et « pinning »

Voici comment je concevrais une configuration minimale (par exemple, 16 cœurs, les cœurs 0 à 1 dédiés à la gestion interne ; les cœurs 2 à 7 et 10 à 15 comme candidats pour la charge de travail ; les cœurs 8 et 9 pour les services système) :

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.