All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@kernel.org>
To: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: x86@kernel.org, linux-kernel@vger.kernel.org,
	live-patching@vger.kernel.org,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Andy Lutomirski <luto@kernel.org>, Jiri Slaby <jslaby@suse.cz>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Peter Zijlstra <peterz@infradead.org>
Subject: Re: [PATCH v2 0/8] x86: undwarf unwinder
Date: Thu, 29 Jun 2017 09:55:47 +0200	[thread overview]
Message-ID: <20170629075547.y24s7aq4nqwt2rll@gmail.com> (raw)
In-Reply-To: <cover.1498659915.git.jpoimboe@redhat.com>


* 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 _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.

> 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.

Thanks,

	Ingo

  parent reply	other threads:[~2017-06-29  7:56 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-28 15:11 [PATCH v2 0/8] x86: undwarf unwinder Josh Poimboeuf
2017-06-28 15:11 ` [PATCH v2 1/8] objtool: move checking code to check.c Josh Poimboeuf
2017-06-30 13:12   ` [tip:core/objtool] objtool: Move " tip-bot for Josh Poimboeuf
2017-06-28 15:11 ` [PATCH v2 2/8] objtool, x86: add several functions and files to the objtool whitelist Josh Poimboeuf
2017-06-30 13:12   ` [tip:core/objtool] objtool, x86: Add " tip-bot for Josh Poimboeuf
2017-06-28 15:11 ` [PATCH v2 3/8] objtool: stack validation 2.0 Josh Poimboeuf
2017-06-30  8:32   ` Ingo Molnar
2017-06-30 13:23     ` Josh Poimboeuf
2017-06-30 13:26       ` Josh Poimboeuf
2017-06-30 14:09     ` [PATCH] objtool: silence warnings for functions which use iret Josh Poimboeuf
2017-06-30 17:49       ` [tip:core/objtool] objtool: Silence warnings for functions which use IRET tip-bot for Josh Poimboeuf
2017-06-30 13:13   ` [tip:core/objtool] objtool: Implement stack validation 2.0 tip-bot for Josh Poimboeuf
2017-06-28 15:11 ` [PATCH v2 4/8] objtool: add undwarf debuginfo generation Josh Poimboeuf
2017-06-29  7:14   ` Ingo Molnar
2017-06-29 13:40     ` Josh Poimboeuf
2017-06-29  7:25   ` Ingo Molnar
2017-06-29 14:04     ` Josh Poimboeuf
2017-06-29 14:46       ` Ingo Molnar
2017-06-29 15:06         ` Josh Poimboeuf
2017-07-06 20:36           ` Josh Poimboeuf
2017-07-07  9:44             ` Ingo Molnar
2017-07-11  2:58               ` Josh Poimboeuf
2017-07-11  8:40                 ` Ingo Molnar
2017-06-28 15:11 ` [PATCH v2 5/8] objtool, x86: add facility for asm code to provide unwind hints Josh Poimboeuf
2017-06-28 15:11 ` [PATCH v2 6/8] x86/entry: add unwind hint annotations Josh Poimboeuf
2017-06-29 17:53   ` Josh Poimboeuf
2017-06-29 18:50     ` Andy Lutomirski
2017-06-29 19:05       ` Josh Poimboeuf
2017-06-29 21:09         ` Andy Lutomirski
2017-06-29 21:41           ` Josh Poimboeuf
2017-06-29 22:59             ` Andy Lutomirski
2017-06-30  2:12               ` Josh Poimboeuf
2017-06-30  5:05                 ` Andy Lutomirski
2017-06-30  5:41                   ` Andy Lutomirski
2017-06-30 13:11                     ` Josh Poimboeuf
2017-06-30 15:44                       ` Andy Lutomirski
2017-06-30 15:55                         ` Josh Poimboeuf
2017-06-30 15:56                           ` Andy Lutomirski
2017-06-30 16:16                             ` Josh Poimboeuf
2017-06-28 15:11 ` [PATCH v2 7/8] x86/asm: add unwind hint annotations to sync_core() Josh Poimboeuf
2017-06-28 15:11 ` [PATCH v2 8/8] x86/unwind: add undwarf unwinder Josh Poimboeuf
2017-06-29  7:55 ` Ingo Molnar [this message]
2017-06-29 14:12   ` [PATCH v2 0/8] x86: " Josh Poimboeuf
2017-06-29 19:13     ` Josh Poimboeuf

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170629075547.y24s7aq4nqwt2rll@gmail.com \
    --to=mingo@kernel.org \
    --cc=hpa@zytor.com \
    --cc=jpoimboe@redhat.com \
    --cc=jslaby@suse.cz \
    --cc=linux-kernel@vger.kernel.org \
    --cc=live-patching@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=peterz@infradead.org \
    --cc=torvalds@linux-foundation.org \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.