It's not even a question worth asking because it's both impractical and
unlikely to actually fix the situation we have.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora
> My comment was specifically about sysprof. I've been told that the
> GNOME developers will not even consider anything else. This means that
> we need to fix sysprof. If we do that, it will be possible to use GNOME
> OS for profiling on older CPUs, and hardware-assisted backtraces on
> newer
> Why does the unwinding need to happen in the kernel? The kernel can
> already asynchronously invoke userspace code in the form of signal
> handlers. Is the problem that it is necessary to collect profiling
> information in the middle of a system call, where another syscall
> would see
> That is the problem right here: .eh_frame-based unwinding is too slow, so it
> has to be
> done offline in userspace. What about instead adding ORC information to
> userspace? That
> would be much faster to use.
I'm not familiar with ORC, but there are a few things that initially come to
> Frank Ch. Eigler mentions that elfutils has a more modern unwinding library.
> Could that perhaps solve your performance issues with libunwind?
I don't think so. The problem is two-fold.
First, we have to capture enough of the stack to do offline unwinding. I think
the default many people do
> So it looks like what you folks are doing is actually very similar to what
> Facebook is doing. That is interesting, and explains why some GNOME
> developers are jumping on the bandwagon of this Change proposal.
To be fair, we've been complaining about it internally in GNOME for probably
Sysprof has modular data collection backends, and not everything requires
linking against libunwind.
For those not familiar with Sysprof, or profiling the desktop at large,
generally a single program is not the problem. The performance problems often
exist across a number of processes. That
