Dans le domaine de la performance, ce ne sont pas toujours les réécritures majeures qui la boostent. Parfois, le saut intervient grâce à un détail apparemment mineur : où se concentrent les “interruptions”. C’est précisément là qu’ingénieurs de chez Intel s’attellent à modifier le noyau Linux pour optimiser la gestion du stockage NVMe sur des serveurs modernes dotés d’un grand nombre de cœurs.

Le problème survient lorsque le nombre d’IRQ NVMe est inférieur au nombre de CPU, ce qui est courant dans les architectures actuelles. Dans ce cas, plusieurs cœurs partagent une même interruption, et si l’affinité de cette IRQ n’est pas bien alignée avec la topologie réelle du processeur, cela engendre une augmentation de la latence et une baisse de performance. Intel résume cette problématique par une idée simple : lorsque l’interruption et le “groupe” de CPU ne sont pas proches (en termes de cache et de localisation), cela pénalise la performance.

Le goulet d’étranglement : IRQ partagées et topologie “réelle” du CPU

Le noyau Linux possède déjà des mécanismes pour répartir les affinités, mais la réalité des processeurs modernes est que “NUMA” ne suffit plus à tout expliquer. Au sein d’un même domaine NUMA, les cœurs peuvent être organisés en clusters (par exemple, des groupes de cores partageant un cache intermédiaire). Selon la manière dont la charge est répartie, une distribution “plate” peut finir par traverser des limites internes qui devraient rester isolées.

Dans le cas évoqué par des développeurs de la liste du noyau, l’exemple pratique concerne une CPU où quatre cœurs partagent un cache L2, formant un cluster. Si Linux répartit l’affinité sans prendre en compte cette organisation, l’interruption peut “sauter” entre clusters, dégradant la localité.

Autrement dit : il ne suffit pas de placer une IRQ “dans le même NUMA”. Sur des systèmes multi-clusters en leur sein, il peut être plus efficace que l’interruption soit traitée par un cœur “voisin”.

Ce que change le patch : Linux devient conscient des clusters

Le changement proposé consiste à faire en sorte que le code du noyau, qui gère la répartition des CPU pour les affinités (dans lib/group_cpus.c), soit évolutif et prenne en compte la présence de clusters au sein de chaque domaine NUMA. L’objectif est d’organiser les cœurs de manière plus intelligente afin que l’attribution des IRQ NVMe conserve une localité meilleure entre la CPU et l’interruption.

Wangyang Guo, ingénieur chez Intel, explique que : à mesure que le nombre de cœurs augmente, il peut y avoir moins d’IRQ NVMe que de CPU, obligeant plusieurs cœurs à partager une interruption. Si l’affinité ne correspond pas au cluster adéquat, cela entraîne une pénalité, et ce patch tente de l’atténuer en regroupant les CPU par cluster dans le domaine NUMA.

Une amélioration notable : +15 % en lectures aléatoires avec FIO

Les tests publiés indiquent que cette modification a permis d’obtenir une amélioration d’environ 15 % en lectures aléatoires utilisant FIO avec libaio sur un serveur Intel Xeon E.

C’est un résultat impressionnant, mais il faut noter qu’il concerne un cas précis : aucune donnée n’a encore été publiée pour d’autres types d’I/O (séquenciel, mixte, écriture) ou pour une gamme élargie de plates-formes. Néanmoins, cette approche s’inscrit dans une tendance claire : la performance des serveurs modernes dépend autant du périphérique que du “chemin” suivi par chaque événement dans le système.

L’enjeu pour les administrateurs et architectes systèmes

Pour ceux qui gèrent ces systèmes, la conclusion est claire : l’affinité IRQ n’est pas un simple détail esthétique dans les environnements NVMe à fort parallélisme. Lorsqu’on utilise de nombreux cœurs, des queues NVMe et des charges I/O intensives (bases de données, stockage pour virtualisation, queues d’ingestion, analytique), une répartition inadéquate peut devenir un frein discret mais significatif à la performance.

Ce type d’amélioration rejoint aussi une réalité opérationnelle : aujourd’hui, le NVMe n’est plus simplement “l’élément rapide”, mais ce dont dépend tout le reste (scheduler, affinités, queues, NUMA, caches) pour éviter que la performance ne soit gâchée.

Ce qu’il est possible de vérifier dès maintenant sans attendre les futurs noyaux

En attendant l’évolution, voici quelques pistes de vérification dans les systèmes avec NVMe :

• Distribution des interruptions : vérifier si une ou plusieurs IRQ NVMe concentrent une charge trop importante ou “ploitent” plusieurs CPUs.
• Affinité et NUMA : s’assurer que les IRQ NVMe sont traitées par des CPU proches du nœud NUMA correspondant au périphérique (surtout en multi-socket).
• Comportement de irqbalance : dans certains environnements, sa politique par défaut n’est pas optimale pour les charges déterministes ; dans d’autres, elle évite une concentration excessive.

Il n’y a pas de solution universelle, mais une majorité de signaux indique que dans des architectures à nombreux cœurs, la topologie a une importance primordiale. Chaque génération tend à ajouter des couches internes (clustering, chiplets, CCX/tiles) qui ne sont pas toujours bien représentées par des heuristiques anciennes.

Situation actuelle : dans “mm-everything” et en vue des prochaines versions

Selon les sources, le patch est intégré dans la branche “mm-everything” maintenue par Andrew Morton. Il pourrait être intégré dans une prochaine version du kernel (Linux 6.20 ou même 7.0), selon l’évolution et les revues.

Comme pour toute optimisation de ce genre, l’impact réel sera observable lorsque davantage d’utilisateurs le testeront dans différents contextes : configurations avec différentes topologies, plusieurs sockets, contrôleurs NVMe variés, charges réelles (au-delà des microbenchmarks). L’approche vise à optimiser non pas uniquement en termes d’IOPS, mais aussi en réduisant la “friction interne”.

Questions fréquentes

Qui bénéficie principalement de cette mise à jour NVMe dans Linux ?

Surtout les systèmes à grand nombre de cœurs où le nombre d’IRQ/queues NVMe ne suit pas toujours la même montée, entraînant des IRQ partagées et des pénalités possibles dues à une mauvaise affinité avec la topologie CPU.

Qu’est-ce que “CPU cluster-aware” signifie dans ce contexte ?

Que le noyau tente d’assembler les CPUs par clusters au sein de chaque domaine NUMA afin d’attribuer les affinités IRQ de façon à favoriser la proximité (par exemple, en évitant de faire sauter une interruption entre groupes de cœurs partageant un cache interne).

Est-ce que le +15 % est généralisable à tous les serveurs ?

Pas encore. Les résultats indiqués concernent un serveur Intel Xeon E avec FIO/libaio en lecture aléatoire. Aucune donnée n’est encore disponible pour d’autres profils d’I/O ou types de hardware.

Quand cette amélioration sera-t-elle intégrée dans le noyau stable ?

Le patch est dans la branche “mm-everything”. Il pourrait faire partie d’une prochaine version (dans la série Linux 6.20 ~ 7.0), sous réserve de validation et d’acceptation finales.