Re: [PATCH v2 1/2] spinlock: New spinlock_refcount.h for locklessupdate of refcount

From: Waiman Long
Date: Sat Jun 29 2013 - 16:30:40 EST


On 06/28/2013 09:46 AM, Thomas Gleixner wrote:
On Thu, 27 Jun 2013, Waiman Long wrote:
On 06/26/2013 09:37 PM, Andi Kleen wrote:
It will be hard to know what changes will be needed without knowing
the exact semantics of the spinlock functions with lock elision. Can
you explain a little more what bizarre semantics you are referring
to?
Totally independent of elision.

For example, what semantics does spin_unlock_wait() have with a ticket
lock. Where in the queue does it wait?
It doesn't really make sense with a ticket lock.

What semantics would lockdep put on it?

-Andi
Calling spin_unlock_wait() doesn't put the caller into a queue. It just wait
until the lock is no longer held by any thread. Yes, there is a possibility
that the lock can be so busy that it may be hold by various threads
continuously for a long time making it hard for those who wait to proceed.
Perhaps, I should change the code to abandon the use of spin_unlock_wait().
Instead, I can make it wait for the lock to be free with some kind of timeout
to make sure that it won't wait too long.
Please no timeout heuristics. They are bound to be wrong.

If the lock is held by some other cpu, then waiting for it with
unlock_wait() or a magic timeout is probably equally expensive as just
going into the slow path right away.

After some more thought, it may not be such a bad idea of have some kind of timeout. In that case, the code will just fall back to the old way of acquiring the spinlock before updating the count. If the lock is really busy, it is possible that the waiting thread may get starved to a point that it cannot proceed for a really long time. A timeout mechanism ensures that unfairness to the waiting thread will be limited. The exact timeout value is not that critical, a larger value will increase the probability of doing a lockless update and a smaller value will decrease the probability.

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