Re: [patch 0/7] fault-injection capabilities (v5)

[Jan Beulich]

>> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/