Re: [patch 00/15] Generic Mutex Subsystem

[Linus Torvalds <torvalds@osdl.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.

However:

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

		Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/