Re: [RFC] Bridging the gap between the Linux Kernel Memory Consistency Model (LKMM) and C11/C++11 atomics

2023-07-04 Thread Paul E. McKenney via Gcc
On Tue, Jul 04, 2023 at 04:25:45PM -0400, Alan Stern wrote: > On Tue, Jul 04, 2023 at 01:19:23PM -0400, Olivier Dion wrote: [ . . . ] > > I am puzzled by this. Initialization of a shared variable does not need > > to be atomic until its publication. Could you expand on this? > > In the kernel,

Re: Doubts regarding the _Dependent_ptr keyword

2019-07-04 Thread Paul E. McKenney
On Thu, Jul 04, 2019 at 01:00:18PM +0200, Richard Biener wrote: > On Wed, Jul 3, 2019 at 6:33 PM Paul E. McKenney wrote: > > > > On Wed, Jul 03, 2019 at 05:47:56PM +0200, Richard Biener wrote: > > > On July 3, 2019 5:14:58 PM GMT+02:00, "Paul E. McKenney" &

Re: Doubts regarding the _Dependent_ptr keyword

2019-07-03 Thread Paul E. McKenney
On Wed, Jul 03, 2019 at 05:47:56PM +0200, Richard Biener wrote: > On July 3, 2019 5:14:58 PM GMT+02:00, "Paul E. McKenney" > wrote: > >On Wed, Jul 03, 2019 at 12:39:41AM +0530, Akshat Garg wrote: > >> On Tue, Jul 2, 2019 at 8:40 PM Paul E. McKenney > > &g

Re: Doubts regarding the _Dependent_ptr keyword

2019-07-03 Thread Paul E. McKenney
On Wed, Jul 03, 2019 at 12:39:41AM +0530, Akshat Garg wrote: > On Tue, Jul 2, 2019 at 8:40 PM Paul E. McKenney > wrote: > > > On Tue, Jul 02, 2019 at 02:15:55PM +0100, Ramana Radhakrishnan wrote: > > > On Tue, Jul 2, 2019 at 1:38 PM Paul E. McKenney > > wrote: >

Re: Doubts regarding the _Dependent_ptr keyword

2019-07-03 Thread Paul E. McKenney
On Tue, Jul 02, 2019 at 07:53:20PM +0200, Richard Biener wrote: > On July 2, 2019 5:36:08 PM GMT+02:00, Jason Merrill wrote: > >On Mon, Jul 1, 2019 at 8:59 PM Paul E. McKenney > >wrote: > >> > >> On Tue, Jul 02, 2019 at 05:58:48AM +0530, Akshat Garg wrote: >

Re: Doubts regarding the _Dependent_ptr keyword

2019-07-02 Thread Paul E. McKenney
On Tue, Jul 02, 2019 at 02:15:55PM +0100, Ramana Radhakrishnan wrote: > On Tue, Jul 2, 2019 at 1:38 PM Paul E. McKenney wrote: > > > > > Once a user-created non-dependent pointer is assigned to, it is OK to > > break the dependency. > > Ok, that's good. >

Re: Doubts regarding the _Dependent_ptr keyword

2019-07-02 Thread Paul E. McKenney
On Tue, Jul 02, 2019 at 12:01:00PM +0100, Ramana Radhakrishnan wrote: > >> > >> It's worth figuring out what passes are doing this - however the worry > >> I have is that every pass now needs to be handling this case with > >> respect to pointer attributes. Is there some place that you are > >> sto

Re: Doubts regarding the _Dependent_ptr keyword

2019-07-01 Thread Paul E. McKenney
On Tue, Jul 02, 2019 at 05:58:48AM +0530, Akshat Garg wrote: > On Tue, Jun 25, 2019 at 9:49 PM Akshat Garg wrote: > > > On Tue, Jun 25, 2019 at 4:04 PM Ramana Radhakrishnan < > > ramana@googlemail.com> wrote: > > > >> On Tue, Jun 25, 2019 at 11:03 AM Akshat Garg wrote: > >> > > >> > As we ha

Re: Importance of transformations that turn data dependencies into control dependencies?

2016-03-01 Thread Paul E. McKenney
On Tue, Mar 01, 2016 at 05:55:07PM +0100, Michael Matz wrote: > Hi, > > On Tue, 1 Mar 2016, Richard Biener wrote: > > > > What about the example I gave above? Is it unrealistic for compilers > > > do ever do something like this, or is it just unlikely to gain much > > > performance, or is it j

Re: [isocpp-parallel] Proposal for new memory_order_consume definition

2016-02-29 Thread Paul E. McKenney
On Mon, Feb 29, 2016 at 07:17:55PM +0100, Michael Matz wrote: > Hi, > > On Sat, 27 Feb 2016, Paul E. McKenney wrote: > > > But we do already have something very similar with signed integer > > overflow. If the compiler can see a way to generate faster code that > >

Re: [isocpp-parallel] Proposal for new memory_order_consume definition

2016-02-27 Thread Paul E. McKenney
On Sat, Feb 27, 2016 at 11:16:51AM -0800, Linus Torvalds wrote: > On Feb 27, 2016 09:06, "Paul E. McKenney" > wrote: > > > > > > But we do already have something very similar with signed integer > > overflow. If the compiler can see a way to generate

Re: [isocpp-parallel] Proposal for new memory_order_consume definition

2016-02-27 Thread Paul E. McKenney
is to define a subset of operations where dependencies will be carried. Note that P0190R0 does call out comparisons as potentially unsafe. Thanx, Paul > On Sat, Feb 20, 2016 at 11:53 AM, Paul E. McKenney < > paul...@linux.vnet.ibm.com> wrote: > >

Re: Importance of transformations that turn data dependencies into control dependencies?

2016-02-26 Thread Paul E. McKenney
On Fri, Feb 26, 2016 at 11:49:29AM +0100, Richard Biener wrote: > On Thu, Feb 25, 2016 at 6:33 PM, Torvald Riegel wrote: > > On Wed, 2016-02-24 at 13:14 +0100, Richard Biener wrote: > >> On Tue, Feb 23, 2016 at 8:38 PM, Torvald Riegel wrote: > >> > I'd like to know, based on the GCC experience, h

Re: [isocpp-parallel] Proposal for new memory_order_consume definition

2016-02-20 Thread Paul E. McKenney
erry portable Babbage Device >   Original Message   > From: Paul E. McKenney > Sent: Thursday, February 18, 2016 4:58 AM > To: paral...@lists.isocpp.org; linux-ker...@vger.kernel.org; > linux-a...@vger.kernel.org; gcc@gcc.gnu.org; llvm-...@lists.llvm.org > Reply To: paral...@lists

Re: [c++std-parallel-2008] Re: Compilers and RCU readers: Once more unto the breach!

2015-09-23 Thread Paul E. McKenney
worried about exactly what sort of marking we use, but I am convinced that marking is required. So, given that we need to mark things, what sort of marking would work best from your perspective? Thanx, Paul > On Tue, Sep 22, 2015 at 10

Re: Compilers and RCU readers: Once more unto the breach!

2015-09-22 Thread Paul E. McKenney
On Mon, Jul 13, 2015 at 05:44:59PM -0700, Paul E. McKenney wrote: > On Tue, May 19, 2015 at 05:55:10PM -0700, Paul E. McKenney wrote: > > Hello! > > > > Following up on last year's discussion (https://lwn.net/Articles/586838/, > > https://lwn.net/Articles/58

Re: Compilers and RCU readers: Once more unto the breach!

2015-07-13 Thread Paul E. McKenney
On Tue, May 19, 2015 at 05:55:10PM -0700, Paul E. McKenney wrote: > Hello! > > Following up on last year's discussion (https://lwn.net/Articles/586838/, > https://lwn.net/Articles/588300/), I believe that we have a solution. If > I am wrong, I am sure you all will let m

Re: [c++std-parallel-1651] Re: Compilers and RCU readers: Once more unto the breach!

2015-05-26 Thread Paul E. McKenney
On Tue, May 26, 2015 at 07:08:35PM +0200, Torvald Riegel wrote: > On Tue, 2015-05-19 at 17:55 -0700, Paul E. McKenney wrote: > > http://www.rdrop.com/users/paulmck/RCU/consume.2015.05.18a.pdf > > I have been discussing Section 7.9 with Paul during last week. > > While I

Re: Compilers and RCU readers: Once more unto the breach!

2015-05-22 Thread Paul E. McKenney
On Fri, May 22, 2015 at 06:30:29PM +0100, Will Deacon wrote: > Hi Paul, > > On Thu, May 21, 2015 at 09:02:12PM +0100, Paul E. McKenney wrote: > > On Thu, May 21, 2015 at 08:24:22PM +0100, Will Deacon wrote: > > > On Wed, May 20, 2015 at 07:16:06PM +0100, Paul E. McKenney

Re: Compilers and RCU readers: Once more unto the breach!

2015-05-22 Thread Paul E. McKenney
On Fri, May 22, 2015 at 08:43:44AM +0200, Ingo Molnar wrote: > > * Linus Torvalds wrote: > > > (a) the "official" rules are completely pointless, and make sense > > only because the standard is written for some random "abstract > > machine" that doesn't actually exist. > > Presuming the inte

Re: Compilers and RCU readers: Once more unto the breach!

2015-05-22 Thread Paul E. McKenney
On Fri, May 22, 2015 at 06:43:32AM -0400, Richard Kenner wrote: > > (Assuming it's a goal of this standard to be human parseable to more > > than a few dozen people on the planet.) > > Unfortunately, that's rarely a goal of most standards. ;-) My experience does match Richard's, sad to say. The

Re: Compilers and RCU readers: Once more unto the breach!

2015-05-21 Thread Paul E. McKenney
On Thu, May 21, 2015 at 01:42:11PM -0700, Linus Torvalds wrote: > On Thu, May 21, 2015 at 1:02 PM, Paul E. McKenney > wrote: > > > > The compiler can (and does) speculate non-atomic non-volatile writes > > in some cases, but I do not believe that it is permitted to specu

Re: Compilers and RCU readers: Once more unto the breach!

2015-05-21 Thread Paul E. McKenney
On Thu, May 21, 2015 at 08:24:22PM +0100, Will Deacon wrote: > On Wed, May 20, 2015 at 07:16:06PM +0100, Paul E. McKenney wrote: > > On Wed, May 20, 2015 at 04:46:17PM +0100, Will Deacon wrote: > > > On Wed, May 20, 2015 at 01:15:22PM +0100, Paul E. McKenney wrote: > > &g

Re: [c++std-parallel-1632] Re: Compilers and RCU readers: Once more unto the breach!

2015-05-21 Thread Paul E. McKenney
On Thu, May 21, 2015 at 06:17:43PM +0200, Michael Matz wrote: > Hi, > > On Thu, 21 May 2015, Paul E. McKenney wrote: > > > The point is -exactly- to codify the current state of affairs. > > Ah, I see, so it's not yet about creating a more useful (for compilers,

Re: [c++std-parallel-1632] Re: Compilers and RCU readers: Once more unto the breach!

2015-05-21 Thread Paul E. McKenney
On Thu, May 21, 2015 at 04:22:38PM +0200, Michael Matz wrote: > Hi, > > On Wed, 20 May 2015, Paul E. McKenney wrote: > > > > > I'm not sure... you'd require the compiler to perform static analysis of > > > > loops to determine the state of the

Re: [c++std-parallel-1632] Re: Compilers and RCU readers: Once more unto the breach!

2015-05-20 Thread Paul E. McKenney
On Wed, May 20, 2015 at 04:54:51PM +0100, Andrew Haley wrote: > On 05/20/2015 04:46 PM, Will Deacon wrote: > > I'm not sure... you'd require the compiler to perform static analysis of > > loops to determine the state of the machine when they exit (if they exit!) > > in order to show whether or not

Re: Compilers and RCU readers: Once more unto the breach!

2015-05-20 Thread Paul E. McKenney
On Wed, May 20, 2015 at 04:46:17PM +0100, Will Deacon wrote: > On Wed, May 20, 2015 at 01:15:22PM +0100, Paul E. McKenney wrote: > > On Wed, May 20, 2015 at 12:47:45PM +0100, Will Deacon wrote: > > > On Wed, May 20, 2015 at 03:41:48AM +0100, Paul E. McKenney wrote: > > >

Re: Compilers and RCU readers: Once more unto the breach!

2015-05-20 Thread Paul E. McKenney
On Wed, May 20, 2015 at 03:15:48PM +0100, Ramana Radhakrishnan wrote: > > > On 20/05/15 15:03, Paul E. McKenney wrote: > >On Wed, May 20, 2015 at 02:44:30PM +0100, Ramana Radhakrishnan wrote: > >> > >> > >>On 20/05/15 14:37, David Howells wrote: >

Re: Compilers and RCU readers: Once more unto the breach!

2015-05-20 Thread Paul E. McKenney
On Wed, May 20, 2015 at 02:44:30PM +0100, Ramana Radhakrishnan wrote: > > > On 20/05/15 14:37, David Howells wrote: > >Paul E. McKenney wrote: > > > >>I was thinking of "y" as a simple variable, but if it is something more > >>complex, then the

Re: [c++std-parallel-1624] Re: Compilers and RCU readers: Once more unto the breach!

2015-05-20 Thread Paul E. McKenney
On Wed, May 20, 2015 at 02:37:05PM +0100, David Howells wrote: > Paul E. McKenney wrote: > > > I was thinking of "y" as a simple variable, but if it is something more > > complex, then the compiler could do this, right? > > > > char *x; > > &

Re: Compilers and RCU readers: Once more unto the breach!

2015-05-20 Thread Paul E. McKenney
On Wed, May 20, 2015 at 02:18:37PM +0100, David Howells wrote: > Paul E. McKenney wrote: > > > > Additionally, what about the following code? > > > > > > char *x = y ? z : z; > > > > > > Does that extend a dependency chain from z to x

Re: Compilers and RCU readers: Once more unto the breach!

2015-05-20 Thread Paul E. McKenney
On Wed, May 20, 2015 at 12:47:45PM +0100, Will Deacon wrote: > Hi Paul, > > On Wed, May 20, 2015 at 03:41:48AM +0100, Paul E. McKenney wrote: > > On Tue, May 19, 2015 at 07:10:12PM -0700, Linus Torvalds wrote: > > > On Tue, May 19, 2015 at 6:57 PM, Linus Torvalds > &

Re: [c++std-parallel-1614] Re: Compilers and RCU readers: Once more unto the breach!

2015-05-20 Thread Paul E. McKenney
On Wed, May 20, 2015 at 11:03:00AM +0200, Richard Biener wrote: > On Wed, May 20, 2015 at 9:34 AM, Jens Maurer wrote: > > On 05/20/2015 04:34 AM, Paul E. McKenney wrote: > >> On Tue, May 19, 2015 at 06:57:02PM -0700, Linus Torvalds wrote: > > > >>> - the &

Re: [c++std-parallel-1616] Re: Compilers and RCU readers: Once more unto the breach!

2015-05-20 Thread Paul E. McKenney
On Wed, May 20, 2015 at 09:34:10AM +0200, Jens Maurer wrote: > On 05/20/2015 04:34 AM, Paul E. McKenney wrote: > > On Tue, May 19, 2015 at 06:57:02PM -0700, Linus Torvalds wrote: > > >> - the "you can add/subtract integral values" still opens you up to > >>

Re: Compilers and RCU readers: Once more unto the breach!

2015-05-19 Thread Paul E. McKenney
On Tue, May 19, 2015 at 07:10:12PM -0700, Linus Torvalds wrote: > On Tue, May 19, 2015 at 6:57 PM, Linus Torvalds > wrote: > > > > - the "you can add/subtract integral values" still opens you up to > > language lawyers claiming "(char *)ptr - (intptr_t)ptr" preserving the > > dependency, which it

Re: Compilers and RCU readers: Once more unto the breach!

2015-05-19 Thread Paul E. McKenney
On Tue, May 19, 2015 at 06:57:02PM -0700, Linus Torvalds wrote: > On Tue, May 19, 2015 at 5:55 PM, Paul E. McKenney > wrote: > > > > http://www.rdrop.com/users/paulmck/RCU/consume.2015.05.18a.pdf > > >From a very quick read-through, the restricted dependency

Compilers and RCU readers: Once more unto the breach!

2015-05-19 Thread Paul E. McKenney
Hello! Following up on last year's discussion (https://lwn.net/Articles/586838/, https://lwn.net/Articles/588300/), I believe that we have a solution. If I am wrong, I am sure you all will let me know, and in great detail. ;-) The key simplification is to "just say no" to RCU-protected array in

Re: [RFC][PATCH 0/5] arch: atomic rework

2014-03-07 Thread Paul E. McKenney
On Fri, Mar 07, 2014 at 07:33:25PM +0100, Torvald Riegel wrote: > On Wed, 2014-03-05 at 10:15 -0800, Paul E. McKenney wrote: > > On Wed, Mar 05, 2014 at 05:54:59PM +0100, Torvald Riegel wrote: > > > On Tue, 2014-03-04 at 13:35 -0800, Paul E. McKenney wrote: > > > >

Re: [RFC][PATCH 0/5] arch: atomic rework

2014-03-07 Thread Paul E. McKenney
On Fri, Mar 07, 2014 at 06:45:57PM +0100, Torvald Riegel wrote: > xagsmtp5.20140307174618.3...@vmsdvm6.vnet.ibm.com > X-Xagent-Gateway: vmsdvm6.vnet.ibm.com (XAGSMTP5 at VMSDVM6) > > On Wed, 2014-03-05 at 10:01 -0800, Paul E. McKenney wrote: > > On Wed, Mar 05, 2014 at 05:26:3

Re: [RFC][PATCH 0/5] arch: atomic rework

2014-03-05 Thread Paul E. McKenney
On Wed, Mar 05, 2014 at 05:54:59PM +0100, Torvald Riegel wrote: > On Tue, 2014-03-04 at 13:35 -0800, Paul E. McKenney wrote: > > On Tue, Mar 04, 2014 at 11:00:32AM -0800, Paul E. McKenney wrote: > > > On Mon, Mar 03, 2014 at 09:46:19PM +0100, Torvald Riegel wrote: > > >

Re: [RFC][PATCH 0/5] arch: atomic rework

2014-03-05 Thread Paul E. McKenney
On Wed, Mar 05, 2014 at 05:26:36PM +0100, Torvald Riegel wrote: > xagsmtp3.20140305162928.8...@uk1vsc.vnet.ibm.com > X-Xagent-Gateway: uk1vsc.vnet.ibm.com (XAGSMTP3 at UK1VSC) > > On Tue, 2014-03-04 at 11:00 -0800, Paul E. McKenney wrote: > > On Mon, Mar 03, 2014 at 09:46:1

Re: [RFC][PATCH 0/5] arch: atomic rework

2014-03-04 Thread Paul E. McKenney
On Tue, Mar 04, 2014 at 11:00:32AM -0800, Paul E. McKenney wrote: > On Mon, Mar 03, 2014 at 09:46:19PM +0100, Torvald Riegel wrote: > > xagsmtp2.20140303204700.3...@vmsdvma.vnet.ibm.com > > X-Xagent-Gateway: vmsdvma.vnet.ibm.com (XAGSMTP2 at VMSDVMA) > > > > On Mon

Re: [RFC][PATCH 0/5] arch: atomic rework

2014-03-04 Thread Paul E. McKenney
On Mon, Mar 03, 2014 at 09:46:19PM +0100, Torvald Riegel wrote: > xagsmtp2.20140303204700.3...@vmsdvma.vnet.ibm.com > X-Xagent-Gateway: vmsdvma.vnet.ibm.com (XAGSMTP2 at VMSDVMA) > > On Mon, 2014-03-03 at 11:20 -0800, Paul E. McKenney wrote: > > On Mon, Mar 03, 2014 at 07:55:0

Re: [RFC][PATCH 0/5] arch: atomic rework

2014-03-03 Thread Paul E. McKenney
On Mon, Mar 03, 2014 at 07:55:08PM +0100, Torvald Riegel wrote: > xagsmtp2.20140303190831.9...@uk1vsc.vnet.ibm.com > X-Xagent-Gateway: uk1vsc.vnet.ibm.com (XAGSMTP2 at UK1VSC) > > On Fri, 2014-02-28 at 16:50 -0800, Paul E. McKenney wrote: > > +o Do not use the results from th

Re: [RFC][PATCH 0/5] arch: atomic rework

2014-03-02 Thread Paul E. McKenney
On Sun, Mar 02, 2014 at 11:44:52PM +, Peter Sewell wrote: > On 2 March 2014 23:20, Paul E. McKenney wrote: > > On Sun, Mar 02, 2014 at 04:05:52AM -0600, Peter Sewell wrote: > >> On 1 March 2014 08:03, Paul E. McKenney wrote: > >> > On Sat, Mar 01, 2014 at 04:06:

Re: [RFC][PATCH 0/5] arch: atomic rework

2014-03-02 Thread Paul E. McKenney
On Sun, Mar 02, 2014 at 04:05:52AM -0600, Peter Sewell wrote: > On 1 March 2014 08:03, Paul E. McKenney wrote: > > On Sat, Mar 01, 2014 at 04:06:34AM -0600, Peter Sewell wrote: > >> Hi Paul, > >> > >> On 28 February 2014 18:50, Paul E. McKenney > >>

Re: [RFC][PATCH 0/5] arch: atomic rework

2014-03-01 Thread Paul E. McKenney
On Sat, Mar 01, 2014 at 04:06:34AM -0600, Peter Sewell wrote: > Hi Paul, > > On 28 February 2014 18:50, Paul E. McKenney > wrote: > > On Thu, Feb 27, 2014 at 12:53:12PM -0800, Paul E. McKenney wrote: > >> On Thu, Feb 27, 2014 at 11:47:08AM -0800, Linus Torvalds w

Re: [RFC][PATCH 0/5] arch: atomic rework

2014-02-28 Thread Paul E. McKenney
On Thu, Feb 27, 2014 at 12:53:12PM -0800, Paul E. McKenney wrote: > On Thu, Feb 27, 2014 at 11:47:08AM -0800, Linus Torvalds wrote: > > On Thu, Feb 27, 2014 at 11:06 AM, Paul E. McKenney > > wrote: > > > > > > 3. The comparison was against another RCU-prote

Re: [RFC][PATCH 0/5] arch: atomic rework

2014-02-27 Thread Paul E. McKenney
On Thu, Feb 27, 2014 at 09:50:21AM -0800, Paul E. McKenney wrote: > On Thu, Feb 27, 2014 at 04:37:33PM +0100, Torvald Riegel wrote: > > xagsmtp2.20140227154925.3...@vmsdvm9.vnet.ibm.com > > > > On Mon, 2014-02-24 at 11:54 -0800, Linus Torvalds wrote: > > > On Mon, Fe

Re: [RFC][PATCH 0/5] arch: atomic rework

2014-02-27 Thread Paul E. McKenney
On Thu, Feb 27, 2014 at 11:47:08AM -0800, Linus Torvalds wrote: > On Thu, Feb 27, 2014 at 11:06 AM, Paul E. McKenney > wrote: > > > > 3. The comparison was against another RCU-protected pointer, > > where that other pointer was properly fetched using on

Re: [RFC][PATCH 0/5] arch: atomic rework

2014-02-27 Thread Paul E. McKenney
On Thu, Feb 27, 2014 at 09:50:21AM -0800, Paul E. McKenney wrote: > On Thu, Feb 27, 2014 at 04:37:33PM +0100, Torvald Riegel wrote: > > xagsmtp2.20140227154925.3...@vmsdvm9.vnet.ibm.com > > > > On Mon, 2014-02-24 at 11:54 -0800, Linus Torvalds wrote: > > > On Mon, Fe

Re: [RFC][PATCH 0/5] arch: atomic rework

2014-02-27 Thread Paul E. McKenney
On Thu, Feb 27, 2014 at 09:01:40AM -0800, Linus Torvalds wrote: > On Thu, Feb 27, 2014 at 7:37 AM, Torvald Riegel wrote: > > > > I agree that just considering syntactic properties of the program seems > > to be insufficient. Making it instead depend on whether there is a > > "semantic" dependency

Re: [RFC][PATCH 0/5] arch: atomic rework

2014-02-27 Thread Paul E. McKenney
On Thu, Feb 27, 2014 at 04:37:33PM +0100, Torvald Riegel wrote: > xagsmtp2.20140227154925.3...@vmsdvm9.vnet.ibm.com > > On Mon, 2014-02-24 at 11:54 -0800, Linus Torvalds wrote: > > On Mon, Feb 24, 2014 at 10:53 AM, Paul E. McKenney > > wrote: > > > > > >

Re: [RFC][PATCH 0/5] arch: atomic rework

2014-02-26 Thread Paul E. McKenney
On Wed, Feb 26, 2014 at 02:04:30PM +0100, Torvald Riegel wrote: > xagsmtp2.20140226130517.3...@vmsdvma.vnet.ibm.com > X-Xagent-Gateway: vmsdvma.vnet.ibm.com (XAGSMTP2 at VMSDVMA) > > On Fri, 2014-02-21 at 11:13 -0800, Paul E. McKenney wrote: > > On Fri, Feb 21, 2014 at 07:35:3

Re: [RFC][PATCH 0/5] arch: atomic rework

2014-02-25 Thread Paul E. McKenney
On Tue, Feb 25, 2014 at 10:06:53PM -0500, George Spelvin wrote: > wrote: > > wrote: > >> I have for the last several years been 100% convinced that the Intel > >> memory ordering is the right thing, and that people who like weak > >> memory ordering are wrong and should try to avoid reproducing i

Re: [RFC][PATCH 0/5] arch: atomic rework

2014-02-25 Thread Paul E. McKenney
On Tue, Feb 25, 2014 at 08:32:38PM -0700, Jeff Law wrote: > On 02/25/14 17:15, Paul E. McKenney wrote: > >>I have for the last several years been 100% convinced that the Intel > >>memory ordering is the right thing, and that people who like weak > >>memory orderi

Re: [RFC][PATCH 0/5] arch: atomic rework

2014-02-25 Thread Paul E. McKenney
On Tue, Feb 25, 2014 at 05:47:03PM -0800, Linus Torvalds wrote: > On Mon, Feb 24, 2014 at 10:00 PM, Paul E. McKenney > wrote: > > > > So let me see if I understand your reasoning. My best guess is that it > > goes something like this: > > > > 1. The Li

Re: [RFC][PATCH 0/5] arch: atomic rework

2014-02-25 Thread Paul E. McKenney
On Mon, Feb 24, 2014 at 10:05:52PM -0800, Linus Torvalds wrote: > On Mon, Feb 24, 2014 at 3:35 PM, Linus Torvalds > wrote: > > > > Litmus test 1: > > > > p = atomic_read(pp, consume); > > if (p == &variable) > > return p->val; > > > >is *NOT* ordered > > Btw, don't get me wron

Re: [RFC][PATCH 0/5] arch: atomic rework

2014-02-24 Thread Paul E. McKenney
On Mon, Feb 24, 2014 at 03:35:04PM -0800, Linus Torvalds wrote: > On Mon, Feb 24, 2014 at 2:37 PM, Paul E. McKenney > wrote: > >> > >> What if the "nothing modifies 'p'" part looks like this: > >> > >> if (p != &myvariable) >

Re: [RFC][PATCH 0/5] arch: atomic rework

2014-02-24 Thread Paul E. McKenney
On Mon, Feb 24, 2014 at 11:54:46AM -0800, Linus Torvalds wrote: > On Mon, Feb 24, 2014 at 10:53 AM, Paul E. McKenney > wrote: > > > > Good points. How about the following replacements? > > > > 3. Adding or subtracting an integer to/from a chained pointer

Re: [RFC][PATCH 0/5] arch: atomic rework

2014-02-24 Thread Paul E. McKenney
On Mon, Feb 24, 2014 at 10:14:01AM -0800, Linus Torvalds wrote: > On Mon, Feb 24, 2014 at 9:21 AM, Paul E. McKenney > wrote: > > > > 4. Bitwise operators ("&", "|", "^", and I suppose also "~") > > applied to a c

Re: [RFC][PATCH 0/5] arch: atomic rework

2014-02-24 Thread Paul E. McKenney
On Mon, Feb 24, 2014 at 09:38:46AM -0800, Linus Torvalds wrote: > On Mon, Feb 24, 2014 at 8:55 AM, Michael Matz wrote: > > > > So, let me try to poke holes into your definition or increase my > > understanding :) . You said "chain of pointers"(dereferences I assume), > > e.g. if p is result of co

Re: [RFC][PATCH 0/5] arch: atomic rework

2014-02-24 Thread Paul E. McKenney
On Mon, Feb 24, 2014 at 09:28:56AM -0800, Paul E. McKenney wrote: > On Mon, Feb 24, 2014 at 05:55:50PM +0100, Michael Matz wrote: > > Hi, > > > > On Mon, 24 Feb 2014, Linus Torvalds wrote: > > > > > > To me that reads like > > > > > > &

Re: [RFC][PATCH 0/5] arch: atomic rework

2014-02-24 Thread Paul E. McKenney
On Mon, Feb 24, 2014 at 02:55:07PM +0100, Michael Matz wrote: > Hi, > > On Fri, 21 Feb 2014, Paul E. McKenney wrote: > > > > And with conservative I mean "everything is a source of a dependency, and > > > hence can't be removed, reordered or otherwise

Re: [RFC][PATCH 0/5] arch: atomic rework

2014-02-24 Thread Paul E. McKenney
On Mon, Feb 24, 2014 at 05:55:50PM +0100, Michael Matz wrote: > Hi, > > On Mon, 24 Feb 2014, Linus Torvalds wrote: > > > > To me that reads like > > > > > > int i; > > > int *q = &i; > > > int **p = &q; > > > > > > atomic_XXX (p, CONSUME); > > > > > > orders against accesses '*p', '**p',

Re: [RFC][PATCH 0/5] arch: atomic rework

2014-02-24 Thread Paul E. McKenney
On Mon, Feb 24, 2014 at 07:57:24AM -0800, Linus Torvalds wrote: > On Sun, Feb 23, 2014 at 11:31 AM, Linus Torvalds > wrote: > > > > Let me think about it some more, but my gut feel is that just tweaking > > the definition of what "ordered" means is sufficient. > > > > So to go back to the suggeste

Re: [RFC][PATCH 0/5] arch: atomic rework

2014-02-23 Thread Paul E. McKenney
On Sun, Feb 23, 2014 at 05:35:28PM -0800, Linus Torvalds wrote: > On Sun, Feb 23, 2014 at 5:16 PM, Paul E. McKenney > wrote: > >> > >> (a) we've said 'q' is restricted, so there is no aliasing between q > >> and the pointers b/c. So the compiler i

Re: [RFC][PATCH 0/5] arch: atomic rework

2014-02-23 Thread Paul E. McKenney
On Sun, Feb 23, 2014 at 11:31:25AM -0800, Linus Torvalds wrote: > On Sat, Feb 22, 2014 at 10:34 PM, Paul E. McKenney > wrote: > > > > Adding and subtracting integers to/from a RCU-protected pointer makes > > sense to me. > > Ack. And that's normal "ac

Re: [RFC][PATCH 0/5] arch: atomic rework

2014-02-23 Thread Paul E. McKenney
On Sat, Feb 22, 2014 at 07:50:35PM -0800, Linus Torvalds wrote: > On Sat, Feb 22, 2014 at 4:39 PM, Paul E. McKenney > wrote: > > > > Agreed, by far the most frequent use is "->" to dereference and assignment > > to store into a local variable. The other op

Re: [RFC][PATCH 0/5] arch: atomic rework

2014-02-22 Thread Paul E. McKenney
On Sat, Feb 22, 2014 at 01:53:30PM -0800, Linus Torvalds wrote: > On Sat, Feb 22, 2014 at 10:53 AM, Torvald Riegel wrote: > > > > Stating that (1) "the standard is wrong" and (2) that you think that > > mo_consume semantics are not good is two different things. > > I do agree. They are two indepe

Re: [RFC][PATCH 0/5] arch: atomic rework

2014-02-22 Thread Paul E. McKenney
On Sat, Feb 22, 2014 at 07:30:37PM +0100, Torvald Riegel wrote: > xagsmtp2.20140222183231.5...@emeavsc.vnet.ibm.com > X-Xagent-Gateway: emeavsc.vnet.ibm.com (XAGSMTP2 at EMEAVSC) > > On Thu, 2014-02-20 at 10:18 -0800, Paul E. McKenney wrote: > > On Thu, Feb 20, 2014 at 06:26:0

Re: [RFC][PATCH 0/5] arch: atomic rework

2014-02-21 Thread Paul E. McKenney
On Fri, Feb 21, 2014 at 10:10:54PM +, Joseph S. Myers wrote: > On Fri, 21 Feb 2014, Paul E. McKenney wrote: > > > This needs to be as follows: > > > > [[carries_dependency]] int getzero(int i [[carries_dependency]]) > > { > > return i - i; > > }

Re: [RFC][PATCH 0/5] arch: atomic rework

2014-02-21 Thread Paul E. McKenney
On Fri, Feb 21, 2014 at 06:28:05PM +, Peter Sewell wrote: > On 20 February 2014 17:01, Linus Torvalds >wrote: [ . . . ] > > > So, if you make one of two changes to your example, then I will agree > > > with you. > > > > No. We're not playing games here. I'm fed up with complex examples > > t

Re: [RFC][PATCH 0/5] arch: atomic rework

2014-02-21 Thread Paul E. McKenney
On Fri, Feb 21, 2014 at 07:35:37PM +0100, Michael Matz wrote: > Hi, > > On Thu, 20 Feb 2014, Linus Torvalds wrote: > > > But I'm pretty sure that any compiler guy must *hate* that current odd > > dependency-generation part, and if I was a gcc person, seeing that > > bugzilla entry Torvald pointed

Re: [RFC][PATCH 0/5] arch: atomic rework

2014-02-20 Thread Paul E. McKenney
On Thu, Feb 20, 2014 at 11:45:29AM -0800, Linus Torvalds wrote: > On Thu, Feb 20, 2014 at 10:56 AM, Paul E. McKenney > wrote: > > > > The example gcc breakage was something like this: > > > > i = atomic_load(idx, memory_order_consume); > > x

Re: [RFC][PATCH 0/5] arch: atomic rework

2014-02-20 Thread Paul E. McKenney
On Thu, Feb 20, 2014 at 07:44:32PM +0100, Torvald Riegel wrote: > xagsmtp3.20140220184514.1...@bldgate.vnet.ibm.com > X-Xagent-Gateway: bldgate.vnet.ibm.com (XAGSMTP3 at BLDGATE) > > On Thu, 2014-02-20 at 10:11 -0800, Paul E. McKenney wrote: > > But yes, the compiler guys would

Re: [RFC][PATCH 0/5] arch: atomic rework

2014-02-20 Thread Paul E. McKenney
On Thu, Feb 20, 2014 at 10:32:51AM -0800, Linus Torvalds wrote: > On Thu, Feb 20, 2014 at 10:11 AM, Paul E. McKenney > wrote: > > > > You really need that "consume" to be "acquire". > > So I think we now all agree that that is what the standard is sa

Re: [RFC][PATCH 0/5] arch: atomic rework

2014-02-20 Thread Paul E. McKenney
On Thu, Feb 20, 2014 at 09:34:57AM -0800, Linus Torvalds wrote: > On Thu, Feb 20, 2014 at 9:14 AM, Torvald Riegel wrote: > >> > >> So the clarification is basically to the statement that the "if > >> (consume(p)) a" version *would* have an ordering guarantee between the > >> read of "p" and "a", b

Re: [RFC][PATCH 0/5] arch: atomic rework

2014-02-20 Thread Paul E. McKenney
On Thu, Feb 20, 2014 at 06:54:06PM +0100, Torvald Riegel wrote: > xagsmtp4.20140220175519.1...@vmsdvm6.vnet.ibm.com > X-Xagent-Gateway: vmsdvm6.vnet.ibm.com (XAGSMTP4 at VMSDVM6) > > On Thu, 2014-02-20 at 00:30 -0800, Paul E. McKenney wrote: > > Well, all the compilers current

Re: [RFC][PATCH 0/5] arch: atomic rework

2014-02-20 Thread Paul E. McKenney
On Thu, Feb 20, 2014 at 06:26:08PM +0100, Torvald Riegel wrote: > xagsmtp2.20140220172700.0...@vmsdvm4.vnet.ibm.com > X-Xagent-Gateway: vmsdvm4.vnet.ibm.com (XAGSMTP2 at VMSDVM4) > > On Wed, 2014-02-19 at 20:01 -0800, Paul E. McKenney wrote: > > On Wed, Feb 19, 2014 at 04:53

Re: [RFC][PATCH 0/5] arch: atomic rework

2014-02-20 Thread Paul E. McKenney
On Thu, Feb 20, 2014 at 09:01:06AM -0800, Linus Torvalds wrote: > On Thu, Feb 20, 2014 at 12:30 AM, Paul E. McKenney > wrote: > >> > >> So lets make this really simple: if you have a consume->cmp->read, is > >> the ordering of the two reads guaranteed? >

Re: [RFC][PATCH 0/5] arch: atomic rework

2014-02-20 Thread Paul E. McKenney
On Thu, Feb 20, 2014 at 12:30:32AM -0800, Paul E. McKenney wrote: > On Wed, Feb 19, 2014 at 08:43:14PM -0800, Linus Torvalds wrote: [ . . . ] > So, if you make one of two changes to your example, then I will agree > with you. The first change is to have a real data dependency between &

Re: [RFC][PATCH 0/5] arch: atomic rework

2014-02-20 Thread Paul E. McKenney
On Wed, Feb 19, 2014 at 08:43:14PM -0800, Linus Torvalds wrote: > On Wed, Feb 19, 2014 at 8:01 PM, Paul E. McKenney > wrote: > > > > The control dependency should order subsequent stores, at least assuming > > that "a" and "b" don't start off with

Re: [RFC][PATCH 0/5] arch: atomic rework

2014-02-19 Thread Paul E. McKenney
On Wed, Feb 19, 2014 at 04:53:49PM -0800, Linus Torvalds wrote: > On Tue, Feb 18, 2014 at 11:47 AM, Torvald Riegel wrote: > > On Tue, 2014-02-18 at 09:44 -0800, Linus Torvalds wrote: > >> > >> Can you point to it? Because I can find a draft standard, and it sure > >> as hell does *not* contain any

Re: [RFC][PATCH 0/5] arch: atomic rework

2014-02-19 Thread Paul E. McKenney
On Wed, Feb 19, 2014 at 06:55:51PM +0100, Torvald Riegel wrote: > On Wed, 2014-02-19 at 07:14 -0800, Paul E. McKenney wrote: > > On Wed, Feb 19, 2014 at 11:59:08AM +0100, Torvald Riegel wrote: [ . . . ] > > > On both sides, the compiler will see that mmap() (or similar) is cal

Re: [RFC][PATCH 0/5] arch: atomic rework

2014-02-19 Thread Paul E. McKenney
On Wed, Feb 19, 2014 at 11:59:08AM +0100, Torvald Riegel wrote: > On Tue, 2014-02-18 at 14:58 -0800, Paul E. McKenney wrote: > > On Tue, Feb 18, 2014 at 10:40:15PM +0100, Torvald Riegel wrote: > > > xagsmtp4.20140218214207.8...@vmsdvm9.vnet.ibm.com > > > X-Xagent-Ga

Re: [RFC][PATCH 0/5] arch: atomic rework

2014-02-18 Thread Paul E. McKenney
On Tue, Feb 18, 2014 at 10:40:15PM +0100, Torvald Riegel wrote: > xagsmtp4.20140218214207.8...@vmsdvm9.vnet.ibm.com > X-Xagent-Gateway: vmsdvm9.vnet.ibm.com (XAGSMTP4 at VMSDVM9) > > On Tue, 2014-02-18 at 09:16 -0800, Paul E. McKenney wrote: > > On Tue, Feb 18, 2014 at 08:49

Re: [RFC][PATCH 0/5] arch: atomic rework

2014-02-18 Thread Paul E. McKenney
On Tue, Feb 18, 2014 at 09:43:31PM +0100, Torvald Riegel wrote: > xagsmtp5.20140218204423.3...@bldgate.vnet.ibm.com > X-Xagent-Gateway: bldgate.vnet.ibm.com (XAGSMTP5 at BLDGATE) > > On Tue, 2014-02-18 at 12:12 +, Peter Sewell wrote: > > Several of you have said that the standard and compiler

Re: [RFC][PATCH 0/5] arch: atomic rework

2014-02-18 Thread Paul E. McKenney
On Tue, Feb 18, 2014 at 10:49:27AM -0800, Linus Torvalds wrote: > On Tue, Feb 18, 2014 at 10:21 AM, Peter Sewell > wrote: > > > > This is a bit more subtle, because (on ARM and POWER) removing the > > dependency and conditional branch is actually in general *not* equivalent > > in the hardware, in

Re: [RFC][PATCH 0/5] arch: atomic rework

2014-02-18 Thread Paul E. McKenney
On Tue, Feb 18, 2014 at 06:23:47PM +, Peter Sewell wrote: > On 18 February 2014 17:16, Paul E. McKenney > wrote: > > On Tue, Feb 18, 2014 at 08:49:13AM -0800, Linus Torvalds wrote: > >> On Tue, Feb 18, 2014 at 7:31 AM, Torvald Riegel wrote: > >> > On Mon,

Re: [RFC][PATCH 0/5] arch: atomic rework

2014-02-18 Thread Paul E. McKenney
On Tue, Feb 18, 2014 at 09:44:48AM -0800, Linus Torvalds wrote: > On Tue, Feb 18, 2014 at 8:17 AM, Torvald Riegel wrote: [ . . . ] > > The standard is clear on what's required. I strongly suggest reading > > the formalization of the memory model by Batty et al. > > Can you point to it? Because

Re: [RFC][PATCH 0/5] arch: atomic rework

2014-02-18 Thread Paul E. McKenney
On Tue, Feb 18, 2014 at 03:16:33PM +, Mark Batty wrote: > Hi Paul, > > Thanks for the document. I'm looking forward to reading the bits about > dependency chains in Linux. And I am looking forward to your thoughts on those bits! > > One point of confusion for me... Example 4 says "language

Re: [RFC][PATCH 0/5] arch: atomic rework

2014-02-18 Thread Paul E. McKenney
On Tue, Feb 18, 2014 at 08:49:13AM -0800, Linus Torvalds wrote: > On Tue, Feb 18, 2014 at 7:31 AM, Torvald Riegel wrote: > > On Mon, 2014-02-17 at 16:05 -0800, Linus Torvalds wrote: > >> And exactly because I know enough, I would *really* like atomics to be > >> well-defined, and have very clear -

Re: [RFC][PATCH 0/5] arch: atomic rework

2014-02-18 Thread Paul E. McKenney
On Tue, Feb 18, 2014 at 04:38:40PM +0100, Torvald Riegel wrote: > On Mon, 2014-02-17 at 16:18 -0800, Linus Torvalds wrote: > > On Mon, Feb 17, 2014 at 3:41 PM, Torvald Riegel wrote: > > > > > > There's an underlying problem here that's independent from the actual > > > instance that you're worried

Re: [RFC][PATCH 0/5] arch: atomic rework

2014-02-18 Thread Paul E. McKenney
On Tue, Feb 18, 2014 at 04:56:40PM +0100, Torvald Riegel wrote: > On Mon, 2014-02-17 at 19:00 -0800, Paul E. McKenney wrote: > > On Mon, Feb 17, 2014 at 12:18:21PM -0800, Linus Torvalds wrote: > > > On Mon, Feb 17, 2014 at 11:55 AM, Torvald Riegel > > > wrote: >

Re: [RFC][PATCH 0/5] arch: atomic rework

2014-02-18 Thread Paul E. McKenney
On Tue, Feb 18, 2014 at 03:33:35PM +, Peter Sewell wrote: > Hi Paul, > > On 18 February 2014 14:56, Paul E. McKenney > wrote: > > On Tue, Feb 18, 2014 at 12:12:06PM +, Peter Sewell wrote: > >> Several of you have said that the standard and compiler should

Re: [RFC][PATCH 0/5] arch: atomic rework

2014-02-18 Thread Paul E. McKenney
On Tue, Feb 18, 2014 at 12:12:06PM +, Peter Sewell wrote: > Several of you have said that the standard and compiler should not > permit speculative writes of atomics, or (effectively) that the > compiler should preserve dependencies. In simple examples it's easy > to see what that means, but i

Re: [RFC][PATCH 0/5] arch: atomic rework

2014-02-17 Thread Paul E. McKenney
On Mon, Feb 17, 2014 at 07:42:42PM -0800, Linus Torvalds wrote: > On Mon, Feb 17, 2014 at 7:24 PM, Linus Torvalds > wrote: > > > > As far as I can tell, the intent is that you can't do value > > speculation (except perhaps for the "relaxed", which quite frankly > > sounds largely useless). > > Hm

Re: [RFC][PATCH 0/5] arch: atomic rework

2014-02-17 Thread Paul E. McKenney
On Mon, Feb 17, 2014 at 07:24:56PM -0800, Linus Torvalds wrote: > On Mon, Feb 17, 2014 at 7:00 PM, Paul E. McKenney > wrote: > > > > One example that I learned about last week uses the branch-prediction > > hardware to validate value speculation. And no, I am not a

Re: [RFC][PATCH 0/5] arch: atomic rework

2014-02-17 Thread Paul E. McKenney
On Mon, Feb 17, 2014 at 12:18:21PM -0800, Linus Torvalds wrote: > On Mon, Feb 17, 2014 at 11:55 AM, Torvald Riegel wrote: > > > > Which example do you have in mind here? Haven't we resolved all the > > debated examples, or did I miss any? > > Well, Paul seems to still think that the standard pos

  1   2   >