lkml.org 
[lkml]   [2017]   [Jun]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v2 0/8] x86: undwarf unwinder
On Thu, Jun 29, 2017 at 09:55:47AM +0200, Ingo Molnar wrote:
>
> * Josh Poimboeuf <jpoimboe@redhat.com> wrote:
>
> > Undwarf 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.
> >
> > In contrast, the undwarf unwinder has no effect on text size or runtime
> > performance, because the debuginfo is out of band. So if you disable
> > frame pointers and enable undwarf, you get a nice performance
> > improvement across the board, and still have reliable stack traces.
> >
> > Another benefit of undwarf compared to frame pointers is that it can
> > reliably unwind across interrupts and exceptions. Frame pointer based
> > unwinds can skip the caller of the interrupted function if it was a leaf
> > function or if the interrupt hit before the frame pointer was saved.
> >
> > The main disadvantage of undwarf compared to frame pointers is that it
> > needs more memory to store the undwarf table: roughly 3-5MB depending on
> > the kernel config.
>
> Note that it's not just a performance improvement, but also an instruction cache
> locality improvement: 3.2% .text savings almost directly transform into a
> similarly sized reduction in cache footprint. That can transform to even higher
> speedups for workloads whose cache locality is borderline.

I'll add that detail to the docs.

> I _really_ like this feature, and the independence of the debuginfo data format.
>
> Logistically it's too bad we are 3 days away from the merge window to be able to
> pick this up:
>
> > 56 files changed, 3466 insertions(+), 1765 deletions(-)
>
> OTOH most of the diffstat is in objtool.
>
> Any objections to applying the first 3 objtool patches straight away and see
> whether anything breaks? That would significantly reduce the size of the rest of
> the patch set.

Merging the first 3 patches now sounds good to me. They implement
"stack validation 2.0" which is a good standalone improvement even
without undwarf. I think I've already ironed out all the issues
reported by the build bot.

> > I'm not tied to the 'undwarf' name, other naming ideas are welcome.
>
> Ha, a new bike shed painting job! ;-)
>
> I think 'undwarf' isn't a bad name, it's short, catchy and describes the purpose
> of the effort.
>
> But I cannot resist some other suggestions, after 'elf' and 'dwarf' the obvious
> candidates from the peoples of Middle-earth would be:
>
> - 'Hobbit'
> - 'Eagle'
> - 'Ent'
> - 'Dragon'
> - 'Troll'
> - 'Ainur'
>
> 'struct troll_entry' has a certain charm to it.
>
> 'Eagle' is even nicer IMHO: larger than a dwarf but so much faster - and eagles
> are beautiful! Plus the name is 2 letters shorter than 'unwdwarf', win-win.

Finally, we get to the important part ;-)

Thus far I've been partial to undwarf, and I haven't been able to shake
it.

But I like some of your suggestions. Especially troll and hobbit. Will
need to do some more deep thinking about it :-)

--
Josh

\
 
 \ /
  Last update: 2017-06-29 16:14    [W:0.958 / U:0.292 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site