If we can get SHSTK to work, the value of the DWARF integration and
performance work will diminish fairly quickly because most developers
will soon have CPUs with fairly deep (32 entry) LBR buffers, SHSTK
support, or both.
This seems like a fairly bold assumption. I also want to add that as discussed
in the proposal, we want to enable profiling not just on our laptops, but across
our entire fleet that's running various generations of hardware. We can't simply
replace all of our hardware just to get shadow stack support unfortunately. So
we can't rely on new hardware features to get stacktraces.
Of course, if shadow stack support lands upstream, is found to be reliable and is
fully supported by all hardware running on our fleet, we'd definitely look into using
it instead of frame pointers. But's it's going to take many years before we can
rely
by all our hardware.
Aside from our use case, I don't think developers are constantly replacing their
hardware either. I'd guess that with this approach we'd have many years of
developers debugging why they're not getting full stacktraces only to find out
their hardware doesn't support shadow stacks.
So to summarize, while we're anxiously awaiting for one of the mentioned
alternatives to become viable, at the moment we think all of them result in a
degraded profiling experience compared to frame pointers, either due to being
slow, being a prototype and not available upstream, or due to requiring new
hardware support.
Cheers,
Daan
________________________________________
From: Florian Weimer <fweimer(a)redhat.com>
Sent: 11 July 2022 07:12
To: Matthias Clasen
Cc: Development discussions related to Fedora
Subject: Re: F37 proposal: Add -fno-omit-frame-pointer to default compilation flags
(System-Wide Change proposal)
* Matthias Clasen:
On Wed, Jul 6, 2022 at 3:06 PM Florian Weimer
<fweimer(a)redhat.com> wrote:
> If the GNOME's sysprof does not work with Fedora, fix it or use
> something else. Do not change how Fedora is built.
The result of that attitude is that performance work in the desktop
space is happening on GNOME OS images, or in Flatpak runtimes instead
of on Fedora. Which is a bit sad for Fedora as a supposedly
developer-friendly environment.
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 CPUs on Fedora (at least Skylake and Zen 3, especially once we've
got userspace SHSTK support).
Even if this proposal is not accepted, I think we can collaborate on a
couple of things:
* Enhance sysprof with LBR and SHSTK support.
* Enable userspace backtrace generation from BPF without frame pointers
(possibly by using LBR and SHSTK at first).
* Investigate use of the Systemtap and elfutils unwinders in these
tools.
* Speed up decoding of DWARF data structures using the BMI instruction
sets (which only operate on scalar registers and should therefore be
usable even within the kernel). According to
<
https://lore.kernel.org/all/c54327dc-75c9-db48-f7c1-59f9fcfca26f@suse.cz/...
that's a major source of DWARF processing overhead, and I don't think
it has to be.
I'll try to get confirmation that it is technically feasible in priciple
to use SHSTK to get arbitrarily deep backtraces from kernel space for
userspace applications.
If we can get SHSTK to work, the value of the DWARF integration and
performance work will diminish fairly quickly because most developers
will soon have CPUs with fairly deep (32 entry) LBR buffers, SHSTK
support, or both.
Thanks,
Florian
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure