Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1197911

[PATCH v4 1/7] locking/pvqspinlock: Unconditional PV kick with _Q_SLOW_VAL

Show all headers | View raw

The smp_store_release() is not a full barrier. In order to avoid missed
wakeup, we may need to add memory barrier around locked and cpu state
variables adding to complexity. As the chance of spurious wakeup is very
low, it is easier and safer to just do an unconditional kick at unlock
time.

Signed-off-by: Waiman Long <Waiman.Long@hp.com>
---
 kernel/locking/qspinlock_paravirt.h |   11 ++++++++---
 1 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/kernel/locking/qspinlock_paravirt.h b/kernel/locking/qspinlock_paravirt.h
index 15d3733..2dd4b39 100644
--- a/kernel/locking/qspinlock_paravirt.h
+++ b/kernel/locking/qspinlock_paravirt.h
@@ -240,7 +240,6 @@ static void pv_wait_head(struct qspinlock *lock, struct mcs_spinlock *node)
 			cpu_relax();
 		}
 
-		WRITE_ONCE(pn->state, vcpu_halted);
 		if (!lp) { /* ONCE */
 			lp = pv_hash(lock, pn);
 			/*
@@ -320,9 +319,15 @@ __visible void __pv_queued_spin_unlock(struct qspinlock *lock)
 	/*
 	 * At this point the memory pointed at by lock can be freed/reused,
 	 * however we can still use the pv_node to kick the CPU.
+	 *
+	 * As smp_store_release() is not a full barrier, adding a check to
+	 * the node->state doesn't guarantee the checking is really done
+	 * after clearing the lock byte since they are in 2 separate
+	 * cachelines and so hardware can reorder them. So either we insert
+	 * memory barrier here and in the corresponding pv_wait_head()
+	 * function or we do an unconditional kick which is what is done here.
 	 */
-	if (READ_ONCE(node->state) == vcpu_halted)
-		pv_kick(node->cpu);
+	pv_kick(node->cpu);
 }
 /*
  * Include the architecture specific callee-save thunk of the
-- 
1.7.1

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

Back to linux.kernel | Previous | Next — Next in thread | Find similar | Unroll thread

Thread

[PATCH v4 1/7] locking/pvqspinlock: Unconditional PV kick with _Q_SLOW_VAL Waiman Long <Waiman.Long@hp.com> - 2015-08-01 04:30 +0200
  RE: [PATCH v4 1/7] locking/pvqspinlock: Unconditional PV kick with  _Q_SLOW_VAL "Long, Wai Man" <waiman.long@hp.com> - 2015-08-01 22:20 +0200
  Re: [PATCH v4 1/7] locking/pvqspinlock: Unconditional PV kick with  _Q_SLOW_VAL Peter Zijlstra <peterz@infradead.org> - 2015-08-02 00:30 +0200
    Re: [PATCH v4 1/7] locking/pvqspinlock: Unconditional PV kick with  _Q_SLOW_VAL Davidlohr Bueso <dave@stgolabs.net> - 2015-08-03 20:30 +0200
      Re: [PATCH v4 1/7] locking/pvqspinlock: Unconditional PV kick with  _Q_SLOW_VAL Peter Zijlstra <peterz@infradead.org> - 2015-08-03 20:40 +0200
        Re: [PATCH v4 1/7] locking/pvqspinlock: Unconditional PV kick with  _Q_SLOW_VAL Davidlohr Bueso <dave@stgolabs.net> - 2015-08-03 21:10 +0200
          Re: [PATCH v4 1/7] locking/pvqspinlock: Unconditional PV kick with  _Q_SLOW_VAL Peter Zijlstra <peterz@infradead.org> - 2015-08-03 22:00 +0200
    Re: [PATCH v4 1/7] locking/pvqspinlock: Unconditional PV kick with  _Q_SLOW_VAL Waiman Long <waiman.long@hp.com> - 2015-08-04 05:30 +0200

csiph-web