|| ||Linus Torvalds <torvalds-AT-osdl.org>|
|| ||Benjamin LaHaise <bcrl-AT-kvack.org>|
|| ||Re: [patch 00/15] Generic Mutex Subsystem|
|| ||Mon, 19 Dec 2005 11:55:59 -0800 (PST)|
|| ||Ingo Molnar <mingo-AT-elte.hu>, Andi Kleen <ak-AT-suse.de>,
Linux Kernel Mailing List <linux-kernel-AT-vger.kernel.org>,
Andrew Morton <akpm-AT-osdl.org>,
Arjan van de Ven <arjanv-AT-infradead.org>,
Steven Rostedt <rostedt-AT-goodmis.org>,
Alan Cox <alan-AT-lxorguk.ukuu.org.uk>,
Christoph Hellwig <hch-AT-infradead.org>,
David Howells <dhowells-AT-redhat.com>,
Alexander Viro <viro-AT-ftp.linux.org.uk>,
Oleg Nesterov <oleg-AT-tv-sign.ru>|
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
> > [ 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? ]
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
to post comments)