From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752970AbdF2OM7 (ORCPT ); Thu, 29 Jun 2017 10:12:59 -0400 Received: from mx1.redhat.com ([209.132.183.28]:53172 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752807AbdF2OM6 (ORCPT ); Thu, 29 Jun 2017 10:12:58 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 7392C73B2A Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=jpoimboe@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 7392C73B2A Date: Thu, 29 Jun 2017 09:12:56 -0500 From: Josh Poimboeuf To: Ingo Molnar Cc: x86@kernel.org, linux-kernel@vger.kernel.org, live-patching@vger.kernel.org, Linus Torvalds , Andy Lutomirski , Jiri Slaby , "H. Peter Anvin" , Peter Zijlstra Subject: Re: [PATCH v2 0/8] x86: undwarf unwinder Message-ID: <20170629141256.ire7jhckc26hsute@treble> References: <20170629075547.y24s7aq4nqwt2rll@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20170629075547.y24s7aq4nqwt2rll@gmail.com> User-Agent: Mutt/1.6.0.1 (2016-04-01) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Thu, 29 Jun 2017 14:12:57 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jun 29, 2017 at 09:55:47AM +0200, Ingo Molnar wrote: > > * Josh Poimboeuf 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