Avant que Linus Torvalds ne perde son accès Internet et son électricité à cause d'une tempête de neige affectant ainsi la fenêtre d'intégration de Linux 6.8, son week-end était déjà en mauvais état en raison d'une baisse de performances avec le nouveau code Linux 6.8 qui entraînait la construction de son noyau Linux. C'est le double de ce qu'il était avec les cœurs précédents. Un ingénieur AMD Linux a pu reproduire la régression et, avec les principaux développeurs, il existe désormais une solution confirmée à ce problème dans le dernier code de planification.
Dans la discussion sur la régression significative des performances signalée par Linus Torvalds et résultant des modifications du planificateur dans Linux 6.8, pour la validation fractionnée, le développeur impliqué n'a pas immédiatement compris la cause de la régression. Dans la discussion qui a suivi, Wise Carney d'AMD a parlé mentionné Cela peut également reproduire la régression. Au lieu d'un AMD Ryzen Threadripper haut de gamme comme celui utilisé par Torvalds, Wyes utilisait un modeste ordinateur de bureau AMD Ryzen 5600G. Une remarque importante qu'il a évoquée est que cela n'est reproduit que si vous désactivez ACPI CPPC à partir du BIOS et utilisez ACPI CPUFreq avec le gouverneur Schedutil.
La plupart des systèmes AMD Zen 2 et versions ultérieures prennent en charge ACPI CPPC, donc avec les cœurs modernes du côté Ryzen, ils utilisent généralement le nouveau pilote AMD P-State. Mais pour les systèmes Zen 2 / Zen 3 et antérieurs (ou ceux qui désactivent CPPC à partir du BIOS), le pilote CPUFreq est toujours utilisé et le régulateur de fréquence du processeur par défaut est généralement « Schedutil » pour tirer parti des données d'utilisation du planificateur.
Grâce à ce fil de discussion sur la liste de diffusion, une correction a été suggérée et des problèmes spécifiques liés à cette régression ont été discutés. Finalement, Vincent Guiteau a cru avoir une solution à la régression et Wise a pu tester le patch avec succès.
Guittot est désormais envoyé Programmé/Juste : correction de la sélection de fréquence en cas d'instabilité En tant que correctif pour corriger cette mauvaise régression sur le nouveau code Linux 6.8 lors de l'utilisation d'ACPI CPUFreq + Schedutil. Explique avec correction :
« Lorsque la persistance de fréquence n'est pas activée, get_capacity_ref_freq(policy) renvoie la fréquence actuelle et la marge de performance appliquée par map_util_perf(), permettant à l'utilisation de dépasser la capacité de calcul maximale et de sélectionner une fréquence supérieure à la fréquence actuelle.
La marge de performance est désormais appliquée dès le début du pipeline pour tenir compte de certaines contraintes d'utilisation et nous ne pouvons pas obtenir une utilisation supérieure à la capacité de calcul maximale.
Nous devons utiliser une fréquence supérieure à la fréquence actuelle pour avoir une chance de définir un OPP plus élevé lorsque la fréquence actuelle est entièrement utilisée. Appliquez la même marge et renvoyez une fréquence 25 % supérieure à la fréquence actuelle afin de passer au prochain OPP avant d'utiliser tout le processeur du processeur actuel.
En fin de compte, il s'agissait d'un correctif de code sur une seule ligne pour remédier à cette dégradation des performances qui a fait passer les builds du noyau vide de Linus Torvalds de 22 secondes à 44 secondes.
En supposant que tout continue de bien se tester avec le nouveau correctif, le correctif devrait être intégré au code Git de Linux 6.8 une fois que l'Internet et l'électricité de Linus Torvalds seront rétablis.