Noyau Linux 7.2 : quoi de neuf pour un VPS ?

Nouveautés du noyau Linux 7.2

Le noyau Linux 7.2 est sorti le 16 août 2026. Le changement qui mérite votre attention est la planification tenant compte du cache, activée par la nouvelle option CONFIG_SCHED_CACHE. Le scheduler essaie désormais de conserver les threads d’un même processus sur des CPU qui partagent le même cache de dernier niveau (LLC). Rien d’autre dans cette version ne modifie la manière dont votre charge de travail est placée sur un CPU.

Le reste de 7.2, en une ligne : une refonte du chemin de fast commit d’ext4, des améliorations de MGLRU (le code de récupération de mémoire least recently used multigénérationnel), une nouvelle cible dm-inlinecrypt de device mapper pour le chiffrement inline des périphériques bloc, et la suppression du dernier appel strncpy() dans les sources du noyau.

Un fait détermine si la fonctionnalité principale peut vous être utile. Il est donc présenté en premier. L’équilibrage de charge tenant compte du cache s’active uniquement lorsqu’un nœud NUMA (non-uniform memory access) contient plusieurs LLC. Un invité VPS ne présente généralement pas cette topologie. Sur la plupart des invités, le code est donc compilé, mais ne s’active jamais. Deux commandes permettent de le vérifier, dans « Un invité VPS voit-il quelque chose de tout cela ? » ci-dessous.

Toutes les affirmations techniques de cette page proviennent du changelog de 7.2 et de la série de patchs sur la planification tenant compte du cache, consultés le 18 août 2026. Les sources sont indiquées vers la fin de la page. Vous pouvez ainsi les comparer au comportement de votre propre noyau.

Pourquoi le scheduler devait connaître les caches

Un socket de serveur moderne ne possède pas un seul cache de dernier niveau. Un package AMD EPYC est composé de plusieurs complexes de cœurs, et chaque complexe possède son propre L3. Les processeurs Intel Xeon récents divisent également un socket en plusieurs domaines de cache. Un seul nœud NUMA peut donc contenir quatre, huit ou davantage de LLC distincts, et deux threads du même programme peuvent se retrouver dans des caches différents.

Ce placement coûte du temps. Lorsque deux threads partagent une page située dans des LLC différents, chaque cache conserve sa propre copie de la ligne. Une écriture d’un côté invalide la copie de l’autre côté. La lecture suivante doit donc traverser l’interconnexion ou accéder à la mémoire principale. C’est le cache bouncing. Il apparaît sous forme de cycles d’attente, et non de temps CPU idle. Il est donc facile de ne pas le voir lorsque vous surveillez la load average.

Avant la 7.2, le load balancer plaçait les tâches en fonction de la load, de l’utilisation et des CPU idle. Il ne disposait d’aucune information indiquant que « ces deux tâches lisent la même mémoire ». La 7.2 en ajoute une, à l’aide d’une approximation dont le calcul ne coûte rien : les threads d’un processus partagent un même espace d’adressage, donc on peut supposer qu’ils partagent probablement des données.

Comment le noyau choisit une LLC préférée

Le suivi est rattaché au processus, dans mm_struct, la structure du noyau qui représente un espace d’adressage. Le noyau échantillonne périodiquement les LLC sur lesquelles s’exécutent les threads de ce processus et compte, pour chaque LLC, la proportion du processus qui s’y trouve. La LLC qui en contient le plus devient la LLC préférée de l’ensemble du processus. Les décisions ultérieures consultent cette valeur unique.

Deux mécanismes l’utilisent. Lors du réveil, l’ordonnanceur privilégie un CPU situé dans la LLC préférée du processus au lieu de choisir n’importe quel CPU inactif du nœud. Lors de l’équilibrage de charge, lorsque des tâches doivent être déplacées entre des groupes d’ordonnancement, il privilégie le déplacement des tâches qui préfèrent déjà la LLC de destination et évite d’éloigner une tâche de sa LLC préférée.

Les garde-fous sont aussi importants que la fonctionnalité elle-même, car regrouper tous les threads d’un processus actif dans un même domaine de cache peut surcharger ce domaine alors que le reste du socket reste inactif. Les paramètres réglables se trouvent dans debugfs, le système de fichiers de débogage du noyau, sous /sys/kernel/debug/sched/ :

• llc_aggr_tolerance, une valeur comprise entre 0 et 100, détermine l’intensité de l’agrégation effectuée par le noyau. 0 désactive l’ordonnancement tenant compte du cache à chaud. 1 est le réglage prudent : un processus dont le RSS (resident set size, c’est-à-dire la mémoire résidente) est supérieur à la LLC, ou qui exécute plus de threads que la LLC ne compte de cœurs, reste là où il se trouve. 100 agrège les processus quelle que soit leur taille ou le nombre de threads.
• llc_overload_pct, à 50 par défaut, définit le taux moyen d’utilisation au-dessus duquel la LLC préférée est considérée comme occupée.
• llc_imb_pct, à 20 par défaut, limite le déséquilibre qu’une migration d’agrégation peut créer lorsque la LLC préférée dépasse ce seuil de surcharge.
• llc_epoch_period, à 10 ms par défaut, définit la fréquence de collecte de l’occupation.
• llc_epoch_affinity_timeout, à 50 ms par défaut, définit la durée pendant laquelle un processus inactif conserve sa préférence avant que le noyau ne la supprime.

Consultez vos propres valeurs avant de les modifier, car une distribution peut fournir des valeurs par défaut différentes : sudo cat /sys/kernel/debug/sched/llc_aggr_tolerance.

Quelles charges de travail peuvent plausiblement en bénéficier, et lesquelles n’en bénéficient pas

Les chiffres ci-dessous sont ceux publiés avec la série de correctifs. Ils ont été mesurés sur du matériel de classe serveur, et certains avec le paramètre de tolérance réglé sur une valeur agressive. Considérez-les comme le meilleur cas sur du bare metal, pas comme une garantie pour votre machine.

[
  {
    "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 avec un seul groupe s’est amélioré de 30.57%, et le test de débit ChaCha20 sur AMD Genoa s’est amélioré de 44%. Les 3 résultats ont été obtenus sur du matériel serveur doté de plusieurs LLC, que l’évaluateur contrôlait de bout en bout.

Une charge de travail susceptible d’en bénéficier présente les caractéristiques suivantes :

• Plus d’un thread dans un même processus, afin qu’il y ait quelque chose à regrouper.
• Un partage réel entre ces threads, de sorte qu’une ligne de cache déplacée représente un coût effectivement payé.
• Un working set qui tient dans une seule LLC, car un processus plus grand que le cache ne peut pas bénéficier d’une meilleure localité de cache simplement en étant déplacé.
• De la capacité disponible sur la machine, afin que le scheduler ait réellement le choix de l’emplacement du thread suivant.

Voici les cas où il n’y a rien à gagner :

• Une machine déjà à pleine capacité. Tous les CPU sont occupés, le placement est donc imposé et les gains annoncés diminuent.
• Les processus mono-thread et les pools de processus indépendants qui ne partagent aucune donnée.
• Un working set bien plus grand que la LLC, que le paramètre llc_aggr_tolerance prudent ignore délibérément.
• Un nœud qui n’annonce qu’une seule LLC, auquel cas la fonctionnalité ne s’active jamais.

Il y a aussi un coût, et la série de correctifs le reconnaît clairement. La collecte de l’occupation est effectuée dans le contexte de la tâche, et certains tests ont montré une dégradation de la latence des requêtes, car cette opération retardait le retour de la tâche dans l’espace utilisateur. L’agrégation peut également augmenter la variance de la latence, même lorsque le débit moyen s’améliore. Si la latence de queue vous importe davantage que la moyenne, mesurez votre propre latence de queue.

Un invité VPS voit-il quelque chose de tout cela

Deux faits déterminent la réponse.

Premièrement, cette fonctionnalité dépend de la topologie. L’équilibrage de charge tenant compte du cache est activé uniquement lorsqu’un même nœud NUMA contient plusieurs LLC. Le kernel enregistre cette information lors de l’initialisation de la topologie. Lorsqu’un nœud ne signale qu’une seule LLC, le chemin tenant compte du cache reste inactif, quels que soient les paramètres tunables.

Deuxièmement, la topologie du cache que lit votre invité n’est pas celle de l’hôte. Elle correspond au modèle CPU présenté par l’hyperviseur. Par défaut, un invité KVM (kernel based virtual machine) ne reçoit généralement pas la véritable organisation du cache L3 de l’hôte. L’invité raisonne donc à partir d’une représentation simplifiée.

Vérifiez ce que voit votre propre invité :

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

index3 correspond au cache L3 sur la plupart des CPU x86. Une seule ligne listant tous les vCPU signifie que l’invité voit une seule LLC. La fonctionnalité n’a donc rien à organiser. No such file or directory signifie qu’aucun cache L3 n’a été exposé à l’invité. Celui-ci considère alors un niveau de cache inférieur comme son dernier niveau, avec des limites inventées par l’hyperviseur plutôt que définies par le silicium.

Il faut aussi tenir compte de la double planification, qui constitue la réserve incontournable pour tout locataire. Le kernel de l’invité place les threads sur les vCPU. Le kernel de l’hôte place ensuite ces threads de vCPU sur les cœurs physiques. Un invité qui regroupe soigneusement quatre threads sur les vCPU 0 à 3 exprime une préférence concernant quatre threads de l’hôte. L’hôte peut les placer sur différents domaines de cache physiques et les déplacer ultérieurement. La décision de l’invité n’est pas incorrecte. Elle n’est simplement pas définitive. C’est la même limite entre les couches que celle qui produit le steal time laissé sur vos vCPU par un voisin bruyant.

Dans quelle mesure cette fonctionnalité concerne-t-elle donc un locataire VPS ? À deux niveaux. Avec les offres où la topologie est réelle plutôt que synthétique, par exemple avec des cœurs dédiés ou des instances plus importantes dont la topologie est transmise à l’invité, le scheduler de l’invité prend une décision concernant du matériel réellement présent. Et sur le kernel de l’hôte du fournisseur, le placement tenant compte du cache de vos threads de vCPU constitue un avantage que le fournisseur peut exploiter, pas vous. L’organisation du cache varie également selon l’architecture. C’est une variable supplémentaire lorsque vous comparez un VPS Arm à un VPS x86.

Mesurer le comportement du cache dans un invité est plus difficile que sur une machine physique. perf stat -e cache-misses signale souvent <not supported>, car l’hyperviseur n’expose pas le PMU (performance monitoring unit) aux invités. Mesurez plutôt le débit et la latence de votre propre application, puis utilisez le paramètre debugfs pour basculer entre les deux exécutions.

Vérifier si votre kernel dispose de CONFIG_SCHED_CACHE

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 signifie que votre kernel a été compilé avec cette option. Une ligne contenant # CONFIG_SCHED_CACHE is not set signifie que l’option existe dans cette version, mais que votre distribution l’a désactivée. Une absence totale de sortie signifie généralement que le kernel est antérieur à cette option ; uname -r le confirmera. Certaines images cloud minimales ne contiennent pas de fichier /boot/config-*. Dans ce cas, consultez plutôt zcat /proc/config.gz, qui ne fonctionne que si le kernel a été compilé avec CONFIG_IKCONFIG_PROC.

La ligne ls affiche les paramètres llc_* lorsque la fonctionnalité est intégrée au kernel. Si elle n’affiche rien alors que CONFIG_SCHED_CACHE=y est présent, montez d’abord debugfs avec sudo mount -t debugfs none /sys/kernel/debug.

Pour comparer votre charge de travail avec la fonctionnalité activée puis désactivée, notez d’abord la valeur actuelle, car vous devrez la rétablir :

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

Exécutez votre benchmark, rétablissez la valeur notée, puis exécutez-le à nouveau. Les écritures dans debugfs ne persistent pas après un redémarrage, ce qui est souhaitable pendant les tests.

Quand une distribution intégrera-t-elle la version 7.2 du noyau

Le noyau mainline n’est pas celui sur lequel votre VPS démarre. La version indiquée par uname -r provient de votre distribution, et chaque distribution suit son propre parcours entre la publication mainline et l’arrivée du noyau sur votre serveur.

Fedora rebase ses versions stables sur de nouveaux noyaux mainline pendant toute leur période de prise en charge. Là, sudo dnf upgrade --refresh suivi d’un redémarrage suffit donc, et c’est généralement le premier endroit où un locataire peut essayer un nouveau noyau. Cette cadence fait partie des choix liés à l’utilisation de Fedora Server sur un VPS.

Ubuntu fournit un nouveau noyau avec chaque version publiée tous les six mois, puis le propose pour la version précédente bénéficiant du support long terme (LTS) par l’intermédiaire de la pile HWE (hardware enablement). En août 2026, Ubuntu 24.04 LTS installe toujours 6.8, publié en avril 2024, comme noyau GA, tandis que sa pile HWE est passée à 6.14 en août 2025, puis à 6.17 en février 2026. Le délai réaliste est donc le suivant : une version mainline publiée en août 2026 atteint une pile HWE LTS environ un an plus tard.

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

Debian stable conserve un seul noyau pendant toute la durée de vie de la version et propose des noyaux plus récents par l’intermédiaire des backports. Vous devez les activer package par package :

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

Après l’une de ces opérations, redémarrez et vérifiez la version avec uname -r ainsi qu’avec le grep ci-dessus. Un nouveau noyau ne peut pas être chargé à chaud : le live kernel patching sur un VPS remplace le code de fonctions individuelles dans le noyau en cours d’exécution, mais ne peut pas modifier la disposition des structures ni ajouter de fichiers debugfs. La planification tenant compte du cache fait les deux, car elle ajoute des champs à mm_struct. Elle n’est donc disponible qu’après le démarrage sur un nouveau noyau.

Deux vérifications pratiques s’imposent ensuite. Conservez l’ancien noyau amorçable jusqu’à ce que le nouveau ait supporté votre charge pendant un certain temps. C’est l’objectif de la sélection du noyau démarré sur un VPS. Surveillez également /boot : la partition de boot d’un petit VPS se remplit après quelques mises à niveau du noyau, comme indiqué dans le nettoyage des anciens noyaux sur Ubuntu.

Dernier point concernant la responsabilité. Sur un VPS KVM, le noyau invité vous appartient : vous le choisissez, vous démarrez dessus et vous pouvez revenir à l’ancien. Le noyau de l’hôte appartient à votre fournisseur, et aucun réglage dans votre invité ne modifie le scheduler exécuté par l’hyperviseur. Une note de version concernant le placement des tâches ne raconte donc que la moitié de l’histoire pour un locataire. La moitié que vous contrôlez concerne l’invité.

Sources utilisées pour cette page

• Le résumé des changements de la version 7.2 sur kernelnewbies.org, pour la date de publication du 16 août 2026 et les changements qui ne concernent pas le scheduler.
• L’article de LWN consacré à la série de patches sur l’ordonnancement sensible au cache, à lwn.net/Articles/1041668 et lwn.net/Articles/1058288, pour les paramètres réglables dans debugfs, le mécanisme de préférence par processus et les résultats de benchmark publiés.
• Le patch qui conditionne cette fonctionnalité à la topologie, "sched/cache: Introduce sched_cache_present", pour la règle selon laquelle l’équilibrage de charge sensible au cache nécessite plusieurs LLC dans un nœud NUMA.

Pour la version précédente, consultez les changements de Linux kernel 7.1. Pour comprendre l’origine des numéros de version, consultez la chronologie de l’histoire du kernel Linux.

FAQ

L’ordonnancement sensible au cache dans Linux 7.2 rend-il un VPS plus rapide ?

Généralement, non, pas à lui seul. Cette fonctionnalité ne s’active que lorsqu’un nœud NUMA indique plusieurs caches de dernier niveau. Or un invité KVM classique n’expose généralement pas cette organisation. Le code ne s’active donc jamais. Lorsqu’il s’active, l’invité est tout de même ordonnancé deux fois : votre kernel sélectionne un vCPU, puis le kernel de l’hôte détermine sur quel cœur physique le thread de ce vCPU s’exécute. L’hôte peut donc annuler la décision de l’invité concernant le cache. Exécutez cat /sys/devices/system/cpu/cpu*/cache/index3/shared_cpu_list | sort -u dans votre invité. Une seule ligne couvrant tous les vCPU signifie que la fonctionnalité n’a rien à organiser.

Comment vérifier si mon kernel intègre CONFIG_SCHED_CACHE ?

Exécutez grep -E '^CONFIG_SCHED_CACHE' /boot/config-$(uname -r). CONFIG_SCHED_CACHE=y signifie que l’option est intégrée au kernel. # CONFIG_SCHED_CACHE is not set signifie que votre distribution l’a désactivée. L’absence de sortie signifie que le kernel est antérieur à cette option. Si l’image ne contient pas de fichier /boot/config-*, essayez zcat /proc/config.gz. Ce fichier existe uniquement avec les kernels compilés avec CONFIG_IKCONFIG_PROC. Vous pouvez confirmer l’état à l’exécution avec sudo ls /sys/kernel/debug/sched/ | grep -i llc. Cette commande liste les paramètres llc_* lorsque la fonctionnalité est présente.

Comment désactiver l’ordonnancement sensible au cache sans redémarrer ?

Écrivez 0 dans le paramètre de tolérance : sudo sh -c 'echo 0 > /sys/kernel/debug/sched/llc_aggr_tolerance'. Cela désactive la fonctionnalité à l’exécution et fournit un commutateur A/B propre pour un benchmark. Lisez d’abord la valeur actuelle avec sudo cat /sys/kernel/debug/sched/llc_aggr_tolerance, puis rétablissez-la ensuite, car les valeurs par défaut varient selon les builds. Rien de ce qui est écrit dans debugfs ne persiste après un redémarrage. Si cat renvoie No such file or directory, votre kernel n’intègre pas cette fonctionnalité et il n’y a rien à désactiver.

Quand Ubuntu ou Debian publieront-ils un kernel basé sur la version 7.2 ?

Fedora rébase ses versions stables sur de nouveaux kernels mainline. Cette version y arrive donc d’abord via un dnf upgrade normal et un redémarrage. Ubuntu publie de nouveaux kernels avec chaque version semestrielle et les fournit ensuite pour la LTS précédente via la pile HWE. L’écart historique est proche d’un an : en août 2026, la pile HWE d’Ubuntu 24.04 LTS utilise la version 6.17 de février 2026, tandis que son kernel GA est toujours en version 6.8. Debian stable conserve un kernel pour toute la durée de la version et propose des kernels plus récents via trixie-backports. Vous les installez alors individuellement avec apt install -t trixie-backports linux-image-amd64.