Re: [PATCH] remove LOCK_SECTION from x86_64 spin_lock asm

[Andi Kleen]

On Thu, Sep 16, 2004 at 08:58:05AM +0200, Ingo Molnar wrote:
> 
> * Andi Kleen <ak@xxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/