Bug#767756: glibc: Consider providing a libc build compiled with -fno-omit-frame-pointer to help with profiling
Hi all, Fedora and Ubuntu [1] have now enabled frame pointers on amd64 by default, providing a great profiling experience out-of-the-box. I think it may be time for Debian to reconsider its position here; the performance overhead is very small and meanwhile this lack of frame pointers is preventing other, much more significant performance improvements by making it hard or impossible to properly profile applications. [1]: https://ubuntu.com/blog/ubuntu-performance-engineering-with-frame-pointers-by-default Kind regards, Ralf
Bug#767756: glibc: Consider providing a libc build compiled with -fno-omit-frame-pointer to help with profiling
On Sun, Feb 16, 2020, at 14:15, Florian Weimer wrote: > Most unwinders should be able to use asynchronous unwind tables, which > only impact disk size (and the size of VM mappings). Experience with perf shows orders of magnitude of overhead of DWARF unwinding over fp based unwinding. The kernel uses ORC for this reason, which is up to 20-40x faster than DWARF, in addition to the removal of the 5-10% DWARF performance penalty caused by .text size increase. It is however not available for user-space programs. Since it uses ORC, DWARF unwinding is also unavailable in (and unlikely to be ever supported by) the kernel, including the bpf_get_stack* helpers used in eBPF. Since most interaction with the kernel is done through libc, this unfortunately makes it impossible to meaningfully inspect user-space programs in response to events, which is one of the biggest selling points of bpf tracing.
Bug#767756: glibc: Consider providing a libc build compiled with -fno-omit-frame-pointer to help with profiling
* Aurelien Jarno: >> I've been running into this myself a lot lately and wonder if >> anything has happened regarding this since 2014, after all it's >> been six years. >> I'm surprised so few people seem to be taking interest in this >> considering the amount of tools that rely on frame pointers for >> performant stack traces, which has further increased with the >> introduction of eBPF. > > I understand the need for -fno-omit-frame-pointer, however it has a > performance impact, so we do not want to do that by default. OTOH > providing an alternative libc is something tricky if we do not want it > to do it without breaking systems. Someone has to come with a patch that > is well tested. Most unwinders should be able to use asynchronous unwind tables, which only impact disk size (and the size of VM mappings).
Bug#767756: glibc: Consider providing a libc build compiled with -fno-omit-frame-pointer to help with profiling
Hi, On 2020-02-16 03:32, notafile wrote: > Hi, > > I've been running into this myself a lot lately and wonder if anything has > happened regarding this since 2014, after all it's been six years. > I'm surprised so few people seem to be taking interest in this considering > the amount of tools that rely on frame pointers for performant stack traces, > which has further increased with the introduction of eBPF. I understand the need for -fno-omit-frame-pointer, however it has a performance impact, so we do not want to do that by default. OTOH providing an alternative libc is something tricky if we do not want it to do it without breaking systems. Someone has to come with a patch that is well tested. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Bug#767756: glibc: Consider providing a libc build compiled with -fno-omit-frame-pointer to help with profiling
Hi, I've been running into this myself a lot lately and wonder if anything has happened regarding this since 2014, after all it's been six years. I'm surprised so few people seem to be taking interest in this considering the amount of tools that rely on frame pointers for performant stack traces, which has further increased with the introduction of eBPF.
Bug#767756: glibc: Consider providing a libc build compiled with -fno-omit-frame-pointer to help with profiling
Hi, On 2016-03-30 06:37:11 +, Alex Reece wrote: > I would love to bump this bug; I think it would be wonderful to have an > alternative version of libc with frame pointers. Yea, I'm hitting this more and more often. Especially with the new eBPF backed profiling tools like bcc, which, for the forseeable future, only support frame pointer based unwinding. Also fp based unwinding is a lot more efficient. > What would it take for such an alternative to exist (can the Debian > alternatives system work for libc)? I was thinking of adding a libc6-frame-pointers which would replace (and conflict with) libc6. But that's just because it was what I could think of. Maybe it'd be better to let those be co-installed by using a different triplet and allow to chose which to use via /etc/ld.so.conf/something? Not pretty either :( > If other people want this, I'm interested in investing some time into > helping with it. Same here. I'd primarily like some guidance about what approach is more likely to be accepted. Greetings, Andres Freund
Bug#767756: glibc: Consider providing a libc build compiled with -fno-omit-frame-pointer to help with profiling
I would love to bump this bug; I think it would be wonderful to have an alternative version of libc with frame pointers. What would it take for such an alternative to exist (can the Debian alternatives system work for libc)? If other people want this, I'm interested in investing some time into helping with it. Best, ~Alex
Bug#767756: glibc: Consider providing a libc build compiled with -fno-omit-frame-pointer to help with profiling
Source: glibc Severity: wishlist Hi, When profiling with perf (and even oprofile) showing the call graph can often be invaluable. Unfortunately for anything that goes through libc that's not efficiently possible as glibc (on at least amd64) doesn't build with frame pointers enabled. It is possible to use dwarf unwinding with halfway modern kernel/perf combinations to get call graphs even in that case, but the overhead is about a magnitude higher and the profiles are much larger. As applications have to be built with -fno-omit-frame-pointers anyway to provide usable call stack it's usually not a problem if some library isn't. But as so many things that often are bottlenecks (syscalls, memcpy, string operations, locking, ...) goes through libc it'd be quite valuable to have a variant of libc built with frame pointers enabled. Thanks for considering, Andres -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.17.0-andres-09670-g0429fbc (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141102130847.28817.43507.report...@alap3.anarazel.de
