Messages in this thread |  | | | Date | Thu, 16 Sep 2004 09:09:02 +0200 | | From | Andi Kleen <> | | Subject | Re: [PATCH] remove LOCK_SECTION from x86_64 spin_lock asm |
On Thu, Sep 16, 2004 at 08:58:05AM +0200, Ingo Molnar wrote: > > * Andi Kleen <ak@suse.de> wrote: > > > > the alternative would be to unwind the stack - quite some task on some > > > platforms ... > > > > Sometimes call graph profiling would be very useful, but I wouldn't > > want the profiler to do it by default, especially not for this silly > > simple case. dwarf2 unwinding is complex enough that just requiring > > frame pointers for the CG case would look attractive. > > but ... frame pointers are overhead to all of the kernel. (the overhead
Yes, it may be up to a few percent in extreme cases because it adds a stall on rsp on K8. On the other hand the code may get slightly smaller, because a rbp reference is one byte shorter than a rsp reference.
> is less pronounced on architectures with more registers, but even with > 15 registers, 14 or 15 can still be a difference.) While unwinding is > overhead to profiling only - if enabled. Also, there could be other > functionality (exception handling?) that could benefit from dwarf2 > unwinding.
Your oopses could get better backtraces, but that could be done with frame pointers too (I'm surprised nobody did it already btw...)
You can try to write a dwarf2 unwinder for the kernel (actually I think IA64 already has one, but it's quite complex as expected and doesn't easily map to anything else). Even with that doing a dwarf2 unwind interpretation will have much more overhead. For me it doesn't look unreasonable to recompile the kernel for special profiles though.
-Andi - 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/
|  |