Phoronix a rapporté le 22 octobre 2026 l’intégration dans Linux Git, pour la branche de développement Linux 7.4, d’une modification du parcours de vidage des workqueues du noyau. Lors d’un flush, l’opération qui vide une workqueue, le noyau visite désormais les files utilisées depuis le vidage précédent plutôt qu’une file pour chaque CPU possible. Les chiffres cités montrent des gains de débit dans plusieurs scénarios, mais aussi un recul dans une charge dense.
Ce qui change lors du vidage d’une workqueue
Une workqueue est une file du noyau qui permet de reporter du travail à exécuter de façon asynchrone. Selon Phoronix, la modification signée par Tejun Heo change les files parcourues lors d’un flush, tandis que le chemin utilisé pour mettre du travail en file reste inchangé.
Le changement concerne les workqueues du noyau Linux, pas une API de files de travail en espace utilisateur.
Pourquoi XFS est concerné
Phoronix rapporte que Yao Kai, ingénieur chez Huawei, a signalé un surcoût lié au parcours de la workqueue CIL de XFS. Sur une machine à 128 CPU, ce parcours pouvait prendre jusqu’à 64 microsecondes par flush. La file est vidée à chaque log force de XFS, selon le compte rendu de Phoronix.
Les débits rapportés selon la charge
Les valeurs attribuées au message de commit de Tejun Heo portent sur une machine à 192 CPU et deux nœuds. Dans le scénario à 16 threads, chaque thread ajoutait un élément de travail puis lançait un flush.
| Charge | Type de workqueue | Avant (vidages/s) | Après (vidages/s) | Rapport de débit |
| Inactive | per-CPU | 40 000 | 4 200 000 | 105× |
| Inactive | unbound | 450 000 | 4 300 000 | environ 9,6× |
| 16 threads | per-CPU | 30 000 | 110 000 | environ 3,7× |
| 16 threads | unbound | 60 000 | 180 000 | 3× |
Ces rapports comparent le nombre de flushes effectués par seconde dans chaque scénario. Ils mesurent le débit, pas une réduction équivalente de la latence de bout en bout. Le cas per-CPU inactif atteint 105 fois son débit de départ, un peu au-dessus du résumé général de 10 à 100 fois également rapporté par Phoronix.
En charge dense, les résultats diffèrent
Lorsque toutes les workqueues de pool étaient actives, les flushes denses per-CPU restaient inchangés. Les flushes denses unbound étaient, eux, 15 à 20 % plus lents. Les mesures citées dessinent donc des résultats différents selon le type de workqueue et la charge, tandis que le chemin de mise en file ne change pas.
