Fedora Workstation 44 était la lente d'un comparatif de six distributions sur le Framework Laptop 13 Pro, et Phoronix en a publié la cause le 11 août 2026. Le suspect que tout le monde désignait était un Intel Thermald périmé, puisque Fedora livre la version 2.5.9 de février 2025 quand Ubuntu 26.04 LTS embarque la 2.5.11. Passer à Thermald 2.5.12 n'a rien réglé. Ce qui a réglé le problème, c'est une seule commande : remplacer tuned-ppd par power-profiles-daemon, le démon que Fedora avait abandonné dès Fedora 41. Si vous faites tourner Fedora sur un portable Intel récent, c'est une vérification de cinq minutes au retour bien réel.
The short answer
Fedora Workstation 44 tournait moins vite que cinq autres distributions Linux sur un Framework Laptop 13 Pro équipé d un Intel Core Ultra X9 388H. Le coupable évident était un Intel Thermald périmé, mais pousser Thermald 2.5.12 en mise à jour a laissé l écart intact. Remplacer tuned-ppd par power-profiles-daemon a ramené Fedora au niveau du peloton, dans le même profil performance que les mesures initiales.
Il existe une catégorie de résultat de benchmark plus utile qu'un chiffre rapide : celle où une machine est inexplicablement lente et où quelqu'un prend la peine de chercher pourquoi. Phoronix en a publié un le 11 août 2026, et la réponse tient à un remplacement de paquet auquel la plupart des utilisateurs de Fedora n'ont jamais pensé.
Le décor : un Framework Laptop 13 Pro avec un Intel Core Ultra X9 388H, la génération Panther Lake, faisant tourner six distributions Linux modernes en configuration d'origine, à ceci près que le profil performance était activé. CachyOS est sortie la plus rapide, ce qui n'a surpris personne. Voir Fedora Workstation 44 sortir derrière les cinq autres a surpris, parce que Fedora tournait sur Linux 7.1 avec des paquets globalement alignés sur le reste du plateau.
Le suspect évident n'était pas le bon
Fedora Workstation 44 livrait Intel Thermald 2.5.9. Ubuntu 26.04 LTS avait la 2.5.11 et l'amont en était à la 2.5.12. Thermald 2.5.9 date de février 2025, ce qui fait long pour un paquet dont tout le métier consiste à savoir comment telle plateforme Intel précise veut être pilotée thermiquement.
Cet écart avait une cause banale. L'empaqueteur Fedora de Thermald a quitté Red Hat et le paquet est resté sans suivi. Neal Gompa a demandé à en reprendre la charge via le ticket FESCo 3672, en écrivant qu'il existe de sérieux problèmes de fonctionnement avec le Thermald présent dans les versions stables de Fedora sur les portables sortis depuis environ un an. Il a séparément demandé une exception ponctuelle à la politique de mise à jour pour Thermald sur toutes les branches Fedora via le ticket 3673, en invoquant un contrôle de la gestion d'énergie cassé sur de nombreuses machines Intel récentes.
Thermald 2.5.12 est donc parti en mise à jour de Fedora 44, les mesures ont été relancées sur une installation propre entièrement à jour, et Fedora était toujours derrière. L'explication évidente avait raison sur le paquet périmé et tort sur la cause.
Ce qui a réellement bougé les chiffres
Fedora est passée de power-profiles-daemon à Tuned en 2024, avec Fedora 41. La plupart des autres distributions ont gardé power-profiles-daemon. Cette divergence dormait tranquillement depuis deux ans sans produire de problème visible, ce qui est en général la façon dont ce genre de chose se passe.
power-profiles-daemon n'est pas installé par défaut sur Fedora 44 mais il reste dans les dépôts. Le remettre en place avec sudo dnf swap tuned-ppd power-profiles-daemon puis relancer les tests concernés dans le même mode performance a ramené Fedora 44 au niveau des autres distributions. Pas marginalement, et pas sur un test choisi avec soin : les charges où Fedora décrochait sont revenues dans le peloton.
Les tests touchés sont ceux que l'on attend sensibles aux fréquences soutenues plutôt qu'au comportement en pointe. Compilation chronométrée du noyau Linux en defconfig, rendu Blender de la scène Junkshop sur processeur, lancer de rayons Embree sur le modèle Asian Dragon, PyTorch exécutant ResNet-50 sur processeur en lots de 16. Ce sont des travaux de plusieurs minutes qui occupent tous les cœurs, c'est-à-dire précisément le régime où la différence entre deux implémentations de politique d'énergie cesse d'être théorique.
Pourquoi une couche de compatibilité est le bon endroit où chercher
Le mécanisme à comprendre ici n'est pas que Tuned serait mauvais. C'est ce qui se produit quand on câble ensemble un curseur d'alimentation de bureau et un cadre de réglage pensé pour des serveurs.
power-profiles-daemon fait une chose étroite. Il présente trois profils sur D-Bus, et quand le bureau en sélectionne un, il règle en conséquence le profil de plateforme et la préférence énergie/performance du processeur. Le périmètre est assez restreint pour que son comportement sur un portable Intel récent soit largement déterminé par ce que le noyau et le micrologiciel exposent.
Tuned est d'une autre nature. C'est un cadre de réglage généraliste qui applique des profils entiers : valeurs sysctl, paramètres d'ordonnanceur, anticipation de lecture disque, gouverneur processeur et politique EPP, le tout déclaré dans des fichiers de profil écrits pour rester raisonnables sur un large éventail de machines. tuned-ppd est la couche de compatibilité qui laisse Tuned répondre sur l'interface de power-profiles-daemon, afin que les commandes d'alimentation de GNOME continuent de fonctionner.
Les deux approches se défendent. Le mode de défaillance est à la jonction. Le bureau dit performance, la couche transmet à un profil Tuned, et le profil applique un ensemble de décisions calibrées pour une large famille de matériels plutôt que pour le comportement de préférence énergie/performance qu'attend une puce Panther Lake. Rien n'est cassé au point de produire une erreur dans les journaux. La machine tourne simplement moins vite que le même matériel sous une autre distribution.
Ce que nous ferions cette semaine sur un portable Fedora
Commencez par savoir ce que vous faites tourner, parce qu'un nombre surprenant de gens l'ignorent. tuned-adm active indique quel profil Tuned est appliqué. rpm -q tuned-ppd power-profiles-daemon indique quelle implémentation détient l'interface D-Bus. Aucune des deux commandes ne modifie quoi que ce soit et chacune prend une seconde.
Si vous êtes sur un portable Intel récent et que la machine paraît plus lente que ses caractéristiques ne le laissent penser en charge soutenue, faites le remplacement et mesurez quelque chose de réel avant et après. Une compilation de noyau avec time make -j$(nproc) fait un très bon indicateur, et c'est une charge que vous exécutez probablement déjà. Surveillez les fréquences pendant l'exécution avec turbostat, ou par une simple lecture de /proc/cpuinfo si vous voulez voir le mécanisme plutôt que le seul résultat.
Mettez Thermald à jour dans tous les cas. La 2.5.12 corrige de vrais problèmes sur du matériel Intel récent, et le fait qu'elle n'explique pas ce ralentissement précis ne la rend pas facultative. Deux choses distinctes n'allaient pas ici, et une seule faisait le titre.
Nous avions couvert le versant noyau du comportement énergétique de Panther Lake quand Linux a cessé d'écrire les valeurs HWP request pour ces puces, qui est le même thème pris par l'autre bout : le silicium Intel moderne veut de plus en plus qu'on le laisse se gérer seul. L'équivalent AMD est apparu dans notre analyse du comportement EPP et boost d'amd-pstate.
Sources et pour aller plus loin
- Analyzing Fedora's Slow Performance On The Framework Laptop 13 Pro With Intel Panther Lake, Phoronix, 11 août 2026
- Benchmarking Six Linux Distributions On The Framework Laptop 13 Pro, Phoronix
- Ticket FESCo 3672, demande de reprise pour mainteneur non réactif sur Thermald
- Ticket FESCo 3673, demande d'exception à la politique de mise à jour pour Thermald
- Fedora 41 passe de power-profiles-daemon à Tuned, Phoronix
Questions fréquentes
Quelle est la différence entre tuned-ppd et power-profiles-daemon ?
Les deux traitent le même problème par des chemins opposés. power-profiles-daemon est un petit service avec une seule tâche : exposer trois profils au bureau, traduire celui qui est sélectionné en réglages de profil de plateforme et de préférence énergie/performance, puis se faire oublier. Tuned est un cadre de réglage Red Hat bien plus ancien et bien plus vaste, qui applique des lots entiers de valeurs sysctl, de paramètres d'ordonnanceur, de réglages disque et de politique de gouverneur processeur, décrits dans des profils déclaratifs. tuned-ppd est une couche de compatibilité qui fait répondre Tuned sur l'interface D-Bus de power-profiles-daemon, pour que le curseur d'alimentation de GNOME continue de fonctionner. C'est dans cette couche que loge le décalage : le bureau demande performance, et ce que Tuned en fait dépend d'un profil écrit pour une large famille de machines plutôt que pour le silicium précis qui est en face.
Comment basculer ma propre machine Fedora, et est-ce réversible ?
C'est une seule transaction dnf et c'est entièrement réversible. Lancez `sudo dnf swap tuned-ppd power-profiles-daemon`, redémarrez la machine ou le service, puis vérifiez avec `powerprofilesctl get` que le démon répond. Pour revenir en arrière, faites le remplacement dans l'autre sens. Comme les deux paquets réclament le même nom D-Bus, ils ne peuvent pas cohabiter, ce qui explique pourquoi dnf modélise cela comme un remplacement et non comme une installation. Rien ne change dans votre dossier personnel ni dans vos réglages GNOME : le curseur d'alimentation du shell fonctionne dans les deux cas, il parle simplement à une autre implémentation en dessous.
Cela concerne-t-il les serveurs, ou seulement les portables ?
Le constat précis est un constat de portable, parce qu'il touche la plomberie de profil de plateforme et de préférence énergie/performance que les puces Intel mobiles exposent et que les machines de bureau et les serveurs n'utilisent pas de la même façon. Mais la leçon voyage. Tuned sur un serveur applique lui aussi un profil, et `throughput-performance` face à `balanced` fait une vraie différence sur un hôte de base de données. Si vous avez hérité d'un serveur Fedora ou RHEL et n'avez jamais lancé `tuned-adm active`, vous ne savez pas aujourd'hui sous quelle politique de réglage tourne votre machine. Cela vaut dix secondes de votre temps, quel que soit le résultat de ce comparatif précis.
Pourquoi Fedora livrait-il un Thermald de février 2025 ?
Un raté d'empaquetage plutôt qu'un choix technique. Le mainteneur Fedora de Thermald a quitté Red Hat et le paquet est resté sans suivi, ce qui est exactement la situation que la procédure de mainteneur non réactif du projet sert à débloquer. Le contributeur Red Hat Neal Gompa a demandé à reprendre les paquets via le ticket FESCo 3672, et a séparément demandé une exception ponctuelle à la politique de mise à jour pour Thermald sur toutes les branches Fedora via le ticket 3673, au motif que le contrôle de la gestion d'énergie est cassé sur de nombreux portables Intel sortis ces deux dernières années. Thermald 2.5.12 a depuis été poussé en mise à jour de Fedora 44. C'est un vrai correctif, simplement pas le correctif de ce ralentissement précis.
Faut-il en conclure que Fedora se comporte mal sur le matériel récent ?
Non, et la forme du résultat plaide contre cette lecture. Fedora 44 tournait sur Linux 7.1 avec des paquets globalement au niveau des autres distributions testées : ce n'était pas un cas de logiciel périmé sur toute la ligne. C'était un démon qui prenait une décision différente de celui que cinq autres distributions livrent. C'est une divergence de configuration avec un remède en une commande, pas un problème de plateforme. L'enseignement utile est plus étroit et plus pratique : quand une machine est plus lente qu'elle ne devrait l'être alors que le noyau et le micrologiciel sont à jour, regardez ce qui pilote activement la politique d'énergie de votre processeur avant de regarder ailleurs.