Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Bug#767756: glibc: Consider providing a libc build compiled with -fno-omit-frame-pointer to help with profiling
107 views
Skip to first unread message
Andres Freund
Nov 2, 2014, 8:30:03 AM11/2/14
to
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-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
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-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
notafile
Feb 15, 2020, 9:40:03 PM2/15/20
to
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'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.
Aurelien Jarno
Feb 16, 2020, 8:10:03 AM2/16/20
to
Hi,
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
aure...@aurel32.net http://www.aurel32.net
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
aure...@aurel32.net http://www.aurel32.net
Florian Weimer
Feb 16, 2020, 8:30:02 AM2/16/20
to
* 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).
>> 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.
only impact disk size (and the size of VM mappings).
notafile
Feb 16, 2020, 12:20:03 PM2/16/20
to
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.
> Most unwinders should be able to use asynchronous unwind tables, which
> only impact disk size (and the size of VM mappings).
Maksim Dmitrichenko
Feb 9, 2023, 12:10:04 PM2/9/23
to
Sorry guys, may be I'm telling well known things but Ubuntu has libc6-prof package which installs alternative version of libc6 with no-omit-frame-pointer to /lib/libc6-prof/x86_64-linux-gnu/ . Any who need to profile his program can use it via LD_LIBRARY_PATH environment variable while other programs by default use optimized version.
Why reinvent the wheel?
--
Why reinvent the wheel?
With best regards
Maksim Dmitrichenko
Maksim Dmitrichenko
0 new messages