All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Hannes Frederic Sowa <hannes@stressinduktion.org>,
	Will Deacon <will.deacon@arm.com>,
	Vineet Gupta <Vineet.Gupta1@synopsys.com>,
	Waiman Long <waiman.long@hpe.com>,
	linux-kernel@vger.kernel.org, torvalds@linux-foundation.org,
	manfred@colorfullife.com, dave@stgolabs.net,
	boqun.feng@gmail.com, tj@kernel.org, pablo@netfilter.org,
	kaber@trash.net, davem@davemloft.net, oleg@redhat.com,
	netfilter-devel@vger.kernel.org, sasha.levin@oracle.com,
	hofrat@osadl.org
Subject: Re: [RFC][PATCH 1/3] locking: Introduce smp_acquire__after_ctrl_dep
Date: Tue, 7 Jun 2016 11:44:09 -0700	[thread overview]
Message-ID: <20160607184409.GG3723@linux.vnet.ibm.com> (raw)
In-Reply-To: <20160607174853.GJ30154@twins.programming.kicks-ass.net>

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 that could
> > > come to play here? Obviously a much smarter CPU could evaluate all the
> > > jumps and come to the conclusion that the write to c is never depending
> > > on the load from a, but is this implemented somewhere in hardware?
> > 
> > I don't know of any hardware that does that, but given that conditional
> > moves are supported by some weakly ordered hardware, it looks to me
> > that we are stuck with the possibility of "a"-"c" reordering.
> 
> Is why I'm scared of relying on the non-condition.
> 
> The if and else branches are obviously dependent on the completion of
> the load; anything after that, not so much.
> 
> You could construct an argument against this program order speculation
> based on interrupts, which should not observe the stores out of order
> etc.. but if the hardware is that clever, it can also abort the entire
> speculation on interrupt (much like hardware transactions already can).
> 
> So even if today no hardware is this clever (and that isn't proven)
> there's nothing saying it will not ever be.
> 
> This is why I really do not want to advertise and or rely on this
> behaviour.

What Peter said!  ;-)

							Thanx, Paul

  reply	other threads:[~2016-06-07 18:44 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-24 14:27 [RFC][PATCH 0/3] spin_unlock_wait and assorted borkage Peter Zijlstra
2016-05-24 14:27 ` [RFC][PATCH 1/3] locking: Introduce smp_acquire__after_ctrl_dep Peter Zijlstra
     [not found]   ` <57451581.6000700@hpe.com>
2016-05-25  4:53     ` Paul E. McKenney
2016-05-25  5:39       ` Boqun Feng
2016-05-25 14:29         ` Paul E. McKenney
2016-05-25 15:20       ` Waiman Long
2016-05-25 15:57         ` Paul E. McKenney
2016-05-25 16:28           ` Peter Zijlstra
2016-05-25 16:54             ` Linus Torvalds
2016-05-25 18:59               ` Paul E. McKenney
2016-06-03  9:18           ` Vineet Gupta
2016-06-03  9:38             ` Peter Zijlstra
2016-06-03 12:08               ` Paul E. McKenney
2016-06-03 12:23                 ` Peter Zijlstra
2016-06-03 12:27                   ` Peter Zijlstra
2016-06-03 13:33                     ` Paul E. McKenney
2016-06-03 13:32                   ` Paul E. McKenney
2016-06-03 13:45                     ` Will Deacon
2016-06-04 15:29                       ` Paul E. McKenney
2016-06-06 17:28                         ` Paul E. McKenney
2016-06-07  7:15                           ` Peter Zijlstra
2016-06-07 12:41                             ` Hannes Frederic Sowa
2016-06-07 13:06                               ` Paul E. McKenney
2016-06-07 14:59                                 ` Hannes Frederic Sowa
2016-06-07 15:23                                   ` Paul E. McKenney
2016-06-07 17:48                                     ` Peter Zijlstra
2016-06-07 18:44                                       ` Paul E. McKenney [this message]
2016-06-07 18:01                                     ` Will Deacon
2016-06-07 18:44                                       ` Paul E. McKenney
2016-06-07 18:54                                       ` Paul E. McKenney
2016-06-07 18:37                                     ` Hannes Frederic Sowa
2016-05-24 14:27 ` [RFC][PATCH 2/3] locking: Annotate spin_unlock_wait() users Peter Zijlstra
2016-05-24 16:17   ` Linus Torvalds
2016-05-24 16:22     ` Tejun Heo
2016-05-24 16:58       ` Peter Zijlstra
2016-05-25 19:28         ` Tejun Heo
2016-05-24 16:57     ` Peter Zijlstra
2016-05-24 14:27 ` [RFC][PATCH 3/3] locking,netfilter: Fix nf_conntrack_lock() Peter Zijlstra
2016-05-24 14:42   ` Peter Zijlstra
     [not found]   ` <3e1671fc-be0f-bc95-4fbb-6bfc56e6c15b@colorfullife.com>
2016-05-26 13:54     ` 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=20160607184409.GG3723@linux.vnet.ibm.com \
    --to=paulmck@linux.vnet.ibm.com \
    --cc=Vineet.Gupta1@synopsys.com \
    --cc=boqun.feng@gmail.com \
    --cc=dave@stgolabs.net \
    --cc=davem@davemloft.net \
    --cc=hannes@stressinduktion.org \
    --cc=hofrat@osadl.org \
    --cc=kaber@trash.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=manfred@colorfullife.com \
    --cc=netfilter-devel@vger.kernel.org \
    --cc=oleg@redhat.com \
    --cc=pablo@netfilter.org \
    --cc=peterz@infradead.org \
    --cc=sasha.levin@oracle.com \
    --cc=tj@kernel.org \
    --cc=torvalds@linux-foundation.org \
    --cc=waiman.long@hpe.com \
    --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.