[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170523072738.vi5sakodet2boddr@gmail.com>
Date: Tue, 23 May 2017 09:27:38 +0200
From: Ingo Molnar <mingo@...nel.org>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Jiri Slaby <jslaby@...e.cz>, Josh Poimboeuf <jpoimboe@...hat.com>,
Jiri Kosina <jikos@...nel.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Andrew Morton <akpm@...ux-foundation.org>,
live-patching@...r.kernel.org,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>,
"H. Peter Anvin" <hpa@...or.com>,
the arch/x86 maintainers <x86@...nel.org>,
Andy Lutomirski <luto@...nel.org>
Subject: Re: [PATCH 7/7] DWARF: add the config option
* Peter Zijlstra <peterz@...radead.org> wrote:
> On Wed, May 10, 2017 at 10:32:06AM +0200, Jiri Slaby wrote:
> > > But it does hurt, in the sense that the complicated format of DWARF CFI
> > > means the unwinder has to jump through a lot more hoops to read it.
> >
> > Why that matters, actually? Unwinder is nothing to be performance
> > oriented. And if somebody is doing a lot of unwinding during runtime,
> > they can switch to in-this-case-faster FP unwinder.
>
> perf (and ftrace) like the unwinder to be considered performance
> oriented.
Yes, and given how critical debugging is there's a kind of useful synergy here:
overall the perf unwinder is run about 10 orders of magnitude more often than the
debugging unwinder, so it's a very big help in shaking out unwinder/debug-info
bugs and increasing robustness overall.
The 'price' for using the unwinder in perf is that it has to be fast.
Thanks,
Ingo
Powered by blists - more mailing lists