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.
With this timeout mechanism, additional lockdep code shouldn't be needed
as the code will eventually call spin_lock() if the lock is really busy.
Regards,
Longman
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
