All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Davidlohr Bueso <dave@stgolabs.net>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	Boqun Feng <boqun.feng@gmail.com>,
	Manfred Spraul <manfred@colorfullife.com>,
	Waiman Long <Waiman.Long@hpe.com>, Ingo Molnar <mingo@kernel.org>,
	ggherdovich@suse.com, Mel Gorman <mgorman@techsingularity.net>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Paul McKenney <paulmck@linux.vnet.ibm.com>,
	Will Deacon <will.deacon@arm.com>
Subject: Re: sem_lock() vs qspinlocks
Date: Sat, 21 May 2016 09:37:39 +0200	[thread overview]
Message-ID: <20160521073739.GB15728@worktop.ger.corp.intel.com> (raw)
In-Reply-To: <20160521004839.GA28231@linux-uzut.site>

On Fri, May 20, 2016 at 05:48:39PM -0700, Davidlohr Bueso wrote:
> On Fri, 20 May 2016, Linus Torvalds wrote:
> 
> 
> >Oh, I definitely agree on the stable part, and yes, the "splt things
> >up" model should come later if people agree that it's a good thing.
> 
> The backporting part is quite nice, yes, but ultimately I think I prefer
> Linus' suggestion making things explicit, as opposed to consulting the spinlock
> implying barriers. I also hate to have an smp_mb() (particularly for spin_is_locked)
> given that we are not optimizing for the common case (regular mutual excl).

I'm confused; we _are_ optimizing for the common case. spin_is_locked()
is very unlikely to be used. And arguably should be used less in favour
of lockdep_assert_held().

> As opposed to spin_is_locked(), spin_unlock_wait() is perhaps more tempting
> to use for locking correctness. For example, taking a look at nf_conntrack_all_lock(),
> it too likes to get smart with spin_unlock_wait() -- also for finer graining purposes.
> While not identical to sems, it goes like:
> 
> nf_conntrack_all_lock():	nf_conntrack_lock():
> spin_lock(B);			spin_lock(A);
> 
> 				if (bar) { // false
> bar = 1;			   ...
> 				}
> [loop ctrl-barrier]				
>  spin_unlock_wait(A);
> foo();				foo();
> 
> If the spin_unlock_wait() doesn't yet see the store that makes A visibly locked,
> we could end up with both threads in foo(), no?. (Although I'm unsure about that
> ctrl barrier and archs could fall into it. The point was to see in-tree examples
> of creative thinking with locking).

I'm tempted to put that trailing smp_rmb() in spin_unlock_wait() too;
because I suspect the netfilter code is broken without it.

And it seems intuitive to assume that if we return from unlock_wait() we
can indeed observe the critical section we waited on.

Something a little like so; but then for _all_ implementations.

---
 include/asm-generic/qspinlock.h |  6 ++++++
 include/linux/compiler.h        | 13 ++++++++-----
 2 files changed, 14 insertions(+), 5 deletions(-)

diff --git a/include/asm-generic/qspinlock.h b/include/asm-generic/qspinlock.h
index 6bd05700d8c9..2f2eddd3e1f9 100644
--- a/include/asm-generic/qspinlock.h
+++ b/include/asm-generic/qspinlock.h
@@ -135,6 +135,12 @@ static inline void queued_spin_unlock_wait(struct qspinlock *lock)
 	smp_mb();
 	while (atomic_read(&lock->val) & _Q_LOCKED_MASK)
 		cpu_relax();
+
+	/*
+	 * Match the RELEASE of the spin_unlock() we just observed. Thereby
+	 * ensuring we observe the whole critical section that ended.
+	 */
+	smp_acquire__after_ctrl_dep();
 }
 
 #ifndef virt_spin_lock
diff --git a/include/linux/compiler.h b/include/linux/compiler.h
index 793c0829e3a3..3c4bc8160947 100644
--- a/include/linux/compiler.h
+++ b/include/linux/compiler.h
@@ -304,21 +304,24 @@ static __always_inline void __write_once_size(volatile void *p, void *res, int s
 	__u.__val;					\
 })
 
+/*
+ * A control dependency provides a LOAD->STORE order, the additional RMB
+ * provides LOAD->LOAD order, together they provide LOAD->{LOAD,STORE} order,
+ * aka. ACQUIRE.
+ */
+#define smp_acquire__after_ctrl_dep()	smp_rmb()
+
 /**
  * smp_cond_acquire() - Spin wait for cond with ACQUIRE ordering
  * @cond: boolean expression to wait for
  *
  * Equivalent to using smp_load_acquire() on the condition variable but employs
  * the control dependency of the wait to reduce the barrier on many platforms.
- *
- * The control dependency provides a LOAD->STORE order, the additional RMB
- * provides LOAD->LOAD order, together they provide LOAD->{LOAD,STORE} order,
- * aka. ACQUIRE.
  */
 #define smp_cond_acquire(cond)	do {		\
 	while (!(cond))				\
 		cpu_relax();			\
-	smp_rmb(); /* ctrl + rmb := acquire */	\
+	smp_acquire__after_ctrl_dep();		\
 } while (0)
 
 #endif /* __KERNEL__ */

  parent reply	other threads:[~2016-05-21  7:38 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-20  5:39 sem_lock() vs qspinlocks Davidlohr Bueso
2016-05-20  7:49 ` Peter Zijlstra
2016-05-20 15:00   ` Davidlohr Bueso
2016-05-20 15:05     ` Peter Zijlstra
2016-05-20 15:25       ` Davidlohr Bueso
2016-05-20 15:28       ` Peter Zijlstra
2016-05-20 20:47     ` Waiman Long
2016-05-20 20:52       ` Peter Zijlstra
2016-05-21  0:59         ` Davidlohr Bueso
2016-05-21  4:01           ` Waiman Long
2016-05-21  7:40             ` Peter Zijlstra
2016-05-20  7:53 ` Peter Zijlstra
2016-05-20  8:13 ` Peter Zijlstra
2016-05-20  8:18   ` Peter Zijlstra
2016-05-20  9:07     ` Giovanni Gherdovich
2016-05-20  9:34       ` Peter Zijlstra
2016-05-20  8:30 ` Peter Zijlstra
2016-05-20  9:00   ` Peter Zijlstra
2016-05-20 10:09     ` Ingo Molnar
2016-05-20 10:45       ` Mel Gorman
2016-05-20 11:58 ` Peter Zijlstra
2016-05-20 14:05   ` Boqun Feng
2016-05-20 15:21     ` Peter Zijlstra
2016-05-20 16:04       ` Peter Zijlstra
2016-05-20 17:00         ` Linus Torvalds
2016-05-20 21:06           ` Peter Zijlstra
2016-05-20 21:44             ` Linus Torvalds
2016-05-21  0:48               ` Davidlohr Bueso
2016-05-21  2:30                 ` Linus Torvalds
2016-05-21  7:37                 ` Peter Zijlstra [this message]
2016-05-21 13:49                   ` Manfred Spraul
2016-05-24 10:57                     ` Peter Zijlstra
2016-05-21 17:14                   ` Davidlohr Bueso
2016-05-23 12:25           ` Peter Zijlstra
2016-05-23 17:52             ` Linus Torvalds
2016-05-25  6:37               ` Boqun Feng
2016-05-22  8:43         ` Manfred Spraul
2016-05-22  9:38           ` Peter Zijlstra
2016-05-20 16:20   ` Davidlohr Bueso
2016-05-20 20:44   ` Waiman Long
2016-05-20 20:53     ` Peter Zijlstra

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160521073739.GB15728@worktop.ger.corp.intel.com \
    --to=peterz@infradead.org \
    --cc=Waiman.Long@hpe.com \
    --cc=boqun.feng@gmail.com \
    --cc=dave@stgolabs.net \
    --cc=ggherdovich@suse.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=manfred@colorfullife.com \
    --cc=mgorman@techsingularity.net \
    --cc=mingo@kernel.org \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=torvalds@linux-foundation.org \
    --cc=will.deacon@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.