Date:   Thu, 29 Jun 2017 09:12:56 -0500
From:   Josh Poimboeuf <jpoimboe@...hat.com>
To:     Ingo Molnar <mingo@...nel.org>
Cc:     x86@...nel.org, linux-kernel@...r.kernel.org,
        live-patching@...r.kernel.org,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Andy Lutomirski <luto@...nel.org>, Jiri Slaby <jslaby@...e.cz>,
        "H. Peter Anvin" <hpa@...or.com>,
        Peter Zijlstra <peterz@...radead.org>
Subject: Re: [PATCH v2 0/8] x86: undwarf unwinder

On Thu, Jun 29, 2017 at 09:55:47AM +0200, Ingo Molnar wrote:
> 
> * Josh Poimboeuf <jpoimboe@...hat.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

Powered by blists - more mailing lists