[<prev] [next>] [day] [month] [year] [list]
Message-Id: <4530CF770200007800024388@emea5-mh.id5.novell.com>
Date: Sat, 14 Oct 2006 12:52:20 +0200
From: "Jan Beulich" <jbeulich@...ell.com>
To: <mingo@...e.hu>, <akinobu.mita@...il.com>, <akpm@...l.org>
Cc: <dwm@...r.net>, <ak@...e.de>, <linux-kernel@...r.kernel.org>
Subject: Re: [patch 0/7] fault-injection capabilities (v5)
>> I don't feel much slowness with STACKTRACE & FRAME_POINTER and
>> enabling stacktrace filter. But with enabling STACK_UNWIND I feel
>> big latency on X. (There are two type of implementation of stacktrace
>> filter in it [1] using STACKTRACE with FRAME_POINTER, and [2] STACK_UNWIND)
>>
>> I don't know why there is quite difference between simple STACKTRACE and
>> STACK_UNWIND. I'm about to try to use rb tree rather than linked list in
>> unwind.
>
>umm, we've hit this before, recently - iirc it was making lockdep run
>really slowly.
>
>The new unwinding code is apparently really inefficient in some situations.
>It wasn't expected that it would be called at a high frequency, except people
>_do_ want to do that.
>
>I forget the details, but I can cc people who have better memory.
The problem is that there's currently nothing to allow a binary search through
the unwind descriptors. The easy path to add these is closed as binutils don't
work here due to two independent limitations. Hence I'm going to add a two-
phase initializations, the second part of which will allocate and initialize a
helper table equivalent to a linker generated .eh_frame_hdr section. I'm not
certain at this point whether we'll need this for modules too.
Jan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists