On 06/26/2013 09:15 PM, Waiman Long wrote:
On 06/26/2013 09:06 PM, Andi Kleen wrote:
In the uncontended case, doing spin_unlock_wait will be similar to
spin_can_lock. This, when combined with a cmpxchg, is still faster
than doing 2 atomic operations in spin_lock/spin_unlock.
I'm totally against any new users of spin_unlock_wait()
It has bizarre semantics, most likely will make various
lock optimizations impossible, it's race condition hell
for most users etc.
spin_can_lock() is not quite as bad has a lot of the similar problems.
BTW, spin_can_lock is just the negation of spin_is_locked.
e.g. with elision it's not.
-Andi
OK, it is about Haswell's lock elision feature. I will see what I can
do to remove those problematic function calls.
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?
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
