Arjan van de Ven wrote:
On Thu, 2005-12-22 at 18:56 +1100, Nick Piggin wrote:
Ingo Molnar wrote:
* Nick Piggin <[email protected]> wrote:
It would be nice to first do a run with a fair implementation of
mutexes.
which fairness implementation do you mean - the one where all tasks will
get the lock in fair FIFO order, and a 'lucky bastard' cannot steal the
lock from waiters and thus put them at an indefinite disadvantage?
I guess so. I'm not so worried about the rare 'lucky bastard' ie. a
lock request coming in concurrently, but rather the naturally favoured
'this CPU' taking the lock again after waking up the head waiter but
before it gets a chance to run / transfer the cacheline.
that's just the most evil lucky bastard....
I'd probably just call "bastard": it is probably _unlucky_ when _doesn't_
get to retake the lock, judging by the factor-of-4 speedup that Jes
demonstrated.
Which might be the right thing to do, but having the front waiter go to
the back of the queue I think is not.
--
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com
-
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]
