A ferramenta perf, o canivete suíço de análise de desempenho no Linux, está passando por uma modernização significativa. Uma nova série (v6) com 22 patches propõe gerar métricas de performance para CPUs Intel via scripts em Python, aposentando o antigo esquema de arquivos JSON estáticos. Na prática, o perf ganha um “cérebro” programável para descrever métricas complexas — e isso muda o jogo para quem investiga gargalos de microarquitetura no kernel.
De JSON estático a Python dinâmico: a nova arquitetura
Até aqui, o perf distribuía métricas em coleções de JSON curadas manualmente. O novo desenho move essa lógica para código (por exemplo, tools/perf/pmu-events/intel_metrics.py e metric.py), que gera o JSON final. O ganho imediato? Manutenção muito mais simples, menos chance de erros de digitação/expressão e escala melhor para novas famílias de CPU — inclusive as híbridas (núcleos P e E) que exigem cuidado extra na seleção de PMUs e eventos.
Em vez de “forçar” métricas genéricas, o sistema passa a condicionar cada métrica aos eventos realmente disponíveis naquele modelo. A série introduz o utilitário CheckPmu() para verificar PMUs presentes nos eventos carregados e marca automaticamente como experimentais as métricas baseadas em eventos experimentais (o que ajuda a calibrar expectativas e evitar diagnósticos precipitados). Todas as novas métricas geradas em Python vêm namespaced com o prefixo lpm_ (Linux Perf Metric), facilitando descoberta e organização dentro do perf.
Para quem usa no dia a dia, isso significa que a Linux perf tool fica mais “esperta” e confiável: se a sua máquina não tem um determinado evento, aquela métrica simplesmente não aparece — e nada quebra. Para quem desenvolve o perf, adicionar medições para uma CPU futura vira tarefa mais objetiva: escreve-se o script de geração uma vez, e ele produz o JSON correto para cada modelo suportado.
Uma avalanche de novas métricas para CPUs Intel
A proposta não é só infraestrutura; ela já chega com vinte conjuntos de métricas adicionais prontos para Intel. Entre os destaques, há leituras de RAPL (estimativa de potência por pacote/núcleos/DRAM), Idle/C-States, TSX (ciclos transacionais/abortos), estatísticas detalhadas de branches, uso de ports (unidades funcionais), L2 (hits/misses, prefetch, RFO, código, evictions) e um conjunto rico para load/store com cmask para decompor latências de aposentadoria de instruções. Isso tudo soma uma visão de alto nível até a lupa de microarquitetura — sem a ginástica que usuários faziam para combinar contadores manualmente.
No topo da pilha, métricas de banda de memória com PMUs uncore (DDR e PMM), memória local vs. remota, latência média de misses (derivada de occupancy e inserts na CHA/CBOX), UPI (leitura/escrita) e até saturação da malha (“mesh”) de interconexão em servidores. Para quem administra servidores Intel modernos, é o tipo de painel que ajuda a separar “CPU lenta” de “memória saturada” com números mais claros.
Exemplos concretos (gostinho do que vem por aí)
- RAPL: métricas
lpm_cpu_power_*que convertem energia em Watts por intervalo de medição — ótimo para correlacionar throttling com carga real. - TSX: percentual de ciclos transacionais, ciclos abortados e “ciclos por transação”/“por elision”, gerados somente quando o modelo e o ambiente (ex.: hypervisor desligando TSX) realmente suportam os eventos.
- Branches: grupos que medem taxa de branches, mispredictions, “instruções entre branches” e distinções por tipo (condicionais, taken/ not taken, far).
- Ports: ocupação por port via
UOPS_DISPATCHED.PORT*, com ajuste para SMT ao normalizar por cycles efetivos — um termômetro direto de pressão em unidades funcionais.
Por que isso importa (de verdade)?
Se você já sofreu ao montar fórmulas de métricas na unha — decifrando umasks, combinando eventos e fazendo post-processing —, este movimento é libertador. Métricas condicionais e parametrizadas cabem naturalmente em Python, inclusive com verificações de presença de eventos e de PMUs híbridas na hora de gerar o JSON. O time que mantém o perf reduz esforço com arquivos duplicados por modelo e, ao mesmo tempo, aumenta a ambição do que é possível medir (ex.: mesh bandwidth saturation ou latência local/remota sem gambiarra).
Também há um ganho de robustez editorial: ao prefixar todas as métricas geradas com lpm_, fica claro o que vem do novo pipeline — útil para depurar, comparar com métricas legadas e até descontinuar duplicatas nos JSON por modelo (a série propõe mover coisas como TSX/SMI do per-model para os scripts).
E quando isso chega?
A série foi publicada inicialmente em 4 de setembro de 2025 como v6 e referencia trabalhos imediatamente anteriores — um indicativo de que a proposta mira a próxima janela de merge após o ciclo baseado no 6.17 (ou seja, provavelmente 6.18). Como sempre, é código em revisão: detalhes podem ajustar, mas a direção (Python gerando métricas) está bem estabelecida. Neste momento, muitos ajustes ainda estão em jogo, mas está muito próximo de conclusão, então estimamos que a novidade esteja no desenvolvimento da próxima versão do kernel.
