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) _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
