Re: [patch 00/15] Generic Mutex Subsystem

[Linus Torvalds]

On Mon, 19 Dec 2005, Benjamin LaHaise wrote:
> 
> The only thing I can see as an improvement that a mutex can offer over 
> the current semaphore implementation is if we can perform the same 
> optimization that spinlocks perform in the unlock operation: don't use 
> a locked, serialising instruction in the up() codepath.  That might be 
> a bit tricky to implement, but it's definately a win on the P4 where the 
> cost of serialisation can be quite high.

Good point. However, it really _is_ hard, because we also need to know if 
the mutex was under contention. A spinlock doesn't care, so we can just 
overwrite the lock value. A mutex would always care, in order to know 
whether it needs to do the slow wakeup path. 

So I suspect you can't avoid serializing the unlock path for a mutex. The 
issue of "was there contention while I held it" fundamentally _is_ a 
serializing question.

> > [ Oh.  I'm looking at the semaphore code, and I realize that we have a 
> >   "wake_up(&sem->wait)" in the __down() path because we had some race long 
> >   ago that we fixed by band-aiding over it. Which means that we wake up 
> >   sleepers that shouldn't be woken up. THAT may well be part of the 
> >   performance problem.. The semaphores are really meant to wake up just 
> >   one at a time, but because of that race hack they'll wake up _two_ at a 
> >   time - once by up(), once by down().
> > 
> >   That also destroys the fairness. Does anybody remember why it's that 
> >   way? ]
> 
> History?

Oh, absolutely, I already checked the old BK history too, and that extra 
wake_up() has been there at least since before we even started using BK. 
So it's very much historical, I'm just wondering if somebody remembers far 
enough back that we'd know.

I don't see why it's needed (since we re-try the "atomic_add_negative()" 
inside the semaphore wait lock, and any up() that saw contention should 
have always been guaranteed to do a wakeup that should fill the race in 
between that atomic_add_negative() and the thing going to sleep). 

It may be that it is _purely_ historical, and simply isn't needed. That 
would be funny/sad, in the sense that we've had it there for years and 
years ;)

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