O retorno dos frame pointers

Site do Brendan: introdução

• A página inicial do blog de Brendan Gregg aborda diversos temas sobre desempenho de sistemas, ferramentas BPF, desempenho no Linux e mais.
• As publicações recentes incluem temas como o retorno dos frame pointers, um documentário sobre eBPF e o fato de que ferramentas de observabilidade com eBPF não são ferramentas de segurança.
• Além de conteúdo técnico, o blog também compartilha várias conferências e apresentações das quais Brendan participou.

O retorno dos frame pointers

• Em sistemas sem frame pointers, o rastreamento de pilha para na camada libc, fazendo com que frames da aplicação fiquem ausentes.
• Fedora e Ubuntu resolveram esse problema ao lançar versões compiladas da libc que incluem frame pointers por padrão.
• Frame pointers são usados por profilers e depuradores externos, e visualizados por flame graphs.

O que é um frame pointer?

• Segundo o documento ABI do x86-64, o registrador de CPU %rbp pode ser usado como o "ponteiro base" do stack frame.
• Essa técnica é amplamente usada para stack tracing, inclusive por Linux perf e eBPF.

2004: remoção dos frame pointers

• Em 2004, o desenvolvedor do gcc Roger Sayle promoveu uma mudança para interromper a geração de frame pointers.
• Essa mudança trouxe ganho de desempenho, mas com a chegada do eBPF, hoje alguns depuradores/profilers enfrentam problemas por causa disso.

2005-2023: o inverno dos profilers quebrados

• A mudança de remoção dos frame pointers também foi aplicada ao x86-64, mas essa arquitetura tinha mais registradores e, por isso, o ganho não foi grande.
• Como resultado, muitos depuradores/profilers deixaram de funcionar corretamente.

2014: Java in Flames

• Ao entrar na Netflix, foi constatado que a falta de suporte a frame pointers no Java quebrava todas as stacks de aplicação.
• Para resolver esse problema, foi desenvolvida uma modificação no compilador JVM c2.

2015-2020: overhead

• O overhead de adicionar frame pointers a tudo geralmente fica abaixo de 1%.
• Em certos microbenchmarks, o overhead pode chegar a 10%.

2022: tentativa upstream

• Sugere-se que grandes empresas como Google, Meta e Netflix já haviam habilitado frame pointers em tudo.
• Há várias dificuldades para tornar essa mudança o padrão de forma que beneficie a todos.

2023, 2024: frame pointers no Fedora e no Ubuntu

• O Fedora aceitou a proposta de reativar frame pointers.
• O Ubuntu também passou a ativar frame pointers por padrão na versão 24.04 LTS.

2034 em diante: além dos frame pointers

• Há várias maneiras de rastrear stacks, incluindo LBR, BTS, AET, DWARF, stack walking com eBPF, ORC, SFrames e shadow stacks.
• No futuro, SFrames ou shadow stacks podem ser usados para todo stack tracing.

Conclusão

• O retorno dos frame pointers torna os flame graphs de CPU mais significativos, faz os flame graphs Off-CPU funcionarem pela primeira vez e abre outras novas possibilidades.
• Também é uma vitória para os profilers contínuos, que deixam de precisar convencer clientes a mudar o sistema operacional para que o profiler funcione plenamente.

Opinião do GN⁺

• O retorno dos frame pointers deve ajudar muito na análise de desempenho de sistemas e na depuração. É uma ferramenta essencial, especialmente para diagnosticar problemas e otimizar desempenho em sistemas de software complexos.
• Essa mudança mostra a importância da colaboração e das contribuições da comunidade open source. As decisões do Fedora e do Ubuntu podem influenciar outras distribuições e trazer mudanças positivas para todo o ecossistema Linux.
• Reintroduzir frame pointers é uma questão de equilibrar perda de desempenho e facilidade de depuração. Essa decisão pode ser melhor compreendida por meio de testes e análises de desempenho em ambientes reais de produção.
• Para usuários com conhecimento técnico, essa mudança pode ser interessante e oferece informações úteis para desenvolvedores e administradores de sistemas interessados em melhorar o desempenho.
• Se houver outras tecnologias ou ferramentas que ofereçam funcionalidade semelhante à dos frame pointers, pode-se usar profilers baseados em hardware, como Intel VTune Profiler ou AMD uProf. Essas ferramentas permitem análise de desempenho mesmo sem frame pointers.

[GN⁺]

Comentários do Hacker News

• Experiência de quando a omissão do ponteiro de frame da pilha começou a se espalhar no início dos anos 2000
  • Na época, o autor estudava ciência da computação, e o computador que usava era antigo e tinha baixo desempenho.
  • Quando depurar ficou mais difícil, passou a usar Python para evitar esses problemas de depuração.
• Esforços na distribuição Fedora para manter o ponteiro de frame da pilha
  • Havia a crença equivocada de que o ponteiro de frame da pilha trazia uma grande sobrecarga, mas na prática a sobrecarga é inferior a 1%.
• O fato de a Apple sempre manter rastros de pilha significativos na arquitetura ARM
  • Algumas funções podem não gerar registros de frame, mas os rastros de pilha continuam úteis mesmo sem informações de depuração.
• Experiência no Google e 20 anos de debate com a comunidade
  • Compartilha a experiência de criar e manter patches para aplicar libunwind ao gperftools.
• Casos do passado em que houve ganho de desempenho com a opção -fomit-frame-pointer
  • Compilar MySQL e PHP em processadores de 32 bits ajudou a reduzir custos de hardware.
• Como a linguagem de programação Virgil gerencia frames de pilha
  • Quando não há alocação dinâmica na pilha, é possível encontrar o tamanho do frame com uma simples consulta em tabela.
  • Explicação sobre o código que implementa a decodificação de metadados.
• A ideia de gerenciar duas pilhas usando RBP e RSP em vez de “percorrer” a pilha
  • A pilha de chamadas passa a ser simplesmente um array de endereços de retorno, reduzindo a necessidade de percorrer a pilha.
• Apoio ao uso de ponteiros de frame e compartilhamento de experiências e opiniões relacionadas
  • A decisão de ativar ou não ponteiros de frame deve ser tomada caso a caso, e benchmarking é importante.
  • A importância de sistemas de build oferecerem uma forma de mudar isso globalmente.
  • Expectativa em torno do SFrame e seu potencial para resolver os problemas atuais.
• Opinião de que profiling foi um problema por 20 anos e só agora foi resolvido
  • A ausência de ponteiros de frame causou sofrimento a muitas pessoas, e agora, ao ver o Linux revertendo isso, parece que seus esforços finalmente estão sendo reconhecidos.
• É irônico reclamar do desempenho do mecanismo que torna possível o profiling do sistema
  • Reclamar de desempenho de um sistema que permite identificar problemas de desempenho é o auge da otimização prematura.