Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752842AbbKWNmj (ORCPT ); Mon, 23 Nov 2015 08:42:39 -0500 Received: from prv-mh.provo.novell.com ([137.65.248.74]:36013 "EHLO prv-mh.provo.novell.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751646AbbKWNmh convert rfc822-to-8bit (ORCPT ); Mon, 23 Nov 2015 08:42:37 -0500 Message-Id: <565325DA02000078000B7D89@prv-mh.provo.novell.com> X-Mailer: Novell GroupWise Internet Agent 14.0.1 Date: Mon, 23 Nov 2015 06:42:34 -0700 From: "Jan Beulich" To: "Vineet Gupta" Cc: "Peter Zijlstra" , "arcml" , "lkml" Subject: Re: dwarf unwinder question References: <56531F8502000078000B7D52@prv-mh.provo.novell.com> In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8BIT Content-Disposition: inline Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2085 Lines: 46 >>> On 23.11.15 at 14:27, wrote: > On Monday 23 November 2015 06:45 PM, Jan Beulich wrote: >>>>> On 23.11.15 at 14:03, wrote: >>> I was wondering if u could answer a question in that respect: >>> arch/arc/kernel/unwind.c >>> >>> If the binary search for a PC fails, it resorts to linear search, which for >>> our >>> case was taking 3 million cycles (vs. normal ~2000). >>> Do you remember why this linear search step was needed - after all the binary >>> lookup table is created out of early parsing of the same data. >>> >>> The fail scenario is for hand asm symbols lacking gcc generated dwarf info >>> and we >>> don't have yet the CFI pseudo ops support in assembler. >>> I can fix memset etc to have empty dwarf info, still unwinder needs this >>> fixing. >>> >>> In case of perf, an overflow interrupt in hand optimized memset leads into >>> the >>> unwinder slow path linear search which causes RCU stalls and such. >>> I'm going to remove it but was wondering if u could provide some historic >>> background. >> Iirc there was no binary lookup at all originally. When it got added, >> it seemed odd to remove the linear lookup altogether (want to keep >> it at least for the case where the binary lookup table couldn't be >> built for whatever reason), and code structure seemed most >> reasonable to simply do one after the other instead of just either. >> I'm pretty sure the linear lookup could be skipped if you're sure the >> binary lookup table is correct and complete. > > Thx for quick reply. I'll remove the linear search as part of many other > tweaks to > speed it up - we can elide a lot of general dwarf checks / rechecks - given > that > it is used only for kernel unwinding (not user space). Don't tell Linus if you're removing any checks... Jan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/