Re: [PATCH -v8][RFC] mutex: implement adaptive spinning

[Avi Kivity]

Nick Piggin wrote:
> > (no they're not, Nick's ticket locks still spin on a shared cacheline
> > IIRC -- the MCS locks mentioned could fix this)
> >     
>
> It reminds me. I wrote a basic variation of MCS spinlocks a while back. And
> converted dcache lock to use it, which showed large dbench improvements on
> a big machine (of course for different reasons than the dbench improvements
> in this threaed).
>
> http://lkml.org/lkml/2008/8/28/24
>
> Each "lock" object is sane in size because given set of spin-local queues may
> only be used once per lock stack. But any spinlocks within a mutex acquisition
> will always be at the bottom of such a stack anyway, by definition.
>
> If you can use any code or concept for your code, that would be great.
>   

Does it make sense to replace 'nest' with a per-cpu counter that's 
incremented on each lock?  I guest you'd have to search for the value of 
nest on unlock, but it would a very short search (typically length 1, 2 
if lock sorting is used to avoid deadlocks).

I think you'd need to make the lock store the actual node pointer, not 
the cpu number, since the values of nest would be different on each cpu.

That would allow you to replace spinlocks with mcs_locks wholesale.

--
error compiling committee.c: too many arguments to function

--
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/