Linux 7.4 rend le flush des workqueues inactives jusqu'à 100 fois plus rapide

Linux 7.4 a intégré une modification des workqueues qui rend le flush d'une workqueue inactive 10 à 100 fois plus rapide sur les grosses machines, a rapporté Phoronix le 22 octobre 2026. Le correctif du développeur du noyau Tejun Heo vise les serveurs dotés de nombreux cœurs, comme les systèmes Intel Xeon et AMD EPYC. Sur ces machines, une opération courante du système de fichiers perdait du temps à vérifier chaque CPU, même quand rien n'attendait.

Ce qu'est le flush d'une workqueue

Une workqueue est le moyen pour le noyau de confier de petites tâches à des threads de travail en arrière-plan, au lieu de les exécuter tout de suite. Les pilotes et les systèmes de fichiers s'en servent en permanence. Faire un flush d'une workqueue, c'est attendre que chaque tâche déjà en file soit terminée.

Chaque workqueue est reliée à ses threads de travail par des pool workqueues, ou pwq. Une pwq est le lien entre une workqueue et un groupe de threads de travail. Sur un gros serveur, il peut y avoir une pwq pour chaque CPU possible.

Le problème remonte à un commit antérieur du noyau, « workqueue: Make unbound workqueues to use per-cpu pool_workqueues ». Depuis ce changement, un flush « parcourt une pwq par CPU possible, en prenant tour à tour chaque verrou de pool », selon la lettre de présentation de la série de correctifs. Il le fait même quand la workqueue est inactive. Plus de cœurs signifiait plus de travail perdu à chaque flush.

Qui l'a trouvé, et où cela coinçait

Yao Kai, ingénieur chez Huawei, a signalé ce surcoût début septembre, selon Phoronix. Le point sensible était XFS, un système de fichiers Linux très répandu. XFS fait un flush de l'une de ses workqueues, la workqueue CIL, à chaque log force. C'est le moment où il doit écrire son journal sur le disque.

Sur une machine à 128 CPU, ce flush prenait jusqu'à 64 microsecondes à chaque fois, selon le signalement. Une microseconde est un millionième de seconde, donc 64 paraît peu. Mais un système de fichiers chargé force son journal très souvent, et le coût s'additionnait.

Le correctif garde la trace des pwq réellement utilisées depuis le dernier flush, dans des listes par nœud. Un nœud est un groupe de CPU disposant de sa propre mémoire locale. Un flush ne visite plus que ces pwq actives. La série compte deux correctifs, « workqueue: Maintain pwq->total_in_flight » et « workqueue: Make flush_workqueue() visit only pwqs active since the last flush ».

Les chiffres des tests

La série de correctifs rapporte ses résultats sur une machine à 192 CPU et deux nœuds. Les workqueues per-cpu exécutent les tâches sur un CPU choisi ; les workqueues unbound laissent l'ordonnanceur choisir n'importe quel CPU.

Test sur un serveur à 192 CPU et 2 nœuds	Avant	Après
Flush d'une workqueue per-cpu inactive	40 000 par seconde	4,2 millions par seconde
Flush d'une workqueue unbound inactive	450 000	4,3 millions
16 threads qui mettent en file et font des flushs, per-cpu	30 000 flushs par seconde	110 000 flushs par seconde
16 threads qui mettent en file et font des flushs, unbound	60 000 flushs par seconde	180 000 flushs par seconde

Le compromis est énoncé clairement. « Les flushs denses où chaque pwq est active sont inchangés sur les workqueues per-cpu et 15 à 20% plus lents sur les unbound », a écrit Heo dans son message de commit, cité par Phoronix. La mise en file de nouvelles tâches n'est pas affectée.

Le correctif voyage déjà au-delà de la branche principale. Le 9 septembre, Yao Kai a publié un rétroportage des deux correctifs sur la liste de diffusion du noyau d'openEuler. Il vise le noyau d'openEuler basé sur la version 6.6.

Linux 7.4 rassemble aussi d'autres accélérations dans cette fenêtre de fusion, dont un correctif qui ouvre les fichiers 39% plus vite en test et Dynamic PAMT pour Intel TDX, qui économise la RAM des serveurs.

Ce que cela signifie pour les développeurs

La plupart des gens n'appelleront jamais directement un flush de workqueue. Ils sentiront ce changement à travers le système de fichiers et les pilotes des gros serveurs.

• Mesurez à nouveau XFS sur les machines à nombreux cœurs. Si vous utilisez XFS sur des serveurs de 100 CPU ou plus, comparez les charges qui écrivent beaucoup dans le journal sous Linux 7.4 et sous votre noyau actuel. Les charges qui synchronisent souvent sur le disque sont celles à examiner.
• Vérifiez le coût des flushs chargés. Un code qui fait des flushs de workqueues unbound alors que chaque pwq est occupée peut être 15 à 20% plus lent. Les développeurs du noyau qui ont de tels chemins critiques devraient les mesurer avant et après.
• N'attendez pas de gains sur les petites machines. Le gain vient du fait de sauter les pwq inactives. Un portable à quelques cœurs avait peu à sauter.
• Surveillez le noyau de votre distribution. openEuler rétroporte déjà la série sur son noyau 6.6. D'autres distributions d'entreprise pourraient suivre : consultez leurs journaux des modifications si vous ne pouvez pas passer à 7.4.