Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751088AbdGMEkm (ORCPT ); Thu, 13 Jul 2017 00:40:42 -0400 Received: from one.firstfloor.org ([193.170.194.197]:60574 "EHLO one.firstfloor.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750789AbdGMEkk (ORCPT ); Thu, 13 Jul 2017 00:40:40 -0400 Date: Wed, 12 Jul 2017 21:40:38 -0700 From: Andi Kleen To: Mike Galbraith Cc: Andi Kleen , Josh Poimboeuf , x86@kernel.org, linux-kernel@vger.kernel.org, live-patching@vger.kernel.org, Linus Torvalds , Andy Lutomirski , Jiri Slaby , Ingo Molnar , "H. Peter Anvin" , Peter Zijlstra Subject: Re: [PATCH v3 00/10] x86: ORC unwinder (previously undwarf) Message-ID: <20170713044038.GE3044@two.firstfloor.org> References: <87wp7dmgoo.fsf@firstfloor.org> <1499914980.5107.18.camel@gmx.de> <20170713041524.GC3044@two.firstfloor.org> <1499920123.5107.29.camel@gmx.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1499920123.5107.29.camel@gmx.de> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1975 Lines: 48 On Thu, Jul 13, 2017 at 06:28:43AM +0200, Mike Galbraith wrote: > On Wed, 2017-07-12 at 21:15 -0700, Andi Kleen wrote: > > On Thu, Jul 13, 2017 at 05:03:00AM +0200, Mike Galbraith wrote: > > > On Wed, 2017-07-12 at 15:30 -0700, Andi Kleen wrote: > > > > Josh Poimboeuf writes: > > > > > > > > > > The ORC data format does have a few downsides compared to DWARF. The > > > > > ORC unwind tables take up ~1MB more memory than DWARF eh_frame tables. > > > > > > > > > Can we have an option to just use dwarf instead? For people > > > > who don't want to waste a MB+ to solve a problem that doesn't > > > > exist (as proven by many years of opensuse kernel experience) > > > > > > Sure the dwarf unwinder works well for crashes, but at the price of > > > demolishing ftrace/perf utility. > > > > You mean the unwind performance? > > Yeah, it hurts.. massively, has even been known to kill big boxen. Why was that? > > > That's a valid concern, but neither ORC nor dwarf are likely > > to address it. However most usages of ftrace/perf shouldn't be that > > depending on unwind performance -- just lower the frequency of your > > events. > > > > The only possible win is if the win from not using FP code is > > significant enough. On the x86 side the only modern CPUs that should really > > care about this are Atoms. > > Nope, they all care. Measure performance delta of fast/light stuff. Well if your test cares that much about function overhead you may want to try LTO. It can get rid of a lot of functions by doing cross file inlining. https://git.kernel.org/pub/scm/linux/kernel/git/ak/linux-misc.git/log/?h=lto-411-2 > Maybe I'm expecting too much good stuff to follow, but don't spoil it > for me, I think I'm looking at a real winner :) It's somewhat surprising. It would be good to under stand why that happens. Is it icache misses, data cache misses for the stack, or simply more instructions executed, or worse tail calls? -Andi