|| ||Linus Torvalds <torvalds-AT-osdl.org>|
|| ||Ingo Molnar <mingo-AT-elte.hu>|
|| ||Re: [patch 00/15] Generic Mutex Subsystem|
|| ||Mon, 19 Dec 2005 12:12:26 -0800 (PST)|
|| ||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>,
Benjamin LaHaise <bcrl-AT-kvack.org>|
On Mon, 19 Dec 2005, Ingo Molnar wrote:
> average cost per op: 206.59 usecs
> average cost per op: 512.13 usecs
(mutex vs semaphore).
That looks suspiciously like exactly double the cost, so I do believe that
the double wake_up() might be exactly what is going on.
> hm, removing that wakeup quickly causes hung test-tasks.
So clearly it really is still hiding some bug.
> and even considering that the current semaphore implementation may have
> a fairness bug, i cannot imagine that making it more fair would also
> speed it up.
That's not the point. The extra wakeup() in th esemaphore code wakes up
two processes for every single up(), so the semaphores end up not just
being unfair, they also end up doing twice the work (because it will
result in the other processes effectively just doing the down() twice).
> I personally find the semaphore implementation clever but too complex,
> maybe that's a reason why such bugs might be hiding there. (possibly
> for many years already ...)
Oh, absolutely. It is too complex.
And don't get me wrong: if it's easier to just ignore the performance bug,
and introduce a new "struct mutex" that just doesn't have it, I'm all for
it. However, if so, I do NOT want to do the unnecessary renaming. "struct
semaphore" should stay as "struct semaphore", and we should not affect old
code in the _least_.
Then code can switch to "struct mutex" if people want to. And if one
reason for it ends up being that the code avoids a performance bug in the
process, all the better ;)
IOW, I really think this should be a series of small patches that don't
touch old users of "struct semaphore" at all. None of this "semaphore" to
"arch_semaphore" stuff, and the new "struct mutex" would not re-use _any_
of the names that the old "struct semaphore" uses.
to post comments)