Re: [PATCH] Fix dwarf2 unwinding through futex functions

[Andi Kleen <ak at linux dot intel dot com>]

On Mon, Oct 07, 2013 at 04:22:43PM -0700, Roland McGrath wrote:
> the straight line hot path.  Making the hot path be straight-line (branch
> not taken) is part of the benefit, but moving the slow path away so it is
> less likely to pollute I-cache may be a more important benefit.  If you
> want to change that you need to demonstrate conclusively that you are not
> harming performance. 

I doubt icache was ever the motivation for this. Usually it's static branch
prediction. But that is increasingly obsolete as the modern CPUs don't use 
the old static fallthrough rules anymore.

FWIW not being able to profile these locks far more impacts performance
than ever saving a few bytes of icache.

I can try to benchmark it, but benchmarking icache or branch 
prediction effects is usually difficult, and in this case the difference is
so small it's near certainly noise. 

The other issue is that a atomic operation does a partial serialization
of the machine, so it typically hides all of these effects anyways.

> In fact, the obvious change would be to change
> ".subsection 1" to ".section .text.cold", which would move the slow path
> code even farther away (the subsection is just the end of the text in the
> same .o file, while .text.cold would be all the way at the end of the DSO's
> text) so as to make I-cache pollution even less likely.

and profiling would be still broken. That's the big problem.

-Andi

-- 
ak@linux.intel.com -- Speaking for myself only