On 21. 11. 24, 16:10, Jiri Slaby wrote:
On 21. 11. 24, 13:30, Neal Gompa wrote:
On Thu, Nov 21, 2024 at 12:32 AM Jiri Slaby <jslaby@suse.cz> wrote:
On 18. 11. 24, 16:22, Neal Gompa wrote:
But the storage increase is several orders of magnitude smaller than using DWARF data.
Then we could use ORC. Which is a reason of NOT having framepointers in the kernel, while being able to unwind.
Sure, do we already build our kernels with ORC?
Yes, since ORC's day 0. We used to have dwarf unwinder before that. And attempts to push dwarf upstream lead to ORC.
BTW let me cite from: https://docs.kernel.org/arch/x86/orc-unwinder.html ==== 9.2. ORC vs frame pointers With frame pointers enabled, GCC adds instrumentation code to every function in the kernel. The kernel’s .text size increases by about 3.2%, resulting in a broad kernel-wide slowdown. Measurements by Mel Gorman [1] have shown a slowdown of 5-10% for some workloads. ==== 9.3 is "ORC vs DWARF" and is interesting readings too: ==== The simpler debuginfo format also enables the unwinder to be much faster than DWARF, which is important for perf and lockdep. In a basic performance test by Jiri Slaby [2], the ORC unwinder was about 20x faster than an out-of-tree DWARF unwinder. (Note: That measurement was taken before some performance tweaks were added, which doubled performance, so the speedup over DWARF may be closer to 40x.) ==== [1] https://lore.kernel.org/all/20170602104048.jkkzssljsompjdwy@suse.de/ [2] https://lore.kernel.org/r/d2ca5435-6386-29b8-db87-7f227c2b713a@suse.cz regards, -- js suse labs