Linux a supprimé un contournement de veille de 2002 et le débit des AMD Zen a bondi jusqu'à 14x

Lorsque le support ACPI a été ajouté au noyau Linux en 2002 — écrit par Andy Grover, validé par Linus Torvalds — il incluait une « opération d'attente factice » : le système lisait des données dans le seul but de retarder l'instruction suivante jusqu'à ce que le CPU puisse s'arrêter complètement avec la commande STPCLK#. Cela apportait des économies d'énergie et de la compatibilité aux débuts, lorsque certains chipsets refusaient d'entrer en état de veille comme prévu.

Vingt ans plus tard, l'ingénieur AMD Prateek Nayak a soumis un correctif du noyau pour « ignorer l'attente factice pour les processeurs basés sur la microarchitecture Zen ». Les puces Zen modernes n'ont pas besoin d'un tel coup de pouce, et des tests par échantillonnage basé sur les instructions ont montré que l'opération factice consommait encore un temps significatif que le noyau comptabilisait à tort comme résidence en C-state. Voyant tout ce travail à faible effort, le CPU se poussait lui-même vers des C-states plus profonds et plus lents, puis mettait plus de temps à se réveiller — pénalisant les tâches qui alternent constamment entre actif et inactif.

Les mesures ont été spectaculaires : lors d'exécutions de tbench sur un système Zen3 bi-socket, le noyau corrigé a offert une augmentation de 1 390 % du débit minimum en Mo/s et de 51 % du débit moyen en Mo/s par rapport au noyau de référence, s'approchant du résultat obtenu en désactivant entièrement l'état de veille C2.

Les systèmes Intel avaient échappé à cette malédiction héritée pendant une décennie grâce à un mécanisme de veille basé sur MWAIT, et Dave Hansen, d'Intel, a soumis un correctif urgent limitant l'attente factice aux systèmes Intel — où elle n'affecterait pas les machines « raisonnablement modernes » — ainsi que des commentaires invitant les lecteurs à passer à des mécanismes de veille plus modernes. Soumis à temps, le correctif pouvait intégrer le noyau Linux 6.0 livré la semaine suivante.

Une lecture sans effet de 2002 était interprétée à tort par la gestion d'énergie comme la preuve d'une charge légère, poussant les cœurs Zen en veille profonde — sa suppression a augmenté le débit minimum de 1 390 %.

Le diagnostic est la trouvaille : l'échantillonnage basé sur les instructions a révélé que le temps gaspillé était étiqueté à tort comme une veille saine, transformant un bug de comptabilisation de la gestion d'énergie en une falaise de performance visible.

Le correctif coûte une branche — ignorer l'attente factice sur Zen — et récupère pourtant quatorze fois le débit minimum, un ratio rarement atteignable par quelque optimisation que ce soit du travail réel.

C'est un spécimen vivant de dette technique : du code ajouté pour des chipsets de 2002 a survécu deux décennies et plusieurs générations de CPU parce que rien n'a jamais échoué, cela a juste ralenti.

Les cales de compatibilité survivent au matériel qu'elles servent : à moins que quelqu'un ne les réexamine face aux nouveaux silicium, une opération sans effet vieille de 20 ans peut devenir une taxe invisible qui ressemble à un problème de puce.

Le correctif Zen de Nayak et le suivi urgent de Hansen limitant l'attente factice aux systèmes Intel ont été soumis fin septembre 2022, à temps pour être pris en compte dans le noyau Linux 6.0 que Torvalds s'attendait à livrer la semaine suivante. Le correctif d'Intel ajoutait également des commentaires encourageant la migration vers des mécanismes de veille modernes. Ars Technica n'a rapporté aucun problème résiduel pour les systèmes AMD une fois le correctif appliqué.