On Thu, 2010-12-23 at 21:45 -0700, Gregory Haskins wrote:
We shouldn't be too quick to merely rip this out without a little
thinking. Clearly this is broken, however the intent was clear.
That being that if a waiter is spinning, we don't need to wake it up.
The wake up path is substantially more than a barrier; it includes a
barrier as well as grabbing the task_rq_lock only to find that the task
is oncpu. Then various accounting is updated, etc.
We know definitively that a waiter can only spin if the owner is oncpu,
by definition of adaptive spinning. We also know that only the owner
can release the lock to a waiter (spinning or not). So it seems clear
that avoiding unnecessary contention on the rq lock would be a Good
Perhaps this cannot be done safely, but if you saw an improvement in
dbench by merely removing a barrier, imagine the improvement by removing
the contention on the lock.
Happy Holidays to all!