Ubuntu 24.04 LTS habilitará frame pointers de forma predeterminada
Ubuntu 24.04 LTS compilará binarios con los frame pointers habilitados de forma predeterminada, revirtiendo una antigua optimización que los omitía para ganar un registro extra en x86 de 32 bits. Los comentaristas sostienen que en las CPU modernas de 64 bits el impacto en rendimiento suele ser inferior al 1–2%, mientras que las ganancias en observabilidad son sustanciales: trazas de pila mucho más fiables, uso más fácil de herramientas como perf, eBPF/bpftrace y perfiles continuos, además de mejor depuración post mortem incluso sin símbolos de depuración completos. A algunos les preocupan regresiones en cargas de trabajo muy sensibles como el intérprete de Python, pero el consenso emergente es que las distribuciones deberían favorecer la depuración por defecto y optar por excluir solo aquellas cargas de trabajo en las que aparezca una ralentización clara y medible.
Antecedentes y motivación
- Muchos comentaristas ven la omisión de los frame pointers como una microoptimización heredada de x86 de 32 bits, donde recuperar el frame pointer proporcionaba un registro adicional crucial y grandes mejoras de rendimiento.
- En x86-64 hay muchos más registros y más anchos, así que el beneficio de omitir el frame pointer se considera mucho menor.
- Varios señalan que otras distros (por ejemplo, Fedora) ya habilitan frame pointers y ven el movimiento de Ubuntu como parte de una tendencia más amplia.
Debate sobre el impacto en el rendimiento
- La sobrecarga reportada en arquitecturas de 64 bits suele ser “difícil de medir”, a menudo por debajo del 1%, con algunas afirmaciones de 1–2% en cargas de trabajo concretas.
- Los críticos argumentan que incluso regresiones globales del 0,1–1% son un desperdicio a escala y que simplemente se deberían arreglar las herramientas para perfilar sin frame pointers.
- Los defensores responden que el acceso fácil a perfiles a menudo produce optimizaciones del 30–3000%, lo que hace que el intercambio sea claramente favorable.
- Algunos mencionan microcasos en los que el registro extra sigue siendo importante (intérpretes de bytecode como Python, bucles internos muy ajustados) y esperan o apoyan exclusiones por paquete.
Beneficios para depuración y perfilado
- Hay un consenso fuerte en que los frame pointers hacen que el desenrollado de pila sea trivial, barato y más fiable, especialmente para:
- Perf, eBPF/bpftrace/bcc, perfilado continuo y flame graphs.
- Depuración post mortem, core dumps y análisis de incidentes en producción en sistemas LTS.
- Sin frame pointers, las herramientas deben usar programas de desenrollado DWARF/.eh_frame, que son más lentos, más complejos y frágiles cuando las pilas están dañadas.
Herramientas, formatos y soporte del kernel
- Varios describen soluciones existentes para desenrollar sin frame pointers usando DWARF+eBPF, pero señalan que son complejas y no están ampliamente disponibles ni son adecuadas para todas las herramientas.
- Se discute el desenrollador ORC del kernel para el propio kernel y el formato SFrame emergente para el futuro desenrollado de pila en espacio de usuario con menor sobrecarga.
- Algunos sostienen que confiar en formatos avanzados de desenrollado es poco realista hoy; los frame pointers funcionan de inmediato con las herramientas existentes.
Casos especiales, seguridad e impacto en el ecosistema
- Se cita Python como un caso en el que se han visto regresiones de ~10% con frame pointers; Ubuntu planea excluir esos casos si se confirma.
- Los sistemas embebidos suelen eliminar la información de depuración/desenrollado, lo que hace que los frame pointers sean especialmente valiosos allí.
- Un comentario señala que omitir frame pointers reduce ligeramente ciertas superficies de explotación por desbordamiento de pila, pero esta línea de razonamiento no se desarrolla.
- Hay debate sobre si estos valores predeterminados deberían establecerlos las distribuciones o dejarse a los upstreams; otros responden que los operadores y usuarios también necesitan observabilidad a nivel de sistema.