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:2.295 / U:1.732 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site