Messages in this thread | | | Date | Sat, 14 Oct 2006 12:52:20 +0200 | From | "Jan Beulich" <> | 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |