Re: [RFC][PATCH 1/3] locking: Introduce smp_acquire__after_ctrl_dep

2016-06-07 Thread Paul E. McKenney
On Tue, Jun 07, 2016 at 07:01:07PM +0100, Will Deacon wrote: > On Tue, Jun 07, 2016 at 08:23:15AM -0700, Paul E. McKenney wrote: > > On Tue, Jun 07, 2016 at 04:59:02PM +0200, Hannes Frederic Sowa wrote: > > > Sorry, to follow-up again on this. Will Deacon's comments were about > > > conditional-mov

Re: [RFC][PATCH 1/3] locking: Introduce smp_acquire__after_ctrl_dep

2016-06-07 Thread Paul E. McKenney
On Tue, Jun 07, 2016 at 07:01:07PM +0100, Will Deacon wrote: > On Tue, Jun 07, 2016 at 08:23:15AM -0700, Paul E. McKenney wrote: > > On Tue, Jun 07, 2016 at 04:59:02PM +0200, Hannes Frederic Sowa wrote: > > > Sorry, to follow-up again on this. Will Deacon's comments were about > > > conditional-mov

Re: [RFC][PATCH 1/3] locking: Introduce smp_acquire__after_ctrl_dep

2016-06-07 Thread Paul E. McKenney
On Tue, Jun 07, 2016 at 07:48:53PM +0200, Peter Zijlstra wrote: > On Tue, Jun 07, 2016 at 08:23:15AM -0700, Paul E. McKenney wrote: > > and if the hardware is not excessively clever (bad bet, by the > > way, long term), > > This ^ > > > > Is there something else than conditional move instructions

Re: [RFC][PATCH 1/3] locking: Introduce smp_acquire__after_ctrl_dep

2016-06-07 Thread Hannes Frederic Sowa
On 07.06.2016 17:23, Paul E. McKenney wrote: > On Tue, Jun 07, 2016 at 04:59:02PM +0200, Hannes Frederic Sowa wrote: >> On 07.06.2016 15:06, Paul E. McKenney wrote: >>> On Tue, Jun 07, 2016 at 02:41:44PM +0200, Hannes Frederic Sowa wrote: On 07.06.2016 09:15, Peter Zijlstra wrote: >> >

Re: [RFC][PATCH 1/3] locking: Introduce smp_acquire__after_ctrl_dep

2016-06-07 Thread Will Deacon
On Tue, Jun 07, 2016 at 08:23:15AM -0700, Paul E. McKenney wrote: > On Tue, Jun 07, 2016 at 04:59:02PM +0200, Hannes Frederic Sowa wrote: > > Sorry, to follow-up again on this. Will Deacon's comments were about > > conditional-move instructions, which this compiler-option would prevent, > > as far

Re: [RFC][PATCH 1/3] locking: Introduce smp_acquire__after_ctrl_dep

2016-06-07 Thread Peter Zijlstra
On Tue, Jun 07, 2016 at 08:23:15AM -0700, Paul E. McKenney wrote: > and if the hardware is not excessively clever (bad bet, by the > way, long term), This ^ > > Is there something else than conditional move instructions that could > > come to play here? Obviously a much smarter CPU could evaluate

Re: [RFC][PATCH 1/3] locking: Introduce smp_acquire__after_ctrl_dep

2016-06-07 Thread Paul E. McKenney
On Tue, Jun 07, 2016 at 04:59:02PM +0200, Hannes Frederic Sowa wrote: > On 07.06.2016 15:06, Paul E. McKenney wrote: > > On Tue, Jun 07, 2016 at 02:41:44PM +0200, Hannes Frederic Sowa wrote: > >> On 07.06.2016 09:15, Peter Zijlstra wrote: > > diff --git a/Documentation/memory-barriers.txt

Re: [RFC][PATCH 1/3] locking: Introduce smp_acquire__after_ctrl_dep

2016-06-07 Thread Hannes Frederic Sowa
On 07.06.2016 15:06, Paul E. McKenney wrote: > On Tue, Jun 07, 2016 at 02:41:44PM +0200, Hannes Frederic Sowa wrote: >> On 07.06.2016 09:15, Peter Zijlstra wrote: diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt index 147ae8ec836f..a4d0a99de04d

Re: [RFC][PATCH 1/3] locking: Introduce smp_acquire__after_ctrl_dep

2016-06-07 Thread Paul E. McKenney
On Tue, Jun 07, 2016 at 02:41:44PM +0200, Hannes Frederic Sowa wrote: > On 07.06.2016 09:15, Peter Zijlstra wrote: > >> > >> diff --git a/Documentation/memory-barriers.txt > >> b/Documentation/memory-barriers.txt > >> index 147ae8ec836f..a4d0a99de04d 100644 > >> --- a/Documentation/memory-barriers

Re: [RFC][PATCH 1/3] locking: Introduce smp_acquire__after_ctrl_dep

2016-06-07 Thread Hannes Frederic Sowa
On 07.06.2016 09:15, Peter Zijlstra wrote: >> >> diff --git a/Documentation/memory-barriers.txt >> b/Documentation/memory-barriers.txt >> index 147ae8ec836f..a4d0a99de04d 100644 >> --- a/Documentation/memory-barriers.txt >> +++ b/Documentation/memory-barriers.txt >> @@ -806,6 +806,41 @@ out-guess

Re: [RFC][PATCH 1/3] locking: Introduce smp_acquire__after_ctrl_dep

2016-06-07 Thread Peter Zijlstra
On Mon, Jun 06, 2016 at 10:28:24AM -0700, Paul E. McKenney wrote: > commit 43672d15aeb69b1a196c06cbc071cbade8d247fd > Author: Paul E. McKenney > Date: Mon Jun 6 10:19:42 2016 -0700 > > documentation: Clarify limited control-dependency scope > > Nothing in the control-dependencies s

Re: [RFC][PATCH 1/3] locking: Introduce smp_acquire__after_ctrl_dep

2016-06-06 Thread Paul E. McKenney
On Sat, Jun 04, 2016 at 08:29:29AM -0700, Paul E. McKenney wrote: > On Fri, Jun 03, 2016 at 02:45:53PM +0100, Will Deacon wrote: > > On Fri, Jun 03, 2016 at 06:32:38AM -0700, Paul E. McKenney wrote: > > > On Fri, Jun 03, 2016 at 02:23:10PM +0200, Peter Zijlstra wrote: > > > > On Fri, Jun 03, 2016 a

Re: [RFC][PATCH 1/3] locking: Introduce smp_acquire__after_ctrl_dep

2016-06-04 Thread Paul E. McKenney
On Fri, Jun 03, 2016 at 02:45:53PM +0100, Will Deacon wrote: > On Fri, Jun 03, 2016 at 06:32:38AM -0700, Paul E. McKenney wrote: > > On Fri, Jun 03, 2016 at 02:23:10PM +0200, Peter Zijlstra wrote: > > > On Fri, Jun 03, 2016 at 05:08:27AM -0700, Paul E. McKenney wrote: > > > > On Fri, Jun 03, 2016 a

Re: [RFC][PATCH 1/3] locking: Introduce smp_acquire__after_ctrl_dep

2016-06-03 Thread Will Deacon
On Fri, Jun 03, 2016 at 06:32:38AM -0700, Paul E. McKenney wrote: > On Fri, Jun 03, 2016 at 02:23:10PM +0200, Peter Zijlstra wrote: > > On Fri, Jun 03, 2016 at 05:08:27AM -0700, Paul E. McKenney wrote: > > > On Fri, Jun 03, 2016 at 11:38:34AM +0200, Peter Zijlstra wrote: > > > > On Fri, Jun 03, 201

Re: [RFC][PATCH 1/3] locking: Introduce smp_acquire__after_ctrl_dep

2016-06-03 Thread Paul E. McKenney
On Fri, Jun 03, 2016 at 02:27:52PM +0200, Peter Zijlstra wrote: > On Fri, Jun 03, 2016 at 02:23:10PM +0200, Peter Zijlstra wrote: > > On Fri, Jun 03, 2016 at 05:08:27AM -0700, Paul E. McKenney wrote: > > > On Fri, Jun 03, 2016 at 11:38:34AM +0200, Peter Zijlstra wrote: > > > > On Fri, Jun 03, 2016

Re: [RFC][PATCH 1/3] locking: Introduce smp_acquire__after_ctrl_dep

2016-06-03 Thread Paul E. McKenney
On Fri, Jun 03, 2016 at 02:23:10PM +0200, Peter Zijlstra wrote: > On Fri, Jun 03, 2016 at 05:08:27AM -0700, Paul E. McKenney wrote: > > On Fri, Jun 03, 2016 at 11:38:34AM +0200, Peter Zijlstra wrote: > > > On Fri, Jun 03, 2016 at 02:48:38PM +0530, Vineet Gupta wrote: > > > > On Wednesday 25 May 201

Re: [RFC][PATCH 1/3] locking: Introduce smp_acquire__after_ctrl_dep

2016-06-03 Thread Peter Zijlstra
On Fri, Jun 03, 2016 at 02:23:10PM +0200, Peter Zijlstra wrote: > On Fri, Jun 03, 2016 at 05:08:27AM -0700, Paul E. McKenney wrote: > > On Fri, Jun 03, 2016 at 11:38:34AM +0200, Peter Zijlstra wrote: > > > On Fri, Jun 03, 2016 at 02:48:38PM +0530, Vineet Gupta wrote: > > > > On Wednesday 25 May 201

Re: [RFC][PATCH 1/3] locking: Introduce smp_acquire__after_ctrl_dep

2016-06-03 Thread Peter Zijlstra
On Fri, Jun 03, 2016 at 05:08:27AM -0700, Paul E. McKenney wrote: > On Fri, Jun 03, 2016 at 11:38:34AM +0200, Peter Zijlstra wrote: > > On Fri, Jun 03, 2016 at 02:48:38PM +0530, Vineet Gupta wrote: > > > On Wednesday 25 May 2016 09:27 PM, Paul E. McKenney wrote: > > > > For your example, but keepin

Re: [RFC][PATCH 1/3] locking: Introduce smp_acquire__after_ctrl_dep

2016-06-03 Thread Paul E. McKenney
On Fri, Jun 03, 2016 at 11:38:34AM +0200, Peter Zijlstra wrote: > On Fri, Jun 03, 2016 at 02:48:38PM +0530, Vineet Gupta wrote: > > On Wednesday 25 May 2016 09:27 PM, Paul E. McKenney wrote: > > > For your example, but keeping the compiler in check: > > > > > > if (READ_ONCE(a)) > > >

Re: [RFC][PATCH 1/3] locking: Introduce smp_acquire__after_ctrl_dep

2016-06-03 Thread Peter Zijlstra
On Fri, Jun 03, 2016 at 02:48:38PM +0530, Vineet Gupta wrote: > On Wednesday 25 May 2016 09:27 PM, Paul E. McKenney wrote: > > For your example, but keeping the compiler in check: > > > > if (READ_ONCE(a)) > > WRITE_ONCE(b, 1); > > smp_rmb(); > > WRITE_ONCE(c, 2); So I thi

Re: [RFC][PATCH 1/3] locking: Introduce smp_acquire__after_ctrl_dep

2016-06-03 Thread Vineet Gupta
On Wednesday 25 May 2016 09:27 PM, Paul E. McKenney wrote: > For your example, but keeping the compiler in check: > > if (READ_ONCE(a)) > WRITE_ONCE(b, 1); > smp_rmb(); > WRITE_ONCE(c, 2); > > On x86, the smp_rmb() is as you say nothing but barrier(). However, > x

Re: [RFC][PATCH 1/3] locking: Introduce smp_acquire__after_ctrl_dep

2016-05-25 Thread Paul E. McKenney
On Wed, May 25, 2016 at 09:54:55AM -0700, Linus Torvalds wrote: > On Wed, May 25, 2016 at 9:28 AM, Peter Zijlstra wrote: > > > > I would consider any architecture that allows speculative stores as > > broken. They are values out of thin air and would make any kind of > > concurrency extremely 'int

Re: [RFC][PATCH 1/3] locking: Introduce smp_acquire__after_ctrl_dep

2016-05-25 Thread Linus Torvalds
On Wed, May 25, 2016 at 9:28 AM, Peter Zijlstra wrote: > > I would consider any architecture that allows speculative stores as > broken. They are values out of thin air and would make any kind of > concurrency extremely 'interesting'. It's worth noting that the same is true of compilers too. You

Re: [RFC][PATCH 1/3] locking: Introduce smp_acquire__after_ctrl_dep

2016-05-25 Thread Peter Zijlstra
On Wed, May 25, 2016 at 08:57:47AM -0700, Paul E. McKenney wrote: > For your example, but keeping the compiler in check: > > if (READ_ONCE(a)) > WRITE_ONCE(b, 1); > smp_rmb(); > WRITE_ONCE(c, 2); > > On x86, the smp_rmb() is as you say nothing but barrier(). Howev

Re: [RFC][PATCH 1/3] locking: Introduce smp_acquire__after_ctrl_dep

2016-05-25 Thread Paul E. McKenney
On Wed, May 25, 2016 at 11:20:42AM -0400, Waiman Long wrote: > On 05/25/2016 12:53 AM, Paul E. McKenney wrote: > >On Tue, May 24, 2016 at 11:01:21PM -0400, Waiman Long wrote: > >>On 05/24/2016 10:27 AM, Peter Zijlstra wrote: > >>>Introduce smp_acquire__after_ctrl_dep(), this construct is not > >>>u

Re: [RFC][PATCH 1/3] locking: Introduce smp_acquire__after_ctrl_dep

2016-05-25 Thread Waiman Long
On 05/25/2016 12:53 AM, Paul E. McKenney wrote: On Tue, May 24, 2016 at 11:01:21PM -0400, Waiman Long wrote: On 05/24/2016 10:27 AM, Peter Zijlstra wrote: Introduce smp_acquire__after_ctrl_dep(), this construct is not uncommen, but the lack of this barrier is. Signed-off-by: Peter Zijlstra (In

Re: [RFC][PATCH 1/3] locking: Introduce smp_acquire__after_ctrl_dep

2016-05-25 Thread Paul E. McKenney
On Wed, May 25, 2016 at 01:39:30PM +0800, Boqun Feng wrote: > On Tue, May 24, 2016 at 09:53:29PM -0700, Paul E. McKenney wrote: > > On Tue, May 24, 2016 at 11:01:21PM -0400, Waiman Long wrote: > > > On 05/24/2016 10:27 AM, Peter Zijlstra wrote: > > > >Introduce smp_acquire__after_ctrl_dep(), this c

Re: [RFC][PATCH 1/3] locking: Introduce smp_acquire__after_ctrl_dep

2016-05-24 Thread Boqun Feng
On Tue, May 24, 2016 at 09:53:29PM -0700, Paul E. McKenney wrote: > On Tue, May 24, 2016 at 11:01:21PM -0400, Waiman Long wrote: > > On 05/24/2016 10:27 AM, Peter Zijlstra wrote: > > >Introduce smp_acquire__after_ctrl_dep(), this construct is not > > >uncommen, but the lack of this barrier is. > >

Re: [RFC][PATCH 1/3] locking: Introduce smp_acquire__after_ctrl_dep

2016-05-24 Thread Paul E. McKenney
On Tue, May 24, 2016 at 11:01:21PM -0400, Waiman Long wrote: > On 05/24/2016 10:27 AM, Peter Zijlstra wrote: > >Introduce smp_acquire__after_ctrl_dep(), this construct is not > >uncommen, but the lack of this barrier is. > > > >Signed-off-by: Peter Zijlstra (Intel) > >--- > > include/linux/compile

[RFC][PATCH 1/3] locking: Introduce smp_acquire__after_ctrl_dep

2016-05-24 Thread Peter Zijlstra
Introduce smp_acquire__after_ctrl_dep(), this construct is not uncommen, but the lack of this barrier is. Signed-off-by: Peter Zijlstra (Intel) --- include/linux/compiler.h | 14 ++ ipc/sem.c| 14 ++ 2 files changed, 12 insertions(+), 16 deletions(-)