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

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

Re: [PATCH] Adding _Dependent_ptr type qualifier in C part 1/3

On Sun, Aug 04, 2019 at 04:11:12PM -0700, Paul E. McKenney wrote: > Good points! > > On the type-qualifier interactions, here is an initial list. Thoughts? > > Thanx, Paul > > _Alignas: Dependency-breaking optimizat

Re: [PATCH] Adding _Dependent_ptr type qualifier in C part 1/3

Good points! On the type-qualifier interactions, here is an initial list. Thoughts? Thanx, Paul _Alignas: Dependency-breaking optimizations would be avoided, and the variable would be aligned as specified. _Atomic: Dependency-breaking

Re: Doubts regarding the _Dependent_ptr keyword

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

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

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

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

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

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 > >>

Re: Doubts regarding the _Dependent_ptr keyword

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

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

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

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

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

On Sat, Feb 27, 2016 at 11:16:51AM -0800, Linus Torvalds wrote: > On Feb 27, 2016 09:06, "Paul E. McKenney" <paul...@linux.vnet.ibm.com> > wrote: > > > > > > But we do already have something very similar with signed integer > > overflow. If the

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

re 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: > > > On Fri, Feb 19, 2016 at 09:15:16PM

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

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

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

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.isoc

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

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:00 AM, Paul E. McKenney < > paul...@linux.vnet.i

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

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/58830

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

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 me know, and in great detail

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

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 think that 7.9 helps narrow

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

On Fri, May 22, 2015 at 08:43:44AM +0200, Ingo Molnar wrote: * Linus Torvalds torva...@linux-foundation.org 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.

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

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. There

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

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 wrote: On to #5

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

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, that is) model. There are several

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

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: Indeed, something like this does

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

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 machine when they exit (if they exit!) in order to show

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

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 paul...@linux.vnet.ibm.com 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 speculate

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

On Wed, May 20, 2015 at 11:03:00AM +0200, Richard Biener wrote: On Wed, May 20, 2015 at 9:34 AM, Jens Maurer jens.mau...@gmx.net 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

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

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 language lawyers claiming (char *)ptr - (intptr_t

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

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 torva...@linux-foundation.org wrote

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

On Wed, May 20, 2015 at 02:18:37PM +0100, David Howells wrote: Paul E. McKenney paul...@linux.vnet.ibm.com wrote: Additionally, what about the following code? char *x = y ? z : z; Does that extend a dependency chain from z to x? If so, I can imagine a CPU breaking

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

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 paul...@linux.vnet.ibm.com wrote: I was thinking of y as a simple variable, but if it is something more complex, then the compiler could do this, right

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

On Wed, May 20, 2015 at 02:37:05PM +0100, David Howells wrote: Paul E. McKenney paul...@linux.vnet.ibm.com 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; y; x = z; Yeah. I

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

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: If a pointer is part

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

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 a

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

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: Paul E. McKenney paul...@linux.vnet.ibm.com wrote: I

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

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 paul...@linux.vnet.ibm.com wrote: http://www.rdrop.com/users/paulmck/RCU/consume.2015.05.18a.pdf From a very quick read-through, the restricted dependency chain in 7.9

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

On Tue, May 19, 2015 at 07:10:12PM -0700, Linus Torvalds wrote: On Tue, May 19, 2015 at 6:57 PM, Linus Torvalds torva...@linux-foundation.org wrote: - the you can add/subtract integral values still opens you up to language lawyers claiming (char *)ptr - (intptr_t)ptr preserving the

Compilers and RCU readers: Once more unto the breach!

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

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

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:36PM +0100, Torvald Riegel

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

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: On Tue, Mar 04, 2014 at 11:00:32AM -0800

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

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:19PM +0100, Torvald Riegel

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

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: xagsmtp2.20140303204700.3

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

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:08PM +0100, Torvald Riegel

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

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, 2014-03-03 at 11:20 -0800, Paul E

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

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 the boolean and || when

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

On Sun, Mar 02, 2014 at 04:05:52AM -0600, Peter Sewell wrote: On 1 March 2014 08:03, Paul E. McKenney paul...@linux.vnet.ibm.com 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 paul...@linux.vnet.ibm.com wrote

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

On Sun, Mar 02, 2014 at 11:44:52PM +, Peter Sewell wrote: On 2 March 2014 23:20, Paul E. McKenney paul...@linux.vnet.ibm.com wrote: On Sun, Mar 02, 2014 at 04:05:52AM -0600, Peter Sewell wrote: On 1 March 2014 08:03, Paul E. McKenney paul...@linux.vnet.ibm.com wrote: On Sat, Mar 01

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

On Sat, Mar 01, 2014 at 04:06:34AM -0600, Peter Sewell wrote: Hi Paul, On 28 February 2014 18:50, Paul E. McKenney paul...@linux.vnet.ibm.com 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 wrote: On Thu

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

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 paul...@linux.vnet.ibm.com wrote: 3. The comparison was against another RCU-protected pointer

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

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 paul...@linux.vnet.ibm.com wrote: Good points. How about

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

On Thu, Feb 27, 2014 at 09:01:40AM -0800, Linus Torvalds wrote: On Thu, Feb 27, 2014 at 7:37 AM, Torvald Riegel trie...@redhat.com 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

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

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, Feb 24, 2014 at 10:53 AM, Paul E. McKenney

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

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 paul...@linux.vnet.ibm.com wrote: 3. The comparison was against another RCU-protected pointer, where that other pointer was properly fetched using one

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

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, Feb 24, 2014 at 10:53 AM, Paul E. McKenney

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

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:37PM +0100, Michael Matz

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

On Mon, Feb 24, 2014 at 10:05:52PM -0800, Linus Torvalds wrote: On Mon, Feb 24, 2014 at 3:35 PM, Linus Torvalds torva...@linux-foundation.org wrote: Litmus test 1: p = atomic_read(pp, consume); if (p == variable) return p-val; is *NOT* ordered Btw, don't get

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

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 paul...@linux.vnet.ibm.com wrote: So let me see if I understand your reasoning. My best guess is that it goes something like this: 1. The Linux kernel contains code

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

On Tue, Feb 25, 2014 at 10:06:53PM -0500, George Spelvin wrote: paul...@linux.vnet.ibm.com wrote: torva...@linux-foundation.org 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

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

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 ordering are wrong and should try to avoid

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

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', '*q' and 'i'. Thus it seems

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

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 fiddled with, and that includes code sequences

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

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 int i; int *q = i; int **p = q; atomic_XXX (p, CONSUME

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

On Mon, Feb 24, 2014 at 09:38:46AM -0800, Linus Torvalds wrote: On Mon, Feb 24, 2014 at 8:55 AM, Michael Matz m...@suse.de 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

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

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 paul...@linux.vnet.ibm.com wrote: 4. Bitwise operators (, |, ^, and I suppose also ~) applied to a chained pointer and an integer results in another

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

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 paul...@linux.vnet.ibm.com wrote: What if the nothing modifies 'p' part looks like this: if (p != myvariable) return; and now any sane compiler will happily

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

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 paul...@linux.vnet.ibm.com wrote: Agreed, by far the most frequent use is - to dereference and assignment to store into a local variable. The other operations where the kernel

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

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 paul...@linux.vnet.ibm.com wrote: Adding and subtracting integers to/from a RCU-protected pointer makes sense to me. Ack. And that's normal access to an object behavior

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

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 paul...@linux.vnet.ibm.com wrote: (a) we've said 'q' is restricted, so there is no aliasing between q and the pointers b/c. So the compiler is free to move those accesses

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

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:08PM +0100, Torvald Riegel

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

On Sat, Feb 22, 2014 at 01:53:30PM -0800, Linus Torvalds wrote: On Sat, Feb 22, 2014 at 10:53 AM, Torvald Riegel trie...@redhat.com 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

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

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 at, I

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

On Fri, Feb 21, 2014 at 06:28:05PM +, Peter Sewell wrote: On 20 February 2014 17:01, Linus Torvalds torva...@linux-foundation.org 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

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

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; } Otherwise dependencies won't get carried through

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

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 paul...@linux.vnet.ibm.com wrote: The control dependency should order subsequent stores, at least assuming that a and b don't start off with identical stores that the compiler

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

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 the read

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

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 paul...@linux.vnet.ibm.com wrote: So lets make this really simple: if you have a consume-cmp-read, is the ordering of the two reads guaranteed? Not as far as I know. Also

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

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:49PM -0800, Linus Torvalds

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

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 currently convert consume

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

On Thu, Feb 20, 2014 at 09:34:57AM -0800, Linus Torvalds wrote: On Thu, Feb 20, 2014 at 9:14 AM, Torvald Riegel trie...@redhat.com 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,

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

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 paul...@linux.vnet.ibm.com wrote: You really need that consume to be acquire. So I think we now all agree that that is what the standard is saying. And I'm saying

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

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 be extremely happy

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

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 paul...@linux.vnet.ibm.com wrote: The example gcc breakage was something like this: i = atomic_load(idx, memory_order_consume); x = array[0 + i - i

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

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-Gateway: vmsdvm9.vnet.ibm.com (XAGSMTP4

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

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 called, so that means

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

On Wed, Feb 19, 2014 at 04:53:49PM -0800, Linus Torvalds wrote: On Tue, Feb 18, 2014 at 11:47 AM, Torvald Riegel trie...@redhat.com 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*

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

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 in

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

On Tue, Feb 18, 2014 at 03:33:35PM +, Peter Sewell wrote: Hi Paul, On 18 February 2014 14:56, Paul E. McKenney paul...@linux.vnet.ibm.com wrote: 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

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

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 trie...@redhat.com wrote: Which example do

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

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 trie...@redhat.com wrote: There's an underlying problem here that's independent from the actual instance that you're

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

On Tue, Feb 18, 2014 at 08:49:13AM -0800, Linus Torvalds wrote: On Tue, Feb 18, 2014 at 7:31 AM, Torvald Riegel trie...@redhat.com 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

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

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 must

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

On Tue, Feb 18, 2014 at 09:44:48AM -0800, Linus Torvalds wrote: On Tue, Feb 18, 2014 at 8:17 AM, Torvald Riegel trie...@redhat.com 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

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

On Tue, Feb 18, 2014 at 06:23:47PM +, Peter Sewell wrote: On 18 February 2014 17:16, Paul E. McKenney paul...@linux.vnet.ibm.com 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 trie...@redhat.com wrote: On Mon

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

On Tue, Feb 18, 2014 at 10:49:27AM -0800, Linus Torvalds wrote: On Tue, Feb 18, 2014 at 10:21 AM, Peter Sewell peter.sew...@cl.cam.ac.uk 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

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

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

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:13AM -0800, Linus Torvalds

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

On Wed, Feb 12, 2014 at 07:12:05PM +0100, Peter Zijlstra wrote: On Wed, Feb 12, 2014 at 09:42:09AM -0800, Paul E. McKenney wrote: You need volatile semantics to force the compiler to ignore any proofs it might otherwise attempt to construct. Hence all the ACCESS_ONCE() calls in my email

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

On Mon, Feb 17, 2014 at 08:55:47PM +0100, Torvald Riegel wrote: On Sat, 2014-02-15 at 10:49 -0800, Linus Torvalds wrote: On Sat, Feb 15, 2014 at 9:45 AM, Torvald Riegel trie...@redhat.com wrote: I think a major benefit of C11's memory model is that it gives a *precise* specification

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

On Mon, Feb 17, 2014 at 09:39:54PM +0100, Richard Biener wrote: On February 17, 2014 7:18:15 PM GMT+01:00, Paul E. McKenney paul...@linux.vnet.ibm.com wrote: On Wed, Feb 12, 2014 at 07:12:05PM +0100, Peter Zijlstra wrote: On Wed, Feb 12, 2014 at 09:42:09AM -0800, Paul E. McKenney wrote

  1   2   >