A remoção do MMX no Linux mira as últimas otimizações de RAID da era Pentium

Desenvolvedores do Linux estão se preparando para remover as últimas otimizações Intel MMX do kernel, encerrando um capítulo iniciado com os processadores Pentium em 1997. A proposta de remoção do MMX no Linux visa cálculos especializados de armazenamento, preservando as alternativas em software já existentes. A principal troca é direta: menos código legado para os mantenedores, com um possível custo de desempenho em sistemas excepcionalmente antigos.

MMX, a extensão de instruções da Intel para processar dados empacotados, já ajudou softwares a acelerar cálculos multimídia e outros cálculos repetitivos. As implementações restantes no kernel atendem ao RAID por software, que combina unidades sob controle do sistema operacional. Essas implementações agora enfrentam a aposentadoria porque alternativas genéricas já realizam o mesmo trabalho.

O destino esperado é o Linux 7.5, previsto para 2027, mas isso continua sendo uma expectativa de lançamento, e não uma integração concluída na linha principal. Para proprietários do hardware afetado, a distinção importa. Esta proposta altera como determinados cálculos de armazenamento são executados; ela não estabelece, por si só, que todo computador da era Pentium poderá executar um kernel futuro.

A remoção do MMX no Linux vai além de uma única rotina XOR

A proposta remove uma pequena família de implementações legadas de RAID, em vez de desativar o recurso de armazenamento que elas aceleram.

Eric Biggers enviou a série em 25 de outubro de 2026. Sua proposta de aposentadoria do MMX contém três patches que abrangem XOR, RAID6 e verificações de recursos do processador. As mudanças enviadas afetam sete arquivos, adicionando 12 linhas e removendo 837.

XOR, uma operação bit a bit que combina valores, ajuda a calcular a paridade, a informação redundante usada para reconstruir dados ausentes. RAID6, uma organização de armazenamento projetada para tolerar duas falhas de unidade, exige cálculos adicionais além do XOR básico. Portanto, tratar toda a série como uma única rotina XOR removida subestima seu escopo.

A distinção também evita uma interpretação exagerada da manchete. Remover uma implementação otimizada altera os caminhos de execução disponíveis. Remover o suporte a RAID eliminaria uma capacidade de armazenamento. A proposta enviada descreve o primeiro caso, com os processadores afetados usando código genérico já existente.

O Phoronix informou que o trabalho havia chegado à árvore de desenvolvimento MM de Andrew Morton e identificou o Linux 7.5 como o destino provável. Sua cobertura sobre o MMX no kernel enquadra a meta de lançamento como uma expectativa. Em 9 de novembro, essa é a linguagem apropriada para leitores que planejam em torno da mudança.

Uma árvore de desenvolvimento fornece evidências de que o trabalho está avançando rumo à integração. Ela não torna incondicional uma meta de lançamento proposta. Revisão, decisões de integração e revisões posteriores ainda podem afetar o que chega a um kernel final.

Para leitores que encontram a remoção do MMX no Linux explicada por meio de manchetes nostálgicas, essa distinção de status merece atenção antes da história. O evento verificado é uma série de limpeza enviada, com uma integração em árvore de desenvolvimento relatada. O evento futuro é sua chegada esperada em um lançamento da linha principal.

O limite prático é igualmente importante. A série trata de implementações dentro do kernel, o núcleo do sistema operacional. Ela não descreve uma proibição geral de aplicativos que usam instruções MMX, nem anuncia que processadores Intel deixarão de reconhecê-las.

Esse limite muda o significado de “fim de uma era”. O kernel concluiria a aposentadoria de seu próprio trabalho de otimização específico para MMX. O ecossistema de software mais amplo, incluindo aplicativos históricos e sistemas operacionais preservados, tem um ciclo de vida separado.

Para os mantenedores, a proposta apresenta uma oportunidade concreta de simplificar um canto sobrevivente do código. Para os usuários, ela levanta uma questão mais restrita: se sua máquina específica seleciona hoje uma dessas implementações. Essa questão leva diretamente aos requisitos de hardware.

Os sistemas afetados ficam abaixo de diferentes limites de instruções

A linha divisória relevante é a capacidade do processador e a carga de trabalho, não simplesmente o fato de um computador ter a marca Pentium.

O patch de remoção de XOR de Biggers identifica o caminho afetado como atendendo antigos processadores de 32 bits sem suporte a SSE. SSE, Streaming SIMD Extensions, é uma extensão posterior de instruções para processar múltiplos elementos de dados. O patch também limita o uso relevante a sistemas que de fato executam um array RAID.

O patch de RAID6 traça um limite diferente: processadores sem SSE2, a extensão subsequente nessa família de instruções. Suas mudanças na implementação de RAID6 também removem um arquivo chamado sse1.c. Biggers explica que essa implementação ainda usava cálculos MMX, complementados por operações de memória SSE.

Esse nome de arquivo é um detalhe instrutivo. Uma leitura rápida poderia sugerir que a série remove uma substituição moderna e independente junto com o MMX. A descrição do patch identifica, em vez disso, outra implementação construída em torno da maquinaria mais antiga.

Para quem avalia o impacto no desempenho do Intel MMX, esses limites separados importam. O suporte de um processador a SSE não determina automaticamente sua exposição a todas as partes da série. A implementação selecionada e o cálculo RAID envolvido determinam a comparação relevante.

Considere um entusiasta hipotético executando uma configuração de kernel compatível em uma máquina de armazenamento Pentium II preservada. Se seu array usar uma implementação em retirada, a mudança prática diria respeito ao desempenho dos cálculos. A presença de uma alternativa significa que a remoção de código proposta não elimina automaticamente esse cálculo.

Agora considere um desenvolvedor lendo a mesma manchete em uma estação de trabalho contemporânea. A idade da extensão de instruções MMX, por si só, diz pouco sobre a implementação de armazenamento selecionada nessa estação. A evidência útil seriam suas capacidades reais de processador e o comportamento do kernel.

Esses exemplos ilustram a exposição, em vez de estabelecer resultados medidos. O material analisado não fornece um inventário de máquinas ativas que usam os caminhos em retirada. Portanto, ele não pode sustentar uma estimativa precisa de usuários afetados.

As pessoas que enfrentam uma decisão significativa são operadores que combinam capacidades antigas de processador com a carga de trabalho de armazenamento relevante. Elas precisariam estabelecer se uma atualização altera sua implementação selecionada e se qualquer lentidão resultante importa.

Mantenedores de distribuições enfrentam uma tarefa de comunicação relacionada. A configuração de seus kernels, a disponibilidade de pacotes e os requisitos de processador permanecem separados dessa limpeza de otimização. Os usuários precisam desses detalhes antes de interpretar um lançamento futuro como uma opção de atualização para hardware preservado.

A troca de manutenção, portanto, alcança um público técnico restrito com necessidades potencialmente específicas. Baixa exposição não significa exposição inexistente. Significa que a resposta deve seguir evidências reais de hardware e carga de trabalho, em vez do peso emocional de um nome de processador familiar.

O código genérico mantém a capacidade enquanto reduz casos especiais

A proposta separa a preservação de uma função da preservação de cada implementação histórica dessa função.

Uma alternativa escalar, código comum que processa valores sem a implementação MMX aposentada, oferece essa opção aos mantenedores. Biggers descreve as alternativas existentes como bem testadas. Essa é a base declarada pelo autor para preservar a funcionalidade enquanto remove caminhos especializados.

A expressão merece o devido escopo. Ela sustenta o argumento de continuidade da proposta, mas não é um benchmark publicado para todas as máquinas afetadas. Saída correta e velocidade equivalente são propriedades diferentes.

A lógica de manutenção é mais fácil de entender quando vista como uma escolha entre implementações. Código especializado pode justificar sua presença quando atende usuários ou oferece desempenho útil. Sua existência contínua também cria material que revisores precisam entender quando código relacionado muda.

O código genérico oferece um lugar compartilhado para manter o comportamento. Isso não torna desnecessária toda implementação especializada. Muda a evidência necessária para manter uma antiga: deve haver um benefício prático que valha a pena preservar.

É aqui que a remoção do MMX no Linux se torna mais interessante do que um aniversário histórico. O projeto está ponderando um caminho de desempenho remanescente contra a complexidade de levá-lo adiante. A existência de uma alternativa funcional torna a remoção possível sem tornar a decisão isenta de custos.

O terceiro patch estende essa simplificação às verificações de recursos do processador, que selecionam implementações adequadas a partir das capacidades de hardware disponíveis. Biggers propõe remover verificações redundantes de pré-requisitos e evitar verificações repetidas das mesmas características. O código enviado mantém implementações mais recentes, incluindo caminhos SSE2 e AVX2.

AVX2, uma extensão posterior de instruções vetoriais, representa outra forma de processar múltiplos valores em uma operação. Sua presença ilustra a comparação técnica mais claramente do que uma rivalidade entre marcas. A questão é qual implementação se adequa ao processador e continua valendo a pena manter.

O nome da Intel domina a história porque ela introduziu o MMX. A decisão de manutenção real diz respeito a recursos de processador suportados, e não à marca do fornecedor. Comparar produtos históricos da Intel e da AMD não resolveria se uma implementação específica do kernel ainda merece seu lugar.

O mesmo raciocínio explica por que uma redução na contagem de linhas precisa de interpretação cuidadosa. Menos linhas descrevem o tamanho de uma mudança no código-fonte. Elas não medem diretamente armazenamento mais rápido, menos defeitos ou uma redução específica nas horas de manutenção.

O argumento mais forte para a limpeza é, portanto, estrutural. Uma alternativa compartilhada preserva o cálculo, enquanto a série remove implementações destinadas a uma faixa mais antiga de capacidades. Alegações de desempenho exigem evidências adicionais.

Vista dessa forma, a remoção do MMX no Linux explicada é uma história sobre reduzir a carga de implementação em torno de uma capacidade existente. O kernel pode continuar executando uma tarefa enquanto aposenta um método histórico de executá-la. Se esse equilíbrio é correto depende, em parte, dos usuários restantes.

A longa aposentadoria do MMX reflete uma mudança no acordo de manutenção

O marco histórico é real, mas a data de lançamento do MMX não mede a idade nem o valor de cada implementação removida.

A Intel lançou o processador Pentium com tecnologia MMX em 8 de janeiro de 1997. Seu lançamento contemporâneo do Pentium MMX enfatizava gráficos, vídeo e áudio. Uma tecnologia comercializada em torno de mídia mais rica para computadores pessoais acabou sobrevivendo em cálculos de armazenamento do kernel.

Essa história explica por que a proposta atrai atenção além do desenvolvimento de armazenamento. O MMX foi um recurso visível para consumidores, associado a um período reconhecível da computação pessoal. Suas otimizações finais no kernel carregam um peso simbólico que trabalhos comuns de limpeza raramente recebem.

O simbolismo não deve obscurecer a cronologia real. Uma extensão de instruções pode anteceder o código que a utiliza. Chamar isso de aposentadoria de uma tecnologia de 1997 é preciso; presumir que cada linha de código-fonte removida data de 1997 exigiria evidências separadas.

A proposta também segue remoções anteriores. Biggers aponta para um commit anterior que eliminou otimizações MMX para funções de memória, incluindo memcpy(), copy_page() e clear_page(). Essas funções copiam dados ou inicializam memória, atividades distintas do trabalho restante de RAID.

A retirada anterior muda o enquadramento do evento atual. Trata-se da conclusão de uma sequência de limpeza mais restrita, e não de uma decisão repentina de expulsar uma tecnologia amplamente usada. O RAID permaneceu como um uso isolado no kernel depois que outros trabalhos de otimização desapareceram.

Uma otimização histórica pode perder gradualmente sua justificativa original. O hardware muda, implementações alternativas surgem, e fica mais difícil determinar a população que utiliza o caminho mais antigo. O código pode continuar funcional durante toda essa transição.

Isso gera uma questão recorrente de manutenção: quanta atenção contínua um projeto deve dedicar a um caminho cujo público prático é incerto? A exclusão é uma resposta quando a capacidade permanece disponível em outro lugar. Manter o código é outra quando usuários demonstram um benefício relevante.

Nenhuma das posições exige desconsiderar hardware antigo. O trabalho de preservação tem objetivos diferentes da manutenção de um kernel atual de propósito geral. Um entusiasta pode valorizar a reprodução de comportamento histórico mesmo quando esse comportamento já não justifica uma implementação dedicada no upstream.

O inverso também é verdadeiro. Nostalgia não comprova que código especializado tenha usuários ativos, testes atuais ou uma vantagem útil de desempenho. Essas são questões técnicas que merecem evidências técnicas.

A lição mais ampla diz respeito aos termos da compatibilidade. Manter um algoritmo disponível, preservar uma otimização específica para um processador e oferecer suporte a uma máquina completa são compromissos distintos. Um projeto pode alterar um deles enquanto os demais continuam sujeitos a seus próprios requisitos.

Para desenvolvedores, este é um exemplo útil de como o software envelhece sem simplesmente deixar de funcionar. Uma otimização pode passar de essencial a opcional e depois tornar-se difícil de justificar. Sua retirada passa então a refletir um acordo de manutenção modificado, e não um juízo sobre a importância histórica do hardware.

A evidência ausente é o desempenho medido no hardware afetado

Um fallback preservado estabelece um caminho para a operação contínua, não uma garantia de desempenho inalterado.

As descrições disponíveis do patch explicam por que Biggers considera o código especializado obsoleto. Elas não fornecem uma comparação medida de máquinas afetadas executando cargas de trabalho de armazenamento representativas antes e depois da mudança. Isso deixa o custo prático em aberto.

Essa lacuna deve limitar afirmações em ambas as direções. Seria prematuro declarar que todo sistema afetado ficará visivelmente mais lento. Também seria prematuro prometer que ninguém perceberá.

O impacto de desempenho do Intel MMX depende de onde o tempo é gasto durante uma operação real. Um cálculo mais lento importa de forma diferente quando o processamento é o fator limitante do que quando outro componente predomina. A proposta, por si só, não estabelece esse equilíbrio para uma máquina específica.

Um teste isolado de cálculo responderia a uma questão útil: como a implementação antiga se compara à sua substituta em condições controladas. Uma carga de trabalho de armazenamento responderia a outra: se essa diferença altera o trabalho que um operador realmente executa.

Esses resultados não devem ser tratados como intercambiáveis. Uma diferença visível no throughput de cálculo não se traduz automaticamente em uma diferença equivalente no desempenho da aplicação. Da mesma forma, uma carga de trabalho rotineira aceitável pode não revelar uma operação menos frequente que seja importante para seu proprietário.

Para um sistema de armazenamento preservado, a atividade de manutenção pode ser tão relevante quanto o acesso cotidiano. Um operador pode se preocupar com trabalho de recuperação, gravações sustentadas ou disponibilidade do processador durante outras tarefas. Essas são áreas propostas de avaliação, não regressões medidas estabelecidas pela série.

A objeção mais forte viria, portanto, de resultados reproduzíveis em uma configuração afetada. Essas evidências poderiam mostrar que o caminho especializado mantém valor prático. Dariam aos revisores algo mais concreto do que uma suposição sobre quantas máquinas antigas ainda restam.

O apoio mais forte combinaria correção contínua com comportamento aceitável em hardware relevante. Isso reforçaria o argumento de que a implementação compartilhada atende às necessidades restantes. Novamente, a existência da proposta não substitui essas observações.

As alegações de compatibilidade precisam de contenção semelhante. A remoção desses arquivos de otimização não estabelece uma mudança no formato de um array armazenado. Tampouco certifica que todo sistema antigo poderá inicializar um kernel futuro.

Os usuários precisam avaliar todo o ambiente de atualização, incluindo requisitos da distribuição e sua configuração de hardware. Uma alteração restrita no código-fonte não pode responder a todas as perguntas sobre o suporte futuro de uma máquina. Apresentá-la dessa forma confundiria decisões distintas.

Também não há base aqui para anunciar uma ampla melhoria de segurança. Reduzir código especializado pode simplificar a revisão, mas a justificativa apresentada não identifica uma vulnerabilidade corrigida por essa exclusão. Os benefícios de manutenção devem permanecer alegações de manutenção, salvo se evidências adicionais sustentarem mais do que isso.

A leitura responsável é, consequentemente, ponderada. A série oferece uma forma plausível de reduzir a complexidade legada ao mesmo tempo que preserva os cálculos. O debate restante envolve o valor da aceleração removida e as evidências necessárias para avaliar esse valor.

Acompanhe a integração, os testes de fallback e a entrega pelas distribuições

Os próximos desdobramentos úteis são marcos observáveis: integração na mainline, testes em sistemas afetados e entrega por meio de pacotes reais do kernel.

Primeiro, acompanhe se a série chega ao kernel mainline e qual lançamento a contém. Linux 7.5 continua sendo o destino esperado relatado. Uma integração confirmada reforçaria a narrativa específica da versão e forneceria uma mudança definitiva para revisores downstream.

Uma revisão, atraso ou retirada alteraria essa avaliação. A proposta mais ampla continuaria documentada, mas o cronograma previsto de lançamento precisaria ser atualizado. Os leitores devem evitar transformar um relatório de árvore de desenvolvimento em uma nota de lançamento incondicional.

A versão exata integrada também importará. A revisão pode alterar o escopo ou detalhes de implementação mesmo quando a direção geral permanece. Acompanhar a mudança aceita fornece uma base mais firme para análise de compatibilidade do que depender indefinidamente da submissão inicial.

Segundo, procure resultados de correção e desempenho em hardware que realmente utiliza os caminhos em retirada. Testes em um processador mais novo e não relacionado não podem determinar a experiência de um sistema legado afetado. A comparação relevante exige uma configuração correspondente e uma carga de trabalho clara.

Um relatório confiável deve distinguir operação bem-sucedida de velocidade satisfatória. Também deve explicar o que foi medido e se a implementação antiga foi selecionada antes da mudança. Sem esse contexto, um resultado pode ser preciso e ainda assim irrelevante para a troca proposta.

Resultados aceitáveis reforçariam o argumento de que o código genérico pode atender à necessidade restante. Uma regressão reproduzível com consequências operacionais o enfraqueceria. Qualquer um dos resultados melhoraria a discussão ao substituir suposições por evidências.

Terceiro, acompanhe a entrega pelas distribuições. Um lançamento upstream não determina quando a distribuição escolhida por um usuário empacotará esse kernel ou oferecerá suporte à sua máquina. A configuração de pacotes e os requisitos do processador continuam fazendo parte da decisão prática de atualização.

Para quem mantém um sistema antigo, o marco relevante é um kernel disponível que se encaixe no ambiente completo. Até lá, a proposta é uma informação de planejamento relevante, e não uma instrução imediata para substituir hardware.

Essas observações também mantêm a narrativa histórica na proporção adequada. A retirada merece atenção porque encerra um capítulo reconhecível na otimização de kernels. Sua importância técnica dependerá do que for integrado, de como os caminhos restantes se comportam e de quem encontra a mudança.

Para equipes de engenharia, manter essas distinções documentadas pode evitar que uma manchete se transforme em uma suposição de compatibilidade sem sustentação. Uma base de conhecimento pesquisável pode conectar o patch aceito, a configuração local e os resultados de teste ao avaliar atualizações.

Se você mantém hardware afetado, comece pela configuração que realmente utiliza e pelo trabalho de armazenamento que precisa executar. Registre a implementação selecionada antes de testar um kernel que contenha a mudança. Compare resultados que reflitam sua carga de trabalho e separe correção de velocidade. Se você mantém sistemas mais novos, acompanhe o patch aceito em vez de tratar toda referência a MMX como um alerta de compatibilidade. A remoção do MMX no Linux será mais informativa como uma decisão de manutenção documentada, com seus benefícios e custos vinculados a comportamentos observáveis. Acompanhe a integração, examine relatórios de teste relevantes e verifique os requisitos da sua distribuição antes de decidir o que essa retirada significa para suas máquinas.