Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755123AbbKWN3s (ORCPT ); Mon, 23 Nov 2015 08:29:48 -0500 Received: from smtprelay.synopsys.com ([198.182.47.9]:52434 "EHLO smtprelay.synopsys.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754904AbbKWN3g convert rfc822-to-8bit (ORCPT ); Mon, 23 Nov 2015 08:29:36 -0500 From: Vineet Gupta To: Jan Beulich CC: Peter Zijlstra , arcml , lkml Subject: Re: dwarf unwinder question Thread-Topic: dwarf unwinder question Thread-Index: AdEl72rJeB1Pt4QvSVCOStxnQ500rg== Date: Mon, 23 Nov 2015 13:27:27 +0000 Message-ID: References: <56531F8502000078000B7D52@prv-mh.provo.novell.com> Accept-Language: en-US, en-IN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.12.197.182] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1931 Lines: 41 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. > > Jan 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). -- 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/