Usunięcie MMX z Linuxa dotyczy ostatnich optymalizacji RAID z ery Pentium

Programiści Linuxa przygotowują się do usunięcia z jądra ostatnich optymalizacji Intel MMX, zamykając rozdział rozpoczęty wraz z procesorami Pentium w 1997 roku. Propozycja usunięcia MMX z Linuxa dotyczy wyspecjalizowanych obliczeń pamięci masowej, przy zachowaniu istniejących programowych mechanizmów awaryjnych. Jej główny kompromis jest prosty: mniej starszego kodu dla opiekunów projektu, kosztem możliwego spadku wydajności w wyjątkowo starych systemach.

MMX, rozszerzenie instrukcji Intela do przetwarzania danych pakietowych, kiedyś pomagało oprogramowaniu przyspieszać multimedia i inne powtarzalne obliczenia. Pozostałe implementacje jądra obsługują programowy RAID, który łączy dyski pod kontrolą systemu operacyjnego. Implementacje te czeka teraz wycofanie, ponieważ ogólne alternatywy już wykonują tę samą pracę.

Oczekiwanym celem jest Linux 7.5, przewidywany na 2027 rok, lecz nadal pozostaje to oczekiwaniem dotyczącym wydania, a nie ukończonym scaleniem z główną gałęzią. Dla właścicieli sprzętu, którego to dotyczy, rozróżnienie ma znaczenie. Ta propozycja zmienia sposób wykonywania określonych obliczeń pamięci masowej; sama w sobie nie przesądza, że każdy komputer z ery Pentium będzie mógł uruchomić przyszłe jądro.

Usunięcie MMX z Linuxa wykracza poza pojedynczą procedurę XOR

Propozycja usuwa niewielką rodzinę starszych implementacji RAID, zamiast wyłączać funkcję pamięci masowej, którą przyspieszają.

Eric Biggers przesłał serię 25 października 2026 roku. Jego propozycja wycofania MMX zawiera trzy poprawki dotyczące XOR, RAID6 i kontroli funkcji procesora. Przesłane zmiany obejmują siedem plików, dodając 12 linii i usuwając 837.

XOR, operacja bitowa łącząca wartości, pomaga obliczać parzystość, czyli nadmiarową informację wykorzystywaną do odtworzenia brakujących danych. RAID6, układ pamięci masowej zaprojektowany tak, by tolerować awarie dwóch dysków, wymaga dodatkowych obliczeń poza podstawowym XOR. Traktowanie całej serii jako jednej usuniętej procedury XOR zaniżałoby zatem jej zakres.

To rozróżnienie zapobiega również przesadnej interpretacji nagłówka. Usunięcie zoptymalizowanej implementacji zmienia dostępne ścieżki wykonania. Usunięcie obsługi RAID wyeliminowałoby funkcję pamięci masowej. Przesłana propozycja opisuje pierwszą z tych sytuacji, przy czym procesory, których to dotyczy, korzystają z istniejącego kodu ogólnego.

Phoronix poinformował, że prace trafiły do drzewa rozwojowego MM Andrew Mortona i wskazał Linux 7.5 jako prawdopodobny cel. Jego materiał o MMX w jądrze przedstawia docelowe wydanie jako oczekiwanie. Na dzień 9 listopada jest to właściwe sformułowanie dla czytelników planujących zmiany w związku z tą aktualizacją.

Drzewo rozwojowe stanowi dowód, że prace zmierzają ku integracji. Nie czyni jednak proponowanego celu wydawniczego bezwarunkowym. Przegląd, decyzje integracyjne i późniejsze poprawki nadal mogą wpłynąć na to, co trafi do finalnego jądra.

Dla czytelników, którzy poznają wyjaśnienie usunięcia MMX z Linuxa przez nostalgiczne nagłówki, rozróżnienie statusu zasługuje na uwagę przed historią. Zweryfikowanym wydarzeniem jest przesłana seria porządkowa wraz z doniesieniem o jej trafieniu do drzewa rozwojowego. Przyszłym wydarzeniem jest oczekiwane włączenie jej do wydania głównej gałęzi.

Równie istotna jest granica praktyczna. Seria dotyczy implementacji wewnątrz jądra, czyli rdzenia systemu operacyjnego. Nie opisuje ogólnego zakazu używania przez aplikacje instrukcji MMX ani nie zapowiada, że procesory Intela przestaną je rozpoznawać.

Ta granica zmienia znaczenie „końca pewnej ery”. Jądro zakończyłoby wycofywanie własnych prac optymalizacyjnych specyficznych dla MMX. Szerszy ekosystem oprogramowania, w tym historyczne aplikacje i zachowane systemy operacyjne, ma odrębny cykl życia.

Dla opiekunów projektu propozycja stanowi konkretną okazję do uproszczenia zachowanego fragmentu kodu. Dla użytkowników rodzi węższe pytanie: czy ich konkretny komputer wybiera dziś jedną z tych implementacji. To pytanie prowadzi bezpośrednio do wymagań sprzętowych.

Systemy, których to dotyczy, znajdują się poniżej różnych progów instrukcji

Istotną linią podziału są możliwości procesora i obciążenie, a nie po prostu to, czy komputer nosi oznaczenie Pentium.

Poprawka Biggersa usuwająca XOR wskazuje, że ścieżka, której to dotyczy, obsługuje stare 32-bitowe procesory bez wsparcia SSE. SSE, Streaming SIMD Extensions, to późniejsze rozszerzenie instrukcji do przetwarzania wielu elementów danych. Poprawka ogranicza też istotne użycie do systemów faktycznie uruchamiających macierz RAID.

Poprawka RAID6 wyznacza inną granicę: procesory bez SSE2, kolejnego rozszerzenia z tej rodziny instrukcji. Jej zmiany implementacji RAID6 usuwają również plik o nazwie sse1.c. Biggers wyjaśnia, że implementacja nadal używała obliczeń MMX, uzupełnionych operacjami pamięci SSE.

Ta nazwa pliku jest pouczającym szczegółem. Pobieżny przegląd mógłby sugerować, że seria usuwa niezależny, nowoczesny zamiennik obok MMX. Opis poprawki wskazuje jednak na inną implementację zbudowaną wokół starszego mechanizmu.

Dla każdego, kto ocenia wpływ MMX Intela na wydajność, te odrębne progi mają znaczenie. Obsługa SSE przez procesor nie rozstrzyga automatycznie, czy dotyczy go każda część serii. Wybrana implementacja i dane obliczenie RAID określają właściwe porównanie.

Rozważmy hipotetycznego entuzjastę uruchamiającego obsługiwaną konfigurację jądra na zachowanym komputerze pamięci masowej z Pentium II. Jeśli jego macierz korzysta z wycofywanej implementacji, praktyczna zmiana dotyczyłaby wydajności obliczeń. Obecność mechanizmu awaryjnego oznacza, że proponowane usunięcie kodu nie eliminuje automatycznie tych obliczeń.

Rozważmy teraz programistę czytającego ten sam nagłówek na współczesnej stacji roboczej. Sam wiek rozszerzenia instrukcji MMX niewiele mówi o implementacji pamięci masowej wybranej na tej stacji. Przydatnym dowodem byłyby rzeczywiste możliwości procesora i zachowanie jądra.

Te przykłady ilustrują zakres oddziaływania, a nie ustalają zmierzone wyniki. Przeanalizowany materiał nie zawiera zestawienia aktywnych maszyn korzystających z wycofywanych ścieżek. Nie może zatem stanowić podstawy dla precyzyjnego oszacowania liczby użytkowników, których to dotyczy.

Osobami stojącymi przed istotną decyzją są operatorzy łączący stare możliwości procesorów z odpowiednim obciążeniem pamięci masowej. Musieliby ustalić, czy aktualizacja zmienia wybraną przez nich implementację oraz czy wynikające z tego spowolnienie ma znaczenie.

Opiekunowie dystrybucji stoją przed powiązanym zadaniem komunikacyjnym. Konfiguracja ich jądra, dostępność pakietów i wymagania dotyczące procesora pozostają odrębne od tego porządkowania optymalizacji. Użytkownicy potrzebują tych szczegółów, zanim uznają przyszłe wydanie za opcję aktualizacji dla zachowanego sprzętu.

Kompromis związany z utrzymaniem dotyczy więc wąskiego grona technicznych odbiorców o potencjalnie konkretnych potrzebach. Niewielki zakres oddziaływania nie oznacza jego braku. Oznacza, że reakcja powinna opierać się na rzeczywistych dowodach dotyczących sprzętu i obciążenia, a nie na emocjonalnej wadze znajomej nazwy procesora.

Kod ogólny zachowuje funkcję, ograniczając liczbę szczególnych przypadków

Propozycja oddziela zachowanie funkcji od zachowania każdej historycznej implementacji tej funkcji.

Skalarny mechanizm awaryjny, zwykły kod przetwarzający wartości bez wycofywanej implementacji MMX, daje opiekunom projektu taką możliwość. Biggers opisuje istniejące mechanizmy awaryjne jako dobrze przetestowane. To wskazana przez autora podstawa zachowania funkcjonalności przy usuwaniu wyspecjalizowanych ścieżek.

Sformułowanie to zasługuje na właściwy zakres. Wspiera argument propozycji dotyczący ciągłości, lecz nie jest opublikowanym benchmarkiem dla każdej maszyny, której to dotyczy. Poprawne wyniki i równoważna szybkość to różne właściwości.

Logikę utrzymania łatwiej zrozumieć, postrzegając ją jako wybór między implementacjami. Wyspecjalizowany kod może uzasadniać swoją obecność, jeśli służy użytkownikom lub zapewnia użyteczną wydajność. Jego dalsze istnienie tworzy również materiał, który recenzenci muszą rozumieć przy zmianach powiązanego kodu.

Kod ogólny oferuje wspólne miejsce do utrzymywania zachowania. Nie czyni to każdej wyspecjalizowanej implementacji zbędną. Zmienia dowody wymagane do zachowania starej implementacji: powinna istnieć praktyczna korzyść warta utrzymania.

W tym miejscu usunięcie MMX z Linuxa staje się ciekawsze niż historyczna rocznica. Projekt rozważa pozostałą ścieżkę wydajnościową wobec złożoności jej dalszego utrzymywania. Istnienie działającej alternatywy umożliwia usunięcie bez czynienia tej decyzji pozbawioną kosztów.

Trzecia poprawka rozszerza to uproszczenie na kontrole funkcji procesora, które wybierają odpowiednie implementacje na podstawie dostępnych możliwości sprzętowych. Biggers proponuje usunięcie zbędnych kontroli warunków wstępnych i unikanie powtarzanych kontroli tych samych funkcji. Przesłany kod zachowuje nowsze implementacje, w tym ścieżki SSE2 i AVX2.

AVX2, późniejsze rozszerzenie instrukcji wektorowych, stanowi inną drogę do przetwarzania wielu wartości w jednej operacji. Jego obecność ilustruje techniczne porównanie wyraźniej niż rywalizacja marek. Problemem jest to, która implementacja odpowiada procesorowi i nadal jest warta utrzymywania.

Nazwa Intela dominuje w historii, ponieważ firma wprowadziła MMX. Faktyczna decyzja dotycząca utrzymania dotyczy obsługiwanych funkcji procesora, a nie marki producenta. Porównywanie historycznych produktów Intela i AMD nie rozstrzygnęłoby, czy konkretna implementacja jądra nadal zasługuje na swoje miejsce.

To samo rozumowanie wyjaśnia, dlaczego redukcja liczby linii wymaga ostrożnej interpretacji. Mniejsza liczba linii opisuje rozmiar zmiany w kodzie źródłowym. Nie mierzy bezpośrednio szybszej pamięci masowej, mniejszej liczby błędów ani określonego skrócenia czasu utrzymania.

Najmocniejszy argument za porządkowaniem jest zatem strukturalny. Wspólny mechanizm awaryjny zachowuje obliczenia, podczas gdy seria usuwa implementacje przeznaczone dla starszego zakresu możliwości. Twierdzenia dotyczące wydajności wymagają dodatkowych dowodów.

W tym ujęciu wyjaśnienie usunięcia MMX z Linuxa jest historią o zawężaniu obciążenia związanego z implementacją wokół istniejącej funkcji. Jądro może nadal wykonywać zadanie, wycofując jedną historyczną metodę jego realizacji. To, czy taka równowaga jest właściwa, zależy częściowo od pozostałych użytkowników.

Długie wycofywanie MMX odzwierciedla zmieniający się kompromis w utrzymaniu

Historyczny kamień milowy jest rzeczywisty, lecz data premiery MMX nie mierzy wieku ani wartości każdej usuniętej implementacji.

Intel wprowadził procesor Pentium z technologią MMX 8 stycznia 1997 roku. Jego ówczesna premiera Pentium MMX podkreślała grafikę, wideo i dźwięk. Technologia promowana wokół bogatszych multimediów na komputerach osobistych ostatecznie przetrwała w obliczeniach pamięci masowej jądra.

Ta historia wyjaśnia, dlaczego propozycja przyciąga uwagę wykraczającą poza rozwój pamięci masowej. MMX było widoczną funkcją konsumencką, kojarzoną z rozpoznawalnym okresem w historii komputerów osobistych. Jego ostatnie optymalizacje jądra niosą symboliczny ciężar, którego zwykłe prace porządkowe rzadko otrzymują.

Symbolika nie powinna przesłaniać rzeczywistej chronologii. Rozszerzenie instrukcji może poprzedzać kod, który z niego korzysta. Nazwanie tego wycofaniem technologii z 1997 roku jest trafne; założenie, że każda usunięta linia kodu źródłowego pochodzi z 1997 roku, wymagałoby odrębnych dowodów.

Propozycja jest również kontynuacją wcześniejszych usunięć. Biggers wskazuje na poprzedni commit, który wyeliminował optymalizacje MMX dla funkcji pamięciowych, w tym memcpy(), copy_page() i clear_page(). Funkcje te kopiują dane lub inicjalizują pamięć — działania niezależne od pozostałej obsługi RAID.

Ich wcześniejsze wycofanie zmienia sposób postrzegania obecnego wydarzenia. To zakończenie węższej sekwencji porządkowania kodu, a nie nagła decyzja o usunięciu szeroko używanej technologii. RAID pozostał odosobnionym zastosowaniem w jądrze po zniknięciu innych prac optymalizacyjnych.

Historyczna optymalizacja może stopniowo tracić pierwotne uzasadnienie. Sprzęt się zmienia, pojawiają się alternatywne implementacje, a ustalenie liczby użytkowników najstarszej ścieżki staje się trudniejsze. Kod może pozostać funkcjonalny przez cały okres tej transformacji.

Prowadzi to do powracającego pytania o utrzymanie: jak wiele ciągłej uwagi projekt powinien poświęcać ścieżce, której praktyczna grupa odbiorców jest niepewna? Usunięcie jest jedną z odpowiedzi, gdy dana funkcja pozostaje dostępna gdzie indziej. Zachowanie kodu jest inną, gdy użytkownicy wykazują istotną korzyść.

Żadne z tych stanowisk nie wymaga lekceważenia starego sprzętu. Praca nad zachowaniem historycznych systemów ma inne cele niż utrzymywanie współczesnego jądra ogólnego przeznaczenia. Entuzjasta może cenić możliwość odtworzenia historycznego zachowania, nawet jeśli nie uzasadnia ono już dedykowanej implementacji w głównym nurcie projektu.

Działa to również w drugą stronę. Nostalgia nie dowodzi, że specjalistyczny kod ma aktywnych użytkowników, bieżące testy ani użyteczną przewagę wydajnościową. To pytania techniczne, które zasługują na techniczne dowody.

Szersza lekcja dotyczy warunków kompatybilności. Utrzymanie dostępności algorytmu, zachowanie optymalizacji dla określonego procesora i obsługa kompletnej maszyny to odrębne zobowiązania. Projekt może zmienić jedno z nich, pozostawiając pozostałe zależne od własnych wymagań.

Dla deweloperów jest to użyteczny przykład tego, jak oprogramowanie się starzeje, nie przestając po prostu działać. Optymalizacja może przejść od niezbędnej do opcjonalnej, a następnie trudnej do uzasadnienia. Jej wycofanie odzwierciedla wtedy zmianę warunków utrzymania, a nie ocenę historycznego znaczenia sprzętu.

Brakującym dowodem są zmierzone wyniki wydajności na objętym zmianą sprzęcie

Zachowany mechanizm awaryjny zapewnia drogę do dalszego działania, a nie gwarancję niezmienionej wydajności.

Dostępne opisy patchy wyjaśniają, dlaczego Biggers uważa specjalistyczny kod za przestarzały. Nie przedstawiają jednak pomiarowego porównania maszyn objętych zmianą, uruchamiających reprezentatywne obciążenia pamięci masowej przed i po zmianie. Praktyczny koszt pozostaje więc nierozstrzygnięty.

Ta luka powinna ograniczać twierdzenia w obu kierunkach. Byłoby przedwczesne deklarowanie, że każdy objęty zmianą system wyraźnie zwolni. Równie przedwczesne byłoby zapewnianie, że nikt nie zauważy różnicy.

Wpływ MMX Intela na wydajność zależy od tego, gdzie podczas rzeczywistej operacji spędzany jest czas. Wolniejsze obliczenia mają inne znaczenie, gdy przetwarzanie jest czynnikiem ograniczającym, a inne, gdy dominuje inny komponent. Sama propozycja nie ustala tej równowagi dla konkretnej maszyny.

Test pojedynczych obliczeń odpowiedziałby na jedno użyteczne pytanie: jak stara implementacja wypada w porównaniu z jej następcą w kontrolowanych warunkach. Obciążenie pamięci masowej odpowiedziałoby na inne: czy ta różnica zmienia pracę, którą operator faktycznie wykonuje.

Wyników tych nie należy traktować jako zamiennych. Widoczna różnica w przepustowości obliczeń nie przekłada się automatycznie na równoważną różnicę w wydajności aplikacji. Podobnie akceptowalne obciążenie rutynowe może nie ujawnić rzadszej operacji, która ma znaczenie dla właściciela systemu.

W przypadku zachowanego systemu pamięci masowej czynności utrzymaniowe mogą być równie istotne jak codzienny dostęp. Operator może zwracać uwagę na pracę odzyskiwania danych, długotrwałe zapisy lub dostępność procesora podczas innych zadań. To proponowane obszary oceny, a nie zmierzone regresje potwierdzone przez serię zmian.

Najsilniejszy sprzeciw wynikałby z powtarzalnych wyników uzyskanych na objętej zmianą konfiguracji. Takie dowody mogłyby wykazać, że specjalistyczna ścieżka zachowuje praktyczną wartość. Dałyby recenzentom coś bardziej konkretnego niż założenie dotyczące liczby pozostających starych maszyn.

Najsilniejsze poparcie łączyłoby ciągłą poprawność działania z akceptowalnym zachowaniem na odpowiednim sprzęcie. Wzmocniłoby to argument, że wspólna implementacja spełnia pozostałe potrzeby. Ponownie, samo istnienie propozycji nie zastępuje takich obserwacji.

Twierdzenia dotyczące kompatybilności wymagają podobnej ostrożności. Usunięcie tych plików optymalizacji nie oznacza zmiany formatu zapisanej macierzy. Nie potwierdza też, że każdy stary system będzie mógł uruchomić przyszłe jądro.

Użytkownicy muszą ocenić całe środowisko aktualizacji, w tym wymagania dystrybucji oraz konfigurację sprzętową. Wąska zmiana w kodzie źródłowym nie może odpowiedzieć na wszystkie pytania o przyszłe wsparcie dla maszyny. Przedstawianie jej w ten sposób mieszałoby odrębne decyzje.

Nie ma tu również podstaw, by reklamować szeroką poprawę bezpieczeństwa. Ograniczenie specjalistycznego kodu może uprościć przegląd, lecz przedstawione uzasadnienie nie wskazuje podatności naprawianej przez to usunięcie. Korzyści utrzymaniowe powinny pozostać twierdzeniami dotyczącymi utrzymania, chyba że dodatkowe dowody uzasadnią więcej.

Odpowiedzialna interpretacja jest zatem wyważona. Seria oferuje wiarygodny sposób ograniczenia złożoności starszego kodu przy zachowaniu obliczeń. Pozostała debata dotyczy wartości usuwanego przyspieszenia oraz dowodów potrzebnych do jej oceny.

Obserwuj integrację, testy mechanizmu awaryjnego i dostarczanie przez dystrybucje

Kolejne użyteczne wydarzenia to obserwowalne kamienie milowe: integracja z główną linią rozwoju, testy na objętych zmianą systemach oraz dostarczenie przez rzeczywiste pakiety jądra.

Najpierw warto obserwować, czy seria trafi do głównej linii jądra i które wydanie ją obejmie. Linux 7.5 pozostaje zgłaszanym, oczekiwanym celem. Potwierdzone scalenie wzmocniłoby opowieść dotyczącą konkretnego wydania i zapewniło ostateczną zmianę dla recenzentów projektów zależnych.

Rewizja, opóźnienie lub wycofanie zmieniłyby tę ocenę. Szersza propozycja nadal byłaby udokumentowana, ale przewidywany termin wydania wymagałby aktualizacji. Czytelnicy powinni unikać przekształcania raportu o drzewie rozwojowym w bezwarunkową informację o wydaniu.

Znaczenie będzie miała także dokładna wersja po scaleniu. Przegląd może zmienić zakres lub szczegóły implementacji, nawet jeśli ogólny kierunek zostanie zachowany. Śledzenie zaakceptowanej zmiany zapewnia pewniejszą podstawę analizy kompatybilności niż nieograniczone poleganie na pierwotnym zgłoszeniu.

Po drugie, należy obserwować wyniki poprawności i wydajności ze sprzętu, który faktycznie korzysta z wycofywanych ścieżek. Testy na niezwiązanym z nimi nowszym procesorze nie mogą rozstrzygnąć doświadczeń systemu starszej generacji objętego zmianą. Odpowiednie porównanie wymaga zgodnej konfiguracji i jasno określonego obciążenia.

Wiarygodny raport powinien odróżniać udane działanie od zadowalającej szybkości. Powinien też wyjaśniać, co zostało zmierzone i czy przed zmianą wybrano starą implementację. Bez tego kontekstu wynik może być dokładny, lecz nieistotny dla proponowanego kompromisu.

Akceptowalne wyniki wzmocniłyby argument, że kod ogólny może spełnić pozostałą potrzebę. Powtarzalna regresja o skutkach operacyjnych osłabiłaby go. Każdy z tych wyników poprawiłby dyskusję, zastępując założenia dowodami.

Po trzecie, należy obserwować dostarczanie przez dystrybucje. Wydanie upstream nie określa, kiedy wybrana przez użytkownika dystrybucja spakuje dane jądro ani czy będzie obsługiwać jego maszynę. Konfiguracja pakietów i wymagania procesora nadal stanowią część praktycznej decyzji o aktualizacji.

Dla osoby utrzymującej stary system znaczącym kamieniem milowym jest dostępne jądro pasujące do całego środowiska. Do tego czasu propozycja jest istotną informacją do planowania, a nie natychmiastową instrukcją wymiany sprzętu.

Te obserwacje pomagają także zachować właściwe proporcje w historycznej narracji. Wycofanie zasługuje na uwagę, ponieważ zamyka rozpoznawalny rozdział optymalizacji jądra. Jego techniczne znaczenie będzie zależeć od tego, co zostanie scalone, jak zachowają się pozostałe ścieżki i kto napotka tę zmianę.

Dla zespołów inżynieryjnych dokumentowanie tych rozróżnień może zapobiec przekształceniu nagłówka w niepotwierdzone założenie dotyczące kompatybilności. Przeszukiwalna baza wiedzy może połączyć zaakceptowany patch, lokalną konfigurację i wyniki testów podczas oceny aktualizacji.

Jeśli utrzymujesz sprzęt objęty zmianą, zacznij od konfiguracji, z której faktycznie korzystasz, oraz pracy związanej z pamięcią masową, którą musi on wykonywać. Zapisz wybraną implementację przed testowaniem jądra zawierającego zmianę. Porównuj wyniki odzwierciedlające Twoje obciążenie i oddziel poprawność od szybkości. Jeśli utrzymujesz nowsze systemy, śledź zaakceptowany patch, zamiast traktować każdą wzmiankę o MMX jako ostrzeżenie dotyczące kompatybilności. Usunięcie MMX z Linuxa będzie najbardziej pouczające jako udokumentowana decyzja utrzymaniowa, której korzyści i koszty są powiązane z obserwowalnym zachowaniem. Śledź scalenie, analizuj odpowiednie raporty z testów i sprawdzaj wymagania swojej dystrybucji, zanim zdecydujesz, co to wycofanie oznacza dla Twoich maszyn.