On Mon, 19 Dec 2005, Andi Kleen wrote:
>
> Do you have an idea where this big difference comes from? It doesn't look
> it's from the fast path which is essentially the same. Do the mutexes have
> that much better scheduling behaviour than semaphores? It is a bit hard to
> believe.
Are ingo's mutex'es perhaps not trying to be fair?
The normal mutexes try to make sure that if a process comes in and gets
stuck on a mutex, and then another CPU releases the mutex and immediately
tries to grab it again, the other CPU will _not_ get it.
That's a huge performance disadvantage, but it's done on purpose, because
otherwise you end up in a situation where the semaphore release code did
wake up the waiter, but before the waiter actually had time to grab it (it
has to go through the IPI and scheduling logic), the same CPU just grabbed
it again.
The original semaphores were unfair, and it works really well most of the
time. But then it really sucks in some nasty cases.
The numbers make me suspect that Ingo's mutexes are unfair too, but I've
not looked at the code yet.
NOTE! I'm not a huge fan of fairness per se. I think unfair is often ok,
and the performance advantages are certainly real. It may well be that the
cases that caused problems before are now done differently (eg we switched
the VM semaphore over to an rwsem), and that we can have an unfair and
fast mutex for those cases where we don't care.
I just suspect the comparison isn't fair.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
