La rimozione di MMX da Linux punta alle ultime ottimizzazioni RAID dell'era Pentium

Gli sviluppatori Linux si stanno preparando a rimuovere le ultime ottimizzazioni Intel MMX dal kernel, chiudendo un capitolo iniziato con i processori Pentium nel 1997. La proposta di rimozione di MMX da Linux riguarda calcoli di archiviazione specializzati, preservando al contempo i fallback software esistenti. Il compromesso centrale è semplice: meno codice legacy da mantenere, con un possibile costo prestazionale per sistemi insolitamente datati.

MMX, l'estensione di istruzioni Intel per l'elaborazione di dati impacchettati, un tempo aiutava il software ad accelerare la multimedialità e altri calcoli ripetitivi. Le implementazioni del kernel ancora presenti servono il RAID software, che combina unità sotto il controllo del sistema operativo. Queste implementazioni sono ora destinate al ritiro perché le alternative generiche svolgono già lo stesso lavoro.

La destinazione prevista è Linux 7.5, atteso nel 2027, ma si tratta ancora di un'aspettativa di rilascio e non di un'integrazione già completata nel mainline. Per i proprietari dell'hardware interessato, la distinzione conta. Questa proposta cambia il modo in cui vengono eseguiti determinati calcoli di archiviazione; non stabilisce di per sé che ogni computer dell'era Pentium possa eseguire un kernel futuro.

La rimozione di MMX da Linux va oltre una singola routine XOR

La proposta rimuove una piccola famiglia di implementazioni RAID legacy, anziché disabilitare la funzionalità di archiviazione che queste accelerano.

Eric Biggers ha inviato la serie il 25 ottobre 2026. La sua proposta di ritiro di MMX contiene tre patch dedicate a XOR, RAID6 e ai controlli delle funzionalità del processore. Le modifiche inviate interessano sette file, aggiungendo 12 righe e rimuovendone 837.

XOR, un'operazione bit a bit che combina valori, aiuta a calcolare la parità, ovvero le informazioni ridondanti usate per ricostruire dati mancanti. RAID6, una configurazione di archiviazione progettata per tollerare il guasto di due unità, richiede calcoli aggiuntivi oltre al semplice XOR. Considerare quindi l'intera serie come una sola routine XOR eliminata ne sottostima la portata.

La distinzione evita anche una lettura esagerata del titolo. Rimuovere un'implementazione ottimizzata cambia i percorsi di esecuzione disponibili. Rimuovere il supporto RAID eliminerebbe una capacità di archiviazione. La proposta inviata descrive il primo caso, con i processori interessati che usano il codice generico esistente.

Phoronix ha riferito che il lavoro era arrivato nell'albero di sviluppo MM di Andrew Morton e ha indicato Linux 7.5 come probabile destinazione. La sua copertura del kernel MMX presenta l'obiettivo di rilascio come un'aspettativa. Al 9 novembre, questa è la formulazione appropriata per i lettori che pianificano in base al cambiamento.

Un albero di sviluppo fornisce prove che il lavoro sta avanzando verso l'integrazione. Non rende incondizionato un obiettivo di rilascio proposto. Revisione, decisioni di integrazione e revisioni successive possono ancora influenzare ciò che arriverà in un kernel finale.

Per i lettori che incontrano spiegazioni della rimozione di MMX da Linux attraverso titoli nostalgici, questa distinzione di stato merita attenzione prima della storia. L'evento verificato è una serie di pulizia inviata, con un approdo riportato in un albero di sviluppo. L'evento futuro è il suo previsto arrivo in una release mainline.

Il confine pratico è altrettanto importante. La serie riguarda implementazioni all'interno del kernel, il nucleo del sistema operativo. Non descrive un divieto generale per le applicazioni di usare istruzioni MMX, né annuncia che i processori Intel smetteranno di riconoscerle.

Questo confine cambia il significato di “fine di un'era”. Il kernel completerebbe il ritiro del proprio lavoro di ottimizzazione specifico per MMX. L'ecosistema software più ampio, comprese applicazioni storiche e sistemi operativi conservati, segue un ciclo di vita separato.

Per i manutentori, la proposta offre un'opportunità concreta per semplificare un angolo sopravvissuto del codice. Per gli utenti, solleva una domanda più circoscritta: se la loro macchina specifica selezioni oggi una di queste implementazioni. Questa domanda porta direttamente ai requisiti hardware.

I sistemi interessati si collocano sotto soglie di istruzioni differenti

La linea di demarcazione rilevante è costituita dalle capacità del processore e dal carico di lavoro, non semplicemente dal fatto che un computer porti il marchio Pentium.

La patch di rimozione XOR di Biggers identifica il percorso interessato come destinato a vecchi processori a 32 bit privi di supporto SSE. SSE, Streaming SIMD Extensions, è una successiva estensione di istruzioni per l'elaborazione di più elementi di dati. La patch limita inoltre l'uso rilevante ai sistemi che eseguono effettivamente un array RAID.

La patch RAID6 traccia un confine diverso: processori privi di SSE2, l'estensione successiva di quella famiglia di istruzioni. Le sue modifiche all'implementazione RAID6 rimuovono anche un file denominato sse1.c. Biggers spiega che questa implementazione usava ancora calcoli MMX, integrati da operazioni di memoria SSE.

Quel nome di file è un dettaglio istruttivo. Una rapida lettura potrebbe suggerire che la serie rimuova, insieme a MMX, un sostituto moderno e indipendente. La descrizione della patch identifica invece un'altra implementazione costruita attorno al meccanismo più vecchio.

Per chiunque stia valutando l'impatto sulle prestazioni di Intel MMX, queste soglie separate sono importanti. Il supporto di un processore per SSE non determina automaticamente la sua esposizione a ogni parte della serie. L'implementazione selezionata e il calcolo RAID coinvolto determinano il confronto rilevante.

Si consideri un ipotetico appassionato che esegue una configurazione del kernel supportata su una macchina di archiviazione Pentium II conservata. Se il suo array usa un'implementazione in fase di ritiro, il cambiamento pratico riguarderebbe le prestazioni di calcolo. La presenza di un fallback significa che la rimozione proposta del codice non elimina automaticamente quel calcolo.

Si consideri ora uno sviluppatore che legge lo stesso titolo su una workstation contemporanea. L'età dell'estensione di istruzioni MMX, da sola, dice poco sull'implementazione di archiviazione selezionata da quella workstation. Le prove utili sarebbero le effettive capacità del processore e il comportamento del kernel.

Questi esempi illustrano l'esposizione, anziché stabilire risultati misurati. Il materiale esaminato non fornisce un inventario delle macchine attive che utilizzano i percorsi in ritiro. Non può quindi sostenere una stima precisa degli utenti interessati.

Le persone che devono affrontare una decisione significativa sono gli operatori che combinano vecchie capacità del processore con il carico di lavoro di archiviazione pertinente. Dovrebbero stabilire se un aggiornamento modifica l'implementazione selezionata e se un eventuale rallentamento risultante è rilevante.

I manutentori delle distribuzioni affrontano un compito di comunicazione correlato. La configurazione del loro kernel, la disponibilità dei pacchetti e i requisiti del processore restano separati da questa pulizia delle ottimizzazioni. Gli utenti hanno bisogno di questi dettagli prima di interpretare una release futura come un'opzione di aggiornamento per hardware conservato.

Il compromesso di manutenzione raggiunge quindi un pubblico tecnico ristretto con esigenze potenzialmente specifiche. Una scarsa esposizione non significa nessuna esposizione. Significa che la risposta dovrebbe seguire prove sull'hardware e sul carico di lavoro effettivi, anziché il peso emotivo di un nome di processore familiare.

Il codice generico conserva la capacità riducendo i casi speciali

La proposta separa la conservazione di una funzione dalla conservazione di ogni implementazione storica di tale funzione.

Un fallback scalare, ossia codice ordinario che elabora valori senza l'implementazione MMX ritirata, offre ai manutentori questa possibilità. Biggers descrive i fallback esistenti come ben testati. Questa è la base dichiarata dall'autore per preservare la funzionalità rimuovendo al contempo i percorsi specializzati.

L'espressione merita la sua corretta portata. Supporta l'argomento di continuità della proposta, ma non è un benchmark pubblicato per ogni macchina interessata. Output corretto e velocità equivalente sono proprietà diverse.

La logica di manutenzione è più facile da comprendere se vista come una scelta tra implementazioni. Il codice specializzato può giustificare la propria presenza quando serve gli utenti o offre prestazioni utili. La sua esistenza continua crea inoltre materiale che i revisori devono comprendere quando cambia il codice correlato.

Il codice generico offre un luogo condiviso in cui mantenere il comportamento. Questo non rende superflua ogni implementazione specializzata. Cambia le prove necessarie per conservarne una vecchia: dovrebbe esserci un vantaggio pratico che valga la pena preservare.

È qui che la rimozione di MMX da Linux diventa più interessante di un anniversario storico. Il progetto sta valutando un percorso prestazionale rimanente rispetto alla complessità di portarlo avanti. L'esistenza di un'alternativa funzionante rende possibile l'eliminazione senza rendere la decisione priva di costi.

La terza patch estende questa semplificazione ai controlli delle funzionalità del processore, che selezionano implementazioni adatte dalle capacità hardware disponibili. Biggers propone di rimuovere controlli dei prerequisiti ridondanti ed evitare controlli ripetuti delle stesse funzionalità. Il codice inviato mantiene implementazioni più recenti, compresi i percorsi SSE2 e AVX2.

AVX2, una successiva estensione di istruzioni vettoriali, rappresenta un'altra via per elaborare più valori in un'operazione. La sua presenza illustra il confronto tecnico più chiaramente di quanto farebbe una rivalità tra marchi. La questione è quale implementazione sia adatta al processore e resti degna di manutenzione.

Il nome di Intel domina la storia perché ha introdotto MMX. La decisione di manutenzione effettiva riguarda le funzionalità del processore supportate, anziché il branding del fornitore. Confrontare prodotti Intel e AMD storici non risolverebbe se una particolare implementazione del kernel meriti ancora il proprio posto.

Lo stesso ragionamento spiega perché una riduzione del numero di righe richieda un'interpretazione attenta. Meno righe descrivono la dimensione di una modifica del sorgente. Non misurano direttamente un'archiviazione più veloce, meno difetti o una riduzione specifica delle ore di manutenzione.

Il caso più forte per questa pulizia è quindi strutturale. Un fallback condiviso preserva il calcolo, mentre la serie rimuove implementazioni destinate a una gamma di capacità più vecchia. Le affermazioni sulle prestazioni richiedono ulteriori prove.

Vista in questo modo, la spiegazione della rimozione di MMX da Linux è una storia di riduzione del carico di implementazione attorno a una capacità esistente. Il kernel può continuare a svolgere un compito ritirando un metodo storico per eseguirlo. Che questo equilibrio sia corretto dipende in parte dagli utenti rimanenti.

Il lungo ritiro di MMX riflette un cambiamento nel patto di manutenzione

La pietra miliare storica è reale, ma la data di lancio di MMX non misura l'età o il valore di ogni implementazione eliminata.

Intel ha introdotto il processore Pentium con tecnologia MMX l'8 gennaio 1997. Il suo lancio contemporaneo del Pentium MMX enfatizzava grafica, video e audio. Una tecnologia commercializzata attorno a contenuti multimediali più ricchi per personal computer è infine sopravvissuta nei calcoli di archiviazione del kernel.

Questa storia spiega perché la proposta attiri attenzione oltre lo sviluppo dello storage. MMX era una caratteristica di consumo visibile, associata a un periodo riconoscibile dell'informatica personale. Le sue ultime ottimizzazioni del kernel hanno un peso simbolico che il normale lavoro di pulizia riceve raramente.

Il simbolismo non dovrebbe oscurare la cronologia effettiva. Un'estensione di istruzioni può precedere il codice che la utilizza. Definire questo il ritiro di una tecnologia del 1997 è accurato; supporre che ogni riga di sorgente rimossa risalga al 1997 richiederebbe prove separate.

La proposta segue anche rimozioni precedenti. Biggers rimanda a un commit precedente che ha eliminato le ottimizzazioni MMX per le funzioni di memoria, incluse memcpy(), copy_page() e clear_page(). Queste funzioni copiano dati o inizializzano la memoria, attività distinte dal lavoro RAID rimanente.

Il loro precedente ritiro modifica il modo di inquadrare l’evento attuale. Si tratta del completamento di una sequenza di pulizia più circoscritta, non di una decisione improvvisa di espellere una tecnologia ampiamente usata. RAID era rimasto come un uso isolato nel kernel dopo la scomparsa degli altri interventi di ottimizzazione.

Un’ottimizzazione storica può perdere gradualmente la propria ragion d’essere originaria. L’hardware cambia, arrivano implementazioni alternative e diventa più difficile stabilire quante persone utilizzino il percorso più vecchio. Il codice può restare funzionale durante tutta questa transizione.

Questo solleva una ricorrente questione di manutenzione: quanta attenzione continuativa dovrebbe dedicare un progetto a un percorso il cui pubblico pratico è incerto? L’eliminazione è una risposta quando la funzionalità sopravvive altrove. Mantenere il codice è un’altra quando gli utenti dimostrano un beneficio significativo.

Nessuna delle due posizioni richiede di liquidare il vecchio hardware. Il lavoro di conservazione ha obiettivi diversi dalla manutenzione di un kernel generico contemporaneo. Un appassionato può attribuire valore alla riproduzione del comportamento storico anche quando quel comportamento non giustifica più un’implementazione upstream dedicata.

Vale anche il contrario. La nostalgia non dimostra che il codice specializzato abbia utenti attivi, test aggiornati o un vantaggio prestazionale utile. Sono questioni tecniche che meritano prove tecniche.

La lezione più ampia riguarda i termini della compatibilità. Mantenere disponibile un algoritmo, conservare un’ottimizzazione specifica per processore e supportare una macchina completa sono impegni distinti. Un progetto può modificarne uno lasciando gli altri soggetti ai rispettivi requisiti.

Per gli sviluppatori, questo è un esempio utile di come il software invecchi senza semplicemente rompersi. Un’ottimizzazione può passare da essenziale a facoltativa fino a diventare difficile da giustificare. Il suo ritiro riflette quindi un diverso patto di manutenzione, non un giudizio sull’importanza storica dell’hardware.

L’evidenza mancante è una misurazione delle prestazioni sull’hardware interessato

Un fallback conservato offre una strada per continuare a operare, non una garanzia di prestazioni invariate.

Le descrizioni delle patch disponibili spiegano perché Biggers considera obsoleto il codice specializzato. Non forniscono però un confronto misurato delle macchine interessate che eseguono carichi di lavoro di archiviazione rappresentativi prima e dopo la modifica. Il costo pratico rimane quindi irrisolto.

Questa lacuna dovrebbe limitare le affermazioni in entrambe le direzioni. Sarebbe prematuro dichiarare che ogni sistema interessato diventerà sensibilmente più lento. Sarebbe altrettanto prematuro promettere che nessuno noterà differenze.

L’impatto prestazionale di Intel MMX dipende da dove viene impiegato il tempo durante un’operazione reale. Un calcolo più lento conta diversamente quando l’elaborazione è il fattore limitante rispetto a quando domina un altro componente. La sola proposta non stabilisce tale equilibrio per una macchina specifica.

Un test isolato di calcolo risponderebbe a una domanda utile: come si confronta la vecchia implementazione con quella sostitutiva in condizioni controllate. Un carico di lavoro di archiviazione risponderebbe a un’altra: se tale differenza modifica il lavoro che un operatore svolge davvero.

Questi risultati non dovrebbero essere considerati intercambiabili. Una differenza visibile nella velocità di calcolo non si traduce automaticamente in una differenza equivalente nelle prestazioni dell’applicazione. Allo stesso modo, un carico di lavoro ordinario accettabile potrebbe trascurare un’operazione meno frequente ma importante per il suo proprietario.

Per un sistema di archiviazione conservato, le attività di manutenzione potrebbero essere rilevanti quanto l’accesso quotidiano. Un operatore potrebbe preoccuparsi del lavoro di ripristino, delle scritture sostenute o della disponibilità del processore durante altre attività. Si tratta di aree di valutazione proposte, non di regressioni misurate stabilite dalla serie.

L’obiezione più forte deriverebbe pertanto da risultati riproducibili su una configurazione interessata. Tali prove potrebbero mostrare che il percorso specializzato conserva un valore pratico. Offrirebbero ai revisori qualcosa di più concreto di un’ipotesi sul numero di vecchie macchine ancora in uso.

Il sostegno più forte combinerebbe la correttezza continuativa con un comportamento accettabile sull’hardware rilevante. Ciò rafforzerebbe l’argomento secondo cui l’implementazione condivisa soddisfa le esigenze residue. Ancora una volta, l’esistenza della proposta non sostituisce tali osservazioni.

Anche le affermazioni sulla compatibilità richiedono analoga prudenza. La rimozione di questi file di ottimizzazione non stabilisce una modifica al formato di un array archiviato. Non certifica nemmeno che ogni vecchio sistema possa avviare un futuro kernel.

Gli utenti devono valutare l’intero ambiente di aggiornamento, compresi i requisiti della distribuzione e la propria configurazione hardware. Una modifica circoscritta al codice sorgente non può rispondere a ogni domanda sul supporto futuro di una macchina. Presentarla in questo modo confonderebbe decisioni separate.

Non vi è inoltre alcuna base per pubblicizzare un ampio miglioramento della sicurezza. Ridurre il codice specializzato può semplificare la revisione, ma la motivazione presentata non identifica una vulnerabilità risolta da questa eliminazione. I benefici di manutenzione dovrebbero restare affermazioni di manutenzione, salvo ulteriori prove a sostegno di altro.

La lettura responsabile è quindi misurata. La serie offre un modo credibile per ridurre la complessità legacy preservando i calcoli. Il dibattito rimanente riguarda il valore dell’accelerazione rimossa e le prove necessarie per giudicarlo.

Monitorare l’integrazione, i test del fallback e la distribuzione

I prossimi sviluppi utili sono traguardi osservabili: integrazione nella mainline, test sui sistemi interessati e distribuzione tramite pacchetti kernel reali.

Innanzitutto, occorre osservare se la serie raggiungerà il kernel mainline e quale versione la conterrà. Linux 7.5 resta la destinazione prevista riportata. Un merge confermato rafforzerebbe la ricostruzione specifica della release e fornirebbe una modifica definitiva ai revisori downstream.

Una revisione, un rinvio o un ritiro cambierebbero questa valutazione. La proposta più ampia resterebbe documentata, ma la tempistica prevista per la release dovrebbe essere aggiornata. I lettori dovrebbero evitare di trasformare una notizia sull’albero di sviluppo in una nota di rilascio incondizionata.

Anche la versione esatta integrata sarà importante. La revisione può modificare l’ambito o i dettagli dell’implementazione anche se la direzione complessiva rimane invariata. Seguire la modifica accettata offre una base più solida per l’analisi della compatibilità rispetto ad affidarsi indefinitamente alla proposta iniziale.

In secondo luogo, occorre cercare risultati di correttezza e prestazioni provenienti dall’hardware che utilizza effettivamente i percorsi in dismissione. I test su un processore più recente non correlato non possono stabilire l’esperienza di un sistema legacy interessato. Il confronto rilevante richiede una configurazione corrispondente e un carico di lavoro chiaro.

Un rapporto credibile dovrebbe distinguere il funzionamento riuscito da una velocità soddisfacente. Dovrebbe inoltre spiegare cosa è stato misurato e se la vecchia implementazione era selezionata prima della modifica. Senza questo contesto, un risultato può essere accurato ma irrilevante rispetto al compromesso proposto.

Risultati accettabili rafforzerebbero l’argomento secondo cui il codice generico può soddisfare le esigenze residue. Una regressione riproducibile con conseguenze operative lo indebolirebbe. Entrambi gli esiti migliorerebbero la discussione sostituendo le ipotesi con prove.

In terzo luogo, occorre monitorare la distribuzione. Una release upstream non stabilisce quando la distribuzione scelta da un utente impacchetterà quel kernel o supporterà la sua macchina. La configurazione dei pacchetti e i requisiti del processore restano parte della decisione pratica di aggiornamento.

Per chi mantiene un vecchio sistema, il traguardo significativo è un kernel disponibile che si adatti all’ambiente completo. Fino ad allora, la proposta è un’informazione utile per la pianificazione, non un’istruzione immediata a sostituire l’hardware.

Queste osservazioni mantengono inoltre proporzionata la narrazione storica. Il ritiro merita attenzione perché chiude un capitolo riconoscibile nell’ottimizzazione del kernel. La sua importanza tecnica dipenderà da ciò che verrà integrato, da come si comporteranno i percorsi rimanenti e da chi incontrerà il cambiamento.

Per i team di ingegneria, documentare queste distinzioni può impedire che un titolo diventi un’ipotesi di compatibilità non supportata. Una base di conoscenza consultabile può collegare la patch accettata, la configurazione locale e i risultati dei test nella valutazione degli aggiornamenti.

Se gestisci hardware interessato, inizia dalla configurazione che utilizzi effettivamente e dal lavoro di archiviazione che ti serve svolgere. Registra l’implementazione selezionata prima di testare un kernel che contiene la modifica. Confronta risultati che riflettano il tuo carico di lavoro e separa la correttezza dalla velocità. Se gestisci sistemi più recenti, segui la patch accettata invece di trattare ogni riferimento a MMX come un avviso di compatibilità. La rimozione di Linux MMX sarà più istruttiva come decisione di manutenzione documentata, con benefici e costi legati a un comportamento osservabile. Segui il merge, esamina i rapporti di test rilevanti e verifica i requisiti della tua distribuzione prima di decidere cosa significhi questo ritiro per le tue macchine.