FERRAMENTAS LINUX: Linux 7.5: a despedida definitiva do MMX no kernel e o que isso significa para o RAID

quarta-feira, 4 de novembro de 2026

Linux 7.5: a despedida definitiva do MMX no kernel e o que isso significa para o RAID

 



O Linux 7.5 remove a última otimização MMX do kernel em 2027. Entenda o impacto no RAID e por que o código escalar é o novo padrão. Saiba como isso afeta Pentium MMX e Pentium II.


O kernel Linux está prestes a virar uma página importante da sua história. A partir do que deve ser mesclado para o Linux 7.5, com lançamento previsto para 2027, a linha principal do kernel vai remover a última otimização específica para processadores MMX que ainda carregava. 

Na prática, isso significa que o conjunto de instruções MMX, criado pela Intel no final dos anos 1990 e presente em processadores como o Pentium MMX e o Pentium II, finalmente deixará de ter qualquer código otimizado dentro do kernel. 


O que era o MMX e por que ele importou?


Para quem não viveu os anos 90, vale um resumo: o MMX (MultiMedia Extensions) foi a primeira grande extensão SIMD (Single Instruction, Multiple Data) da Intel para os processadores x86. 

Lançado com o Pentium MMX em 1996, ele adicionou 57 novas instruções e oito registradores de 64 bits dedicados, permitindo que a CPU realizasse operações em paralelo sobre múltiplos dados — algo revolucionário para a época, especialmente para as aplicações multimídia, como reprodução de vídeo e áudio, e para cálculos de compactação.

Naquela época, o MMX foi um marco: permitia que softwares de edição de imagem, jogos e até mesmo o incipiente mercado de vídeo digital rodassem com desempenho muito superior em comparação com as instruções escalares tradicionais. 

O kernel Linux, sempre atento ao suporte de hardware, incorporou otimizações MMX em pontos críticos, incluindo operações de memcpy(), copy_page(), clear_page() e o cálculo XOR usado em RAID por software.

O tempo, porém, não perdoa. Com o avanço das extensões SSE (Streaming SIMD Extensions), lançadas com o Pentium III em 1999, e depois SSE2, AVX e além, o MMX foi ficando para trás. 

Seus registradores de 64 bits e seu conjunto limitado de instruções tornaram-se um fardo: o código MMX não se integra bem com as unidades de ponto flutuante modernas, exige salvar e restaurar o estado da FPU (unidade de ponto flutuante) em contextos de troca de tarefas e ocupa espaço no kernel sem oferecer ganhos reais para a imensa maioria dos usuários.


A longa limpeza do MMX no kernel


A remoção do MMX do kernel não aconteceu da noite para o dia. Foi um processo gradual, que começou anos atrás. Em 2021, o kernel já havia removido as otimizações MMX das funções de gerenciamento de memória mais chamadas, como memcpy(), copy_page() e clear_page(). 

O commit que oficializou essa limpeza foi o c6dbd3e5e69c (“x86/mmx_32: Remove X86_USE_3DNOW”), que também aposentou as extensões 3DNow! da AMD. Depois disso, sobrou apenas um reduto: o código MMX otimizado para RAID XOR (e para o cálculo de síndromes RAID6) na arquitetura x86 de 32 bits. 

Esse código era usado exclusivamente por processadores 32 bits que não possuem suporte a SSE — ou seja, basicamente Pentium MMX, Pentium II e alguns AMD K6 — e somente em sistemas que efetivamente utilizam RAID por software.

O patch de Eric Biggers é dividido em três partes. A primeira remove o código MMX do RAID5 (XOR); a segunda remove o código MMX do RAID6, incluindo um arquivo sse1.c que, segundo o próprio autor, era “na verdade uma implementação MMX com prefetches SSE1 e armazenamentos não temporais adicionados por cima”; a terceira parte limpa as verificações de recursos de CPU no código RAID6. No total, são 276 linhas deletadas dos arquivos mmx.c e sse1.c.


O que muda para quem ainda usa Pentium MMX ou Pentium II?


Se você é uma dessas raridades que ainda mantém um Pentium MMX ou um Pentium II rodando Linux com um array RAID por software, a mudança é direta: o kernel deixará de usar o caminho otimizado em MMX e passará a usar o código escalar em C, que já existe e é amplamente testado. 

O próprio patch explica: “As CPUs afetadas, como Pentium MMX e Pentium II, simplesmente cairão de volta para o código escalar existente e bem testado”.

Na prática, para o usuário final, o impacto no dia a dia é praticamente nulo. O código escalar já é o fallback para qualquer CPU que não tenha a extensão específica, e o RAID por software continua funcionando normalmente. 

A diferença estará no desempenho bruto do cálculo XOR e das síndromes RAID6: o MMX podia ser marginalmente mais rápido em alguns cenários, mas estamos falando de hardware com mais de 25 anos e que, convenhamos, não é mais o público-alvo de kernels modernos.



Produto Recomendado


Você já percebeu que a maioria das pessoas só conversa com o ChatGPT... enquanto uma minoria está criando agentes de IA que executam tarefas, tomam decisões e geram receita sozinhos?

O livro "Construindo Aplicações com Agentes de IA: Projeto e Implementação de Sistemas Multiagentes" é o seu mapa prático — do zero à arquitetura profissional.


✅ Projeto e implementação passo a passo

✅ Sistemas multiagentes que colaboram entre si

✅ Aplicações reais para negócios e automação

✅ Linguagem acessível, com rigor técnico


💡 Não é teoria. É engenharia aplicada.

Construindo Aplicações com Agentes de IA: Projeto e Implementação de Sistemas Multiagentes -> https://link.amazon/B04nEiWES

Eu ganho uma comissão quando você faz uma compra.


Por que o kernel está removendo o MMX?


A decisão não é arbitrária. Ela reflete a filosofia de manutenção sustentável do kernel Linux: manter código para hardware obsoleto tem custos. Cada otimização específica de arquitetura precisa ser testada, documentada e mantida em sincronia com as mudanças no restante do kernel. 

Quando um recurso deixa de ser usado pela esmagadora maioria dos sistemas, ele se torna um “peso morto” que pode introduzir bugs e dificultar a evolução do código.

O patch de Biggers deixa isso claro: o código MMX para RAID era o único resquício de otimização MMX no kernel. Não havia mais otimizações MMX para criptografia, CRC ou qualquer outra função. Isso o tornava um outlier — um ponto fora da curva — e, portanto, um alvo natural para remoção.

Além disso, há uma questão de segurança e confiabilidade. Código antigo, pouco testado e específico para hardware raro é um convite para vulnerabilidades sutis. Ao removê-lo, o kernel reduz sua superfície de ataque e simplifica a auditoria. 

O fallback escalar, por outro lado, é usado por todos os processadores que não têm SSE (e por muitos que têm, em determinados contextos) e passa por testes constantes na esteira de integração contínua do kernel.


O cronograma: quando o Linux 7.5 chega?


O patch já está na árvore “MM” de Andrew Morton, que serve como um dos principais funis para mudanças relacionadas a gerenciamento de memória e outras áreas antes de chegarem à árvore principal de Linus Torvalds. 

As previsões para o cronograma do kernel, mantidas pelo projeto “Linux Kernel Tea Leaves”, indicam que o Linux 7.4 deve ser lançado entre o final de dezembro de 2026 e o início de janeiro de 2027, e que a janela de mesclagem para o Linux 7.5 começaria logo em seguida, com o v7.5-rc1 previsto para janeiro de 2027. 

Isso significa que, se tudo correr conforme o planejado, o Linux 7.5 chegará às distribuições ao longo de 2027, e a remoção do MMX estará consolidada.


O fim de uma era (e o começo de outra)


A remoção do MMX do kernel não é um adeus melancólico, mas um sinal de maturidade. O Linux nasceu em 1991, no mesmo período em que o MMX despontava, e ao longo de três décadas suportou praticamente todo tipo de hardware x86 já fabricado. 

Essa compatibilidade impressionante foi uma de suas maiores forças, mas também um desafio crescente.

Hoje, o kernel precisa lidar com arquiteturas heterogêneas, virtualização, segurança em nível de hardware e desempenho em nuvem. Manter otimizações para um conjunto de instruções que ninguém usa em produção há pelo menos duas décadas não faz sentido. 

O MMX cumpriu seu papel histórico: ajudou a popularizar o conceito de SIMD em desktops e abriu caminho para o SSE, o AVX e todas as extensões vetoriais que dominam os processadores modernos.

Para os entusiastas de retrocomputação, o recado é claro: se você tem um Pentium MMX ou Pentium II funcionando, ele continuará rodando Linux — mas contará com o código escalar, que é robusto e testado. 

E, convenhamos, para um hardware dessa idade, a diferença de desempenho no RAID XOR dificilmente será o gargalo.


📋 Checklist para copiar e colar

✅ Como se preparar para a remoção do MMX no Linux 7.5


□ Verifique seu hardware: O processador é um Pentium MMX, Pentium II ou AMD K6 (ou outro x86 de 32 bits sem SSE)?

□ Confirme se você usa RAID por software: O array RAID está configurado com mdadm ou outra solução baseada no kernel?

□ Teste o fallback escalar: Se possível, force o kernel a usar o código escalar (via parâmetro de boot ou configuração) para avaliar o desempenho no seu cenário.

□ Monitore o cronograma do kernel: Acompanhe as notas de lançamento do Linux 7.4 e 7.5 para saber exatamente quando a mudança chegará à sua distribuição.

□ Considere um upgrade de hardware: Se o RAID for crítico para você, avalie migrar para uma plataforma com SSE2 ou superior, que já é o padrão há mais de 20 anos.

□ Faça backup dos dados: Antes de qualquer atualização de kernel, especialmente em hardware antigo, garanta que seus dados estejam seguros.


Conclusão


A remoção da última otimização MMX do kernel Linux é mais do que uma nota de rodapé técnica: é um marco simbólico. Representa a transição definitiva de um kernel que precisava suportar cada canto do universo x86 para um kernel que prioriza manutenibilidade, segurança e desempenho em hardware moderno.

Para a grande maioria dos usuários — que roda Linux em processadores com SSE2 ou superior há pelo menos duas décadas —, nada muda. 

Para os poucos que ainda mantêm um Pentium MMX ou Pentium II com RAID por software, o recado é de que o código escalar está pronto para assumir, sem drama e sem perda significativa de funcionalidade.

O MMX teve seu momento de glória nos anos 90, abrindo caminho para as extensões SIMD que hoje são onipresentes. Agora, ele se aposenta com honras, enquanto o kernel segue em frente — mais enxuto, mais focado e pronto para os próximos 30 anos.


Nenhum comentário:

Postar um comentário