Worst case performance of up()

[Adrian Cox]

On Sat, 2006-11-25 at 07:45 +1100, Benjamin Herrenschmidt wrote:
> On Fri, 2006-11-24 at 16:21 +0000, Adrian Cox wrote:
> > Does anybody have any ideas what could make up() take so long in this
> > circumstance? I'd expect cache transfers to make the operation about 100
> > times slower, but this looks like repeated cache ping-pong between the
> > two CPUs.
> 
> Is it hung in up() (toplevel) or __up (low level) ?

Not yet proven.

> Have you tried some oprofile runs to catch the exact instruction where
> the cycles appear to be wasted ?

I've spent a day wrestling with oprofile, but I've not managed to
trigger the problem while profiling yet.  It's possible that the slight
overhead of oprofile is enough to change the scheduling behaviour.

It remains an odd problem, and rather hard to reproduce.  Unless I get
better data with oprofile this one may remain in the mystery file.

> Have you tried moving the semaphore away from whatever other data might
> be manipulated at the same time ? In it's own cache line maybe ?

I did try that, but it didn't make any difference.

-- 
Adrian Cox <adrian at humboldt.co.uk>