[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] [PATCH 10/11] qspinlock: Paravirt support
- To: Paolo Bonzini <pbonzini@xxxxxxxxxx>
- From: Waiman Long <waiman.long@xxxxxx>
- Date: Wed, 18 Jun 2014 11:26:51 -0400
- Cc: linux-arch@xxxxxxxxxxxxxxx, Peter Zijlstra <a.p.zijlstra@xxxxxxxxx>, kvm@xxxxxxxxxxxxxxx, boris.ostrovsky@xxxxxxxxxx, scott.norton@xxxxxx, raghavendra.kt@xxxxxxxxxxxxxxxxxx, paolo.bonzini@xxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx, gleb@xxxxxxxxxx, virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx, Peter Zijlstra <peterz@xxxxxxxxxxxxx>, chegu_vinod@xxxxxx, david.vrabel@xxxxxxxxxx, oleg@xxxxxxxxxx, xen-devel@xxxxxxxxxxxxxxxxxxxx, tglx@xxxxxxxxxxxxx, paulmck@xxxxxxxxxxxxxxxxxx, torvalds@xxxxxxxxxxxxxxxxxxxx, mingo@xxxxxxxxxx
- Delivery-date: Wed, 18 Jun 2014 15:27:02 +0000
- List-id: Xen developer discussion <xen-devel.lists.xen.org>
On 06/18/2014 08:03 AM, Paolo Bonzini wrote:
Il 17/06/2014 00:08, Waiman Long ha scritto:
+void __pv_queue_unlock(struct qspinlock *lock)
+{
+ int val = atomic_read(&lock->val);
+
+ native_queue_unlock(lock);
+
+ if (val & _Q_LOCKED_SLOW)
+ ___pv_kick_head(lock);
+}
+
Again a race can happen here between the reading and writing of the lock
value. I can't think of a good way to do that without using cmpxchg.
Could you just use xchg on the locked byte?
Paolo
The slowpath flag is just an indication that the queue head cpu might
have been suspended. It may not be due to spurious wakeup. Releasing the
lock unconditionally may cause the queue to be changed while it is being
inspected. It really depending on how the cpu kicking is being handled.
My patch delays the unlocking until all the inspections had been done to
make sure that we don't waste time doing a cpu kick that is not needed.
-Longman
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
