On 11/1/22 07:38, Dominique Martinet wrote:
Daan De Meyer via devel wrote on Tue, Nov 01, 2022 at 11:26:13AM
-0000:
> I've added a new section to the proposal with the benchmark results of
> some benchmarks we performed against a Fedora 37 system built with
> frame pointers and a regular Fedora 37 system. The impact on most
> benchmarks seems limited aside from the CPython benchmark suite
> (pyperformance). See the proposal itself for the detail.
For others who rotate their mailbox out regularly and no longer have the
start of this thread, here's a link to the change:
https://fedoraproject.org/wiki/Changes/fno-omit-frame-pointer
and quoting the relevant section summary:
* Compiling the kernel with GCC is 2.4% slower with frame pointers
* Running Blender to render a frame is 2% slower on our specific
testcase
* openssl/botan/zstd do not seem to be affected significantly when built
with frame pointers
* The impact on CPython benchmarks can be anywhere from 1-10% depending
on the specific benchmark
* Redis benchmarks do not seem to be significantly impacted when built
with frame pointers
with details in
https://github.com/DaanDeMeyer/fpbench
I am pretty sure that the conclusion from last time was that slowing
down userspace to work around perf limitations was not acceptable,
and that the kernel limitations should be fixed instead. Has adding
kernel support for DWARF unwinding been considered instead? systemtap
has a kernel-mode unwinder that could be used. Another very useful
improvement would be to move unwinding from NMI context to immediately
before returning to userspace. That would allow unwinding to block
on e.g. faulting in memory from disk.
I did manage to come up with an alternative solution that avoids
requiring DWARF to be processed in kernel mode. The kernel could
handle the event by sending a fake signal to the process. This signal
could not be caught, blocked, or ignored, and would instead be handled
by the kernel returning to a location in the vDSO. The vDSO would
then do the unwinding in userspace and use rt_sigreturn to resume
normal execution. Recording data from a process in an uninterruptible
sleep would be tricky, though.
--
Sincerely,
Demi Marie Obenour (she/her/hers)