On Wed, 2010-04-07 at 20:25 -0700, Darren Hart wrote:Thomas Gleixner wrote:On Wed, 7 Apr 2010, Darren Hart wrote:Thomas Gleixner wrote:
That's an interesting question, and I'm not sure what the right answer is. The current approach of the adaptive spinning in the kernel is to spin until the owner changes or deschedules, then stop and block. The idea is that if you didn't get the lock before the owner changed, you aren't going to get it in a very short period of time (you have at least an entire critical section to wait through plus whatever time you've already spent spinning). However, blocking just so another task can spin doesn't really make sense either, and makes the lock less fair than it could otherwise be.Why ? If the owner has changed and the new owner is running on anotherif ((curval & FUTEX_TID_MASK) != ownertid) {Hrm... at this point the owner has changed... so we should break and go
ownertid = curval & FUTEX_TID_MASK;
owner = update_owner(ownertid);
}
to sleep, not update the owner and start spinning again. The
futex_spin_on_owner() will detect this and abort, so I'm not seeing the
purpose of the above if() block.
cpu then why not spin further ?
Not only less fair, but potentially could cause starvation, no? Perhaps
you could see this if you changed your model to allow all contended
tasks to spin instead of just one.
If a spinning task blocks because of an owner change, and a new task
enters and starts spinning directly after the owner change, at what
point does the original task get woken up?
Its likely that the new
spinner will get the resource next, no? Rinse/repeat with another task
and the original spinner is starved.
(Or am I missing something? My understanding was that unfairness was
built-in to this algo... If so, then the above is a possibility, right?)