From: Vineet Gupta <Vineet.Gupta1@synopsys.com>
To: Jan Beulich <JBeulich@suse.com>
CC: lkml <linux-kernel@vger.kernel.org>,
        arcml <linux-snps-arc@lists.infradead.org>,
        Peter Zijlstra <peterz@infradead.org>
Subject: dwarf unwinder question
Thread-Topic: dwarf unwinder question
Thread-Index: AdEl72rJeB1Pt4QvSVCOStxnQ500rg==
Date: Mon, 23 Nov 2015 13:03:59 +0000
Message-ID: <C2D7FE5348E1B147BCA15975FBA23075F44D2DF8@IN01WEMBXA.internal.synopsys.com>
Accept-Language: en-US, en-IN
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 8BIT
MIME-Version: 1.0
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1209
Lines: 27

Hi Jan,

ARC port has kernel dwarf unwinder shamelessly copied from your original code
which existed in tree at the time (circa 2008)

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.

TIA,
-Vineet
--
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/