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-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
