La suppression de MMX dans Linux vise les dernières optimisations RAID de l’ère Pentium
Les développeurs de Linux se préparent à retirer les dernières optimisations Intel MMX du noyau, refermant un chapitre ouvert avec les processeurs Pentium en 1997. La proposition de suppression de MMX dans Linux cible des calculs spécialisés de stockage tout en conservant les solutions de repli logicielles existantes. Le compromis central est simple : moins de code historique à maintenir, avec un coût potentiel en performances pour des systèmes exceptionnellement anciens.
MMX, l’extension d’instructions d’Intel destinée au traitement de données empaquetées, aidait autrefois les logiciels à accélérer le multimédia et d’autres calculs répétitifs. Les implémentations restantes dans le noyau servent au RAID logiciel, qui regroupe des disques sous le contrôle du système d’exploitation. Elles sont désormais vouées à disparaître, car des alternatives génériques réalisent déjà le même travail.
La destination attendue est Linux 7.5, prévu pour 2027, mais il s’agit d’une attente de publication plutôt que d’une intégration achevée dans la branche principale. Pour les propriétaires de matériels concernés, la distinction compte. Cette proposition modifie l’exécution de certains calculs de stockage ; elle n’établit pas, à elle seule, que chaque ordinateur de l’ère Pentium pourra exécuter un futur noyau.
La suppression de MMX dans Linux dépasse une seule routine XOR
La proposition retire une petite famille d’implémentations RAID historiques, plutôt que de désactiver la fonctionnalité de stockage qu’elles accélèrent.
Eric Biggers a soumis la série le 25 octobre 2026. Sa proposition de retrait de MMX comprend trois correctifs couvrant XOR, RAID6 et les vérifications de fonctionnalités du processeur. Les changements soumis touchent sept fichiers, ajoutent 12 lignes et en suppriment 837.
XOR, une opération bit à bit qui combine des valeurs, aide à calculer la parité, l’information redondante utilisée pour reconstruire des données manquantes. RAID6, une configuration de stockage conçue pour tolérer deux défaillances de disques, exige des calculs supplémentaires au-delà du XOR de base. Réduire l’ensemble de la série à une seule routine XOR supprimée sous-estime donc sa portée.
Cette distinction évite aussi une lecture exagérée du titre. Retirer une implémentation optimisée modifie les chemins d’exécution disponibles. Retirer la prise en charge du RAID éliminerait une capacité de stockage. La proposition soumise décrit le premier cas, les processeurs concernés utilisant le code générique existant.
Phoronix a indiqué que le travail avait atteint l’arbre de développement MM d’Andrew Morton et a identifié Linux 7.5 comme la destination probable. Sa couverture du MMX dans le noyau présente l’objectif de version comme une attente. Au 9 novembre, c’est le langage approprié pour les lecteurs qui planifient autour de ce changement.
Un arbre de développement prouve que le travail progresse vers une intégration. Il ne rend pas une cible de version proposée inconditionnelle. Les revues, les décisions d’intégration et les révisions ultérieures peuvent encore influer sur ce qui atteindra un noyau final.
Pour les lecteurs découvrant la suppression de MMX dans Linux à travers des titres nostalgiques, cette distinction de statut mérite attention avant l’histoire. L’événement vérifié est une série de nettoyage soumise, dont l’arrivée dans un arbre de développement a été rapportée. L’événement futur est son arrivée attendue dans une version de la branche principale.
La limite pratique est tout aussi importante. La série concerne des implémentations au sein du noyau, le cœur du système d’exploitation. Elle ne décrit pas une interdiction générale pour les applications d’utiliser des instructions MMX, et n’annonce pas non plus que les processeurs Intel cesseront de les reconnaître.
Cette limite modifie le sens de la « fin d’une époque ». Le noyau achèverait le retrait de ses propres travaux d’optimisation spécifiques à MMX. L’écosystème logiciel plus large, y compris les applications historiques et les systèmes d’exploitation préservés, suit un cycle de vie distinct.
Pour les mainteneurs, la proposition offre une occasion concrète de simplifier un recoin survivant du code. Pour les utilisateurs, elle soulève une question plus précise : leur machine particulière sélectionne-t-elle aujourd’hui l’une de ces implémentations ? Cette question mène directement aux exigences matérielles.
Les systèmes concernés se situent sous différents seuils d’instructions
La ligne de partage pertinente dépend des capacités du processeur et de la charge de travail, et non simplement de la présence d’un badge Pentium sur un ordinateur.
Le correctif de suppression de XOR de Biggers identifie le chemin concerné comme destiné aux anciens processeurs 32 bits sans prise en charge de SSE. SSE, ou Streaming SIMD Extensions, est une extension d’instructions ultérieure destinée au traitement simultané de plusieurs éléments de données. Le correctif limite également l’usage pertinent aux systèmes exécutant réellement une grappe RAID.
Le correctif RAID6 trace une autre frontière : les processeurs dépourvus de SSE2, l’extension suivante de cette famille d’instructions. Ses modifications de l’implémentation RAID6 retirent également un fichier nommé sse1.c. Biggers explique que cette implémentation utilisait encore des calculs MMX, complétés par des opérations mémoire SSE.
Ce nom de fichier est un détail instructif. Un examen rapide pourrait laisser croire que la série supprime, aux côtés de MMX, un remplacement moderne et indépendant. La description du correctif identifie au contraire une autre implémentation construite autour de mécanismes plus anciens.
Pour quiconque évalue l’impact d’Intel MMX sur les performances, ces seuils distincts comptent. La prise en charge de SSE par un processeur ne détermine pas automatiquement son exposition à chaque partie de la série. L’implémentation sélectionnée et le calcul RAID concerné déterminent la comparaison pertinente.
Prenons l’exemple hypothétique d’un passionné exécutant une configuration de noyau prise en charge sur une machine de stockage Pentium II préservée. Si sa grappe utilise une implémentation retirée, le changement pratique concernerait les performances des calculs. La présence d’une solution de repli signifie que la suppression de code proposée n’élimine pas automatiquement ce calcul.
Considérons maintenant un développeur lisant le même titre sur une station de travail contemporaine. L’ancienneté de l’extension d’instructions MMX ne dit à elle seule presque rien de l’implémentation de stockage sélectionnée par cette station. Les éléments utiles seraient les capacités réelles de son processeur et le comportement du noyau.
Ces exemples illustrent l’exposition plutôt qu’ils n’établissent des résultats mesurés. Le matériel examiné ne fournit pas d’inventaire des machines actives utilisant les chemins appelés à disparaître. Il ne peut donc pas étayer une estimation précise du nombre d’utilisateurs affectés.
Les personnes confrontées à une décision significative sont les opérateurs qui associent d’anciennes capacités de processeur à la charge de stockage pertinente. Elles devraient déterminer si une mise à niveau modifie leur implémentation sélectionnée et si un éventuel ralentissement en résultant importe.
Les mainteneurs de distributions font face à une tâche de communication connexe. Leur configuration du noyau, la disponibilité des paquets et les exigences de processeur restent distinctes de ce nettoyage d’optimisation. Les utilisateurs ont besoin de ces détails avant d’interpréter une future version comme une option de mise à niveau pour du matériel préservé.
Le compromis de maintenance atteint donc un public technique restreint aux besoins potentiellement spécifiques. Une faible exposition ne signifie pas une absence d’exposition. Cela signifie que la réponse doit s’appuyer sur les preuves réelles liées au matériel et à la charge de travail, plutôt que sur le poids émotionnel d’un nom de processeur familier.
Le code générique préserve la capacité tout en réduisant les cas particuliers
La proposition distingue la préservation d’une fonction de celle de chaque implémentation historique de cette fonction.
Une solution de repli scalaire, un code ordinaire qui traite les valeurs sans l’implémentation MMX retirée, offre cette possibilité aux mainteneurs. Biggers décrit les solutions de repli existantes comme bien testées. C’est la base invoquée par l’auteur pour préserver la fonctionnalité tout en retirant des chemins spécialisés.
Cette expression mérite d’être replacée dans son juste cadre. Elle étaye l’argument de continuité de la proposition, mais elle ne constitue pas un benchmark publié pour chaque machine concernée. Une sortie correcte et une vitesse équivalente sont deux propriétés différentes.
La logique de maintenance est plus facile à comprendre lorsqu’on l’envisage comme un choix entre implémentations. Le code spécialisé peut justifier sa présence lorsqu’il sert les utilisateurs ou apporte des performances utiles. Sa persistance crée également du matériel que les relecteurs doivent comprendre lorsque le code associé évolue.
Le code générique offre un lieu commun pour maintenir le comportement. Cela ne rend pas chaque implémentation spécialisée inutile. Cela modifie les preuves nécessaires pour en conserver une ancienne : il doit exister un avantage pratique qui mérite d’être préservé.
C’est là que la suppression de MMX dans Linux devient plus intéressante qu’un simple anniversaire historique. Le projet met en balance un chemin de performance restant avec la complexité de son maintien. L’existence d’une alternative fonctionnelle rend la suppression possible sans rendre la décision gratuite.
Le troisième correctif étend cette simplification aux vérifications des fonctionnalités du processeur, qui sélectionnent les implémentations appropriées selon les capacités matérielles disponibles. Biggers propose de supprimer des vérifications préalables redondantes et d’éviter les vérifications répétées des mêmes fonctionnalités. Le code soumis conserve des implémentations plus récentes, y compris les chemins SSE2 et AVX2.
AVX2, une extension ultérieure d’instructions vectorielles, représente une autre voie pour traiter plusieurs valeurs dans une opération. Sa présence illustre plus clairement la comparaison technique qu’une rivalité entre marques. La question est de savoir quelle implémentation convient au processeur et mérite encore d’être maintenue.
Le nom d’Intel domine l’histoire parce que l’entreprise a introduit MMX. La décision de maintenance réelle porte sur les fonctionnalités de processeur prises en charge, plutôt que sur l’image de marque du fabricant. Comparer des produits Intel et AMD historiques ne permettrait pas de déterminer si une implémentation particulière du noyau mérite encore sa place.
Le même raisonnement explique pourquoi une réduction du nombre de lignes exige une interprétation prudente. Moins de lignes décrivent l’ampleur d’un changement de code source. Elles ne mesurent pas directement un stockage plus rapide, moins de défauts ou une réduction précise des heures de maintenance.
L’argument le plus solide en faveur du nettoyage est donc structurel. Une solution de repli partagée préserve le calcul, tandis que la série retire des implémentations conçues pour une ancienne plage de capacités. Les affirmations sur les performances nécessitent des preuves supplémentaires.
Vue sous cet angle, la suppression de MMX dans Linux expliquée est l’histoire d’une réduction de la charge d’implémentation autour d’une capacité existante. Le noyau peut continuer à accomplir une tâche tout en abandonnant une méthode historique pour y parvenir. La pertinence de cet équilibre dépend en partie des utilisateurs restants.
La longue retraite de MMX reflète un changement dans le compromis de maintenance
Le jalon historique est réel, mais la date de lancement de MMX ne mesure ni l’ancienneté ni la valeur de chaque implémentation supprimée.
Intel a lancé le processeur Pentium avec la technologie MMX le 8 janvier 1997. Son lancement contemporain du Pentium MMX mettait l’accent sur les graphismes, la vidéo et l’audio. Une technologie commercialisée autour d’une expérience multimédia plus riche sur ordinateur personnel a fini par subsister dans les calculs de stockage du noyau.
Cette histoire explique pourquoi la proposition attire l’attention au-delà du développement du stockage. MMX était une fonctionnalité grand public visible, associée à une période reconnaissable de l’informatique personnelle. Ses dernières optimisations dans le noyau portent une charge symbolique que les travaux de nettoyage ordinaires reçoivent rarement.
Le symbolisme ne doit pas occulter la chronologie réelle. Une extension d’instructions peut précéder le code qui l’utilise. Qualifier cela de retrait d’une technologie de 1997 est exact ; supposer que chaque ligne de code supprimée date de 1997 exigerait des preuves distinctes.
La proposition s’inscrit également dans la continuité de suppressions antérieures. Biggers cite un commit précédent qui a éliminé les optimisations MMX pour les fonctions de mémoire, notamment memcpy(), copy_page() et clear_page(). Ces fonctions copient des données ou initialisent la mémoire, des activités distinctes du travail RAID restant.
Leur retrait antérieur modifie la manière d’interpréter l’événement actuel. Il s’agit de l’aboutissement d’une séquence de nettoyage plus ciblée, et non d’une décision soudaine d’exclure une technologie largement utilisée. RAID demeurait un cas isolé d’utilisation dans le noyau après la disparition d’autres travaux d’optimisation.
Une optimisation historique peut progressivement perdre sa justification initiale. Le matériel évolue, d’autres implémentations apparaissent et il devient plus difficile d’établir l’ampleur de la population utilisant le chemin le plus ancien. Le code peut rester fonctionnel tout au long de cette transition.
Cela soulève une question récurrente de maintenance : quelle attention continue un projet doit-il consacrer à un chemin dont le public réel est incertain ? La suppression est une réponse lorsque la capacité subsiste ailleurs. Conserver le code en est une autre lorsque les utilisateurs démontrent un avantage significatif.
Aucune de ces positions n’implique de dénigrer l’ancien matériel. Le travail de préservation répond à des objectifs différents de ceux de la maintenance d’un noyau généraliste actuel. Un passionné peut valoriser la reproduction d’un comportement historique, même lorsque celui-ci ne justifie plus une implémentation dédiée en amont.
L’inverse est également vrai. La nostalgie ne prouve pas qu’un code spécialisé dispose d’utilisateurs actifs, de tests actuels ou d’un avantage de performance utile. Ce sont des questions techniques qui méritent des preuves techniques.
L’enseignement plus large concerne les conditions de compatibilité. Maintenir un algorithme disponible, conserver une optimisation propre à un processeur et prendre en charge une machine complète sont des engagements distincts. Un projet peut modifier l’un tout en laissant les autres soumis à leurs propres exigences.
Pour les développeurs, c’est un exemple utile de la façon dont les logiciels vieillissent sans simplement cesser de fonctionner. Une optimisation peut passer d’essentielle à facultative, puis devenir difficile à justifier. Son retrait reflète alors un compromis de maintenance modifié, plutôt qu’un jugement sur l’importance historique du matériel.
L’élément manquant est une mesure des performances sur le matériel concerné
Un repli préservé offre une voie vers la continuité de fonctionnement, et non une garantie de performances inchangées.
Les descriptions disponibles des correctifs expliquent pourquoi Biggers considère le code spécialisé comme obsolète. Elles ne fournissent pas de comparaison mesurée de machines concernées exécutant des charges de stockage représentatives avant et après le changement. Le coût pratique reste donc non résolu.
Cette lacune devrait limiter les affirmations dans les deux sens. Il serait prématuré de déclarer que chaque système concerné deviendra sensiblement plus lent. Il serait également prématuré de promettre que personne ne remarquera quoi que ce soit.
L’impact sur les performances d’Intel MMX dépend de la répartition du temps lors d’une opération réelle. Un calcul plus lent a une importance différente lorsque le traitement constitue le facteur limitant que lorsqu’un autre composant domine. La proposition seule n’établit pas cet équilibre pour une machine donnée.
Un test de calcul isolé répondrait à une question utile : comment l’ancienne implémentation se compare à son remplacement dans des conditions contrôlées. Une charge de stockage en éclairerait une autre : cette différence modifie-t-elle le travail réellement effectué par un opérateur ?
Ces résultats ne doivent pas être considérés comme interchangeables. Une différence visible de débit de calcul ne se traduit pas automatiquement par une différence équivalente de performances applicatives. De même, une charge de travail courante acceptable peut masquer une opération moins fréquente qui compte pour son propriétaire.
Pour un système de stockage préservé, les activités de maintenance peuvent être aussi pertinentes que l’accès quotidien. Un opérateur peut se soucier des opérations de récupération, des écritures soutenues ou de la disponibilité du processeur pendant d’autres tâches. Il s’agit de domaines d’évaluation proposés, et non de régressions mesurées établies par la série.
L’objection la plus solide proviendrait donc de résultats reproductibles sur une configuration concernée. De telles preuves pourraient montrer que le chemin spécialisé conserve une valeur pratique. Elles donneraient aux examinateurs un élément plus concret qu’une hypothèse sur le nombre de vieilles machines restantes.
L’argument le plus solide en faveur de la suppression combinerait la continuité de la correction avec un comportement acceptable sur le matériel pertinent. Cela renforcerait l’idée que l’implémentation partagée répond aux besoins restants. Là encore, l’existence de la proposition ne remplace pas ces observations.
Les affirmations de compatibilité nécessitent une retenue similaire. La suppression de ces fichiers d’optimisation n’établit pas une modification du format d’une grappe stockée. Elle ne certifie pas non plus que chaque ancien système puisse démarrer un futur noyau.
Les utilisateurs doivent évaluer l’environnement complet de mise à niveau, y compris les exigences de la distribution et leur configuration matérielle. Une modification limitée du code source ne peut répondre à toutes les questions sur la prise en charge future d’une machine. La présenter ainsi confondrait des décisions distinctes.
Il n’existe pas non plus ici de fondement pour promouvoir une vaste amélioration de la sécurité. Réduire le code spécialisé peut simplifier la revue, mais la justification soumise n’identifie aucune vulnérabilité corrigée par cette suppression. Les bénéfices de maintenance doivent rester des affirmations de maintenance, sauf si des preuves supplémentaires justifient davantage.
La lecture responsable est donc mesurée. La série offre un moyen crédible de réduire la complexité héritée tout en préservant les calculs. Le débat restant concerne la valeur de l’accélération retirée et les preuves nécessaires pour évaluer cette valeur.
Surveillez l’intégration, les tests de repli et la livraison par les distributions
Les prochaines évolutions utiles sont des jalons observables : l’intégration dans la branche principale, les tests sur les systèmes concernés et la livraison dans des paquets de noyau réels.
Tout d’abord, observez si la série atteint la branche principale du noyau et quelle version l’intègre. Linux 7.5 reste la destination attendue rapportée. Une fusion confirmée renforcerait le récit propre à cette version et fournirait une modification définitive aux examinateurs en aval.
Une révision, un retard ou un retrait modifierait cette évaluation. La proposition plus large resterait documentée, mais le calendrier de sortie anticipé devrait être mis à jour. Les lecteurs devraient éviter de transformer un rapport portant sur l’arbre de développement en note de publication inconditionnelle.
La version exacte fusionnée importera également. La revue peut modifier la portée ou les détails d’implémentation, même si l’orientation générale demeure. Suivre le changement accepté offre une base plus solide pour l’analyse de compatibilité que de s’appuyer indéfiniment sur la soumission initiale.
Ensuite, surveillez les résultats de correction et de performances provenant de matériel qui utilise réellement les chemins retirés. Des tests sur un processeur plus récent non concerné ne peuvent pas déterminer l’expérience d’un système hérité affecté. La comparaison pertinente exige une configuration correspondante et une charge de travail claire.
Un rapport crédible devrait distinguer le fonctionnement réussi d’une vitesse satisfaisante. Il devrait également expliquer ce qui a été mesuré et si l’ancienne implémentation était sélectionnée avant le changement. Sans ce contexte, un résultat peut être exact tout en restant sans rapport avec le compromis proposé.
Des résultats acceptables renforceraient l’argument selon lequel le code générique peut répondre au besoin restant. Une régression reproductible ayant des conséquences opérationnelles l’affaiblirait. L’une ou l’autre issue améliorerait la discussion en remplaçant les hypothèses par des preuves.
Enfin, surveillez la livraison par les distributions. Une version en amont ne détermine pas à quel moment la distribution choisie par un utilisateur empaquettera ce noyau ou prendra en charge sa machine. La configuration des paquets et les exigences du processeur restent partie intégrante de la décision pratique de mise à niveau.
Pour une personne qui maintient un ancien système, le jalon significatif est un noyau disponible qui convient à l’environnement complet. D’ici là, la proposition constitue une information utile à la planification, plutôt qu’une instruction immédiate de remplacer le matériel.
Ces observations permettent également de maintenir le récit historique dans des proportions appropriées. Ce retrait mérite l’attention parce qu’il clôt un chapitre identifiable de l’optimisation du noyau. Son importance technique dépendra de ce qui sera fusionné, du comportement des chemins restants et des personnes qui rencontreront le changement.
Pour les équipes d’ingénierie, documenter ces distinctions peut empêcher qu’un titre ne devienne une hypothèse de compatibilité non étayée. Une base de connaissances consultable peut relier le correctif accepté, la configuration locale et les résultats de test lors de l’évaluation des mises à niveau.
Si vous maintenez du matériel concerné, commencez par la configuration que vous utilisez réellement et les tâches de stockage qu’il doit accomplir. Enregistrez l’implémentation sélectionnée avant de tester un noyau contenant le changement. Comparez des résultats qui reflètent votre charge de travail et distinguez la correction de la vitesse. Si vous maintenez des systèmes plus récents, suivez le correctif accepté au lieu de considérer chaque référence à MMX comme un avertissement de compatibilité. La suppression de Linux MMX sera surtout informative en tant que décision de maintenance documentée, dont les avantages et les coûts sont liés à un comportement observable. Suivez la fusion, examinez les rapports de test pertinents et vérifiez les exigences de votre distribution avant de décider ce que ce retrait signifie pour vos machines.
