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

2014-02-15 Thread Linus Torvalds
On Sat, Feb 15, 2014 at 9:30 AM, Torvald Riegel wrote: > > I think the example is easy to misunderstand, because the context isn't > clear. Therefore, let me first try to clarify the background. > > (1) The abstract machine does not write speculatively. > (2) Emitting a branch instruction and

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

2014-02-15 Thread Linus Torvalds
On Sat, Feb 15, 2014 at 9:45 AM, Torvald Riegel wrote: > > I think a major benefit of C11's memory model is that it gives a > *precise* specification for how a compiler is allowed to optimize. Clearly it does *not*. This whole discussion is proof of that. It's not at all clear, and the standard

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

2014-02-15 Thread Torvald Riegel
On Fri, 2014-02-14 at 18:44 -0800, Linus Torvalds wrote: > On Fri, Feb 14, 2014 at 6:08 PM, Paul E. McKenney > wrote: > > > > One way of looking at the discussion between Torvald and myself would be > > as a seller (Torvald) and a buyer (me) haggling over the fine print in > > a proposed contract

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

2014-02-15 Thread Torvald Riegel
On Fri, 2014-02-14 at 12:02 -0800, Linus Torvalds wrote: > On Fri, Feb 14, 2014 at 11:50 AM, Linus Torvalds > wrote: > > > > Why are we still discussing this idiocy? It's irrelevant. If the > > standard really allows random store speculation, the standard doesn't > > matter, and sane people

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

2014-02-15 Thread Torvald Riegel
On Fri, 2014-02-14 at 11:50 -0800, Linus Torvalds wrote: > On Fri, Feb 14, 2014 at 9:29 AM, Paul E. McKenney > wrote: > > > > Linus, Peter, any objections to marking places where we are relying on > > ordering from control dependencies against later stores? This approach > > seems to me to have

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

2014-02-15 Thread Torvald Riegel
On Fri, 2014-02-14 at 11:50 -0800, Linus Torvalds wrote: On Fri, Feb 14, 2014 at 9:29 AM, Paul E. McKenney paul...@linux.vnet.ibm.com wrote: Linus, Peter, any objections to marking places where we are relying on ordering from control dependencies against later stores? This approach

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

2014-02-15 Thread Torvald Riegel
On Fri, 2014-02-14 at 12:02 -0800, Linus Torvalds wrote: On Fri, Feb 14, 2014 at 11:50 AM, Linus Torvalds torva...@linux-foundation.org wrote: Why are we still discussing this idiocy? It's irrelevant. If the standard really allows random store speculation, the standard doesn't matter,

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

2014-02-15 Thread Torvald Riegel
On Fri, 2014-02-14 at 18:44 -0800, Linus Torvalds wrote: On Fri, Feb 14, 2014 at 6:08 PM, Paul E. McKenney paul...@linux.vnet.ibm.com wrote: One way of looking at the discussion between Torvald and myself would be as a seller (Torvald) and a buyer (me) haggling over the fine print in a

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

2014-02-15 Thread Linus Torvalds
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 for how a compiler is allowed to optimize. Clearly it does *not*. This whole discussion is proof of that. It's not at all clear,

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

2014-02-15 Thread Linus Torvalds
On Sat, Feb 15, 2014 at 9:30 AM, Torvald Riegel trie...@redhat.com wrote: I think the example is easy to misunderstand, because the context isn't clear. Therefore, let me first try to clarify the background. (1) The abstract machine does not write speculatively. (2) Emitting a branch

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

2014-02-14 Thread Paul E. McKenney
On Fri, Feb 14, 2014 at 10:35:44PM -0800, Paul E. McKenney wrote: > On Fri, Feb 14, 2014 at 06:48:02PM -0800, Linus Torvalds wrote: > > On Fri, Feb 14, 2014 at 6:44 PM, Linus Torvalds > > wrote: > > > > > > And conversely, the C11 people can walk away from us too. But if they > > > can't make us

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

2014-02-14 Thread Paul E. McKenney
On Fri, Feb 14, 2014 at 06:48:02PM -0800, Linus Torvalds wrote: > On Fri, Feb 14, 2014 at 6:44 PM, Linus Torvalds > wrote: > > > > And conversely, the C11 people can walk away from us too. But if they > > can't make us happy (and by "make us happy", I really mean no stupid > > games on our part)

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

2014-02-14 Thread Linus Torvalds
On Fri, Feb 14, 2014 at 6:44 PM, Linus Torvalds wrote: > > And conversely, the C11 people can walk away from us too. But if they > can't make us happy (and by "make us happy", I really mean no stupid > games on our part) I personally think they'll have a stronger > standard, and a real use case,

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

2014-02-14 Thread Linus Torvalds
On Fri, Feb 14, 2014 at 6:08 PM, Paul E. McKenney wrote: > > One way of looking at the discussion between Torvald and myself would be > as a seller (Torvald) and a buyer (me) haggling over the fine print in > a proposed contract (the standard). Whether that makes you feel better > or worse about

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

2014-02-14 Thread Paul E. McKenney
On Fri, Feb 14, 2014 at 12:02:23PM -0800, Linus Torvalds wrote: > On Fri, Feb 14, 2014 at 11:50 AM, Linus Torvalds > wrote: > > > > Why are we still discussing this idiocy? It's irrelevant. If the > > standard really allows random store speculation, the standard doesn't > > matter, and sane

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

2014-02-14 Thread Linus Torvalds
On Fri, Feb 14, 2014 at 11:50 AM, Linus Torvalds wrote: > > Why are we still discussing this idiocy? It's irrelevant. If the > standard really allows random store speculation, the standard doesn't > matter, and sane people shouldn't waste their time arguing about it. Btw, the other part of this

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

2014-02-14 Thread Linus Torvalds
On Fri, Feb 14, 2014 at 9:29 AM, Paul E. McKenney wrote: > > Linus, Peter, any objections to marking places where we are relying on > ordering from control dependencies against later stores? This approach > seems to me to have significant documentation benefits. Quite frankly, I think it's

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

2014-02-14 Thread Torvald Riegel
On Fri, 2014-02-14 at 09:29 -0800, Paul E. McKenney wrote: > On Thu, Feb 13, 2014 at 08:43:01PM -0800, Torvald Riegel wrote: > > On Thu, 2014-02-13 at 18:01 -0800, Paul E. McKenney wrote: > > [ . . . ] > > > > Another option would be to flag the conditional expression, prohibiting > > > the

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

2014-02-14 Thread Torvald Riegel
On Fri, 2014-02-14 at 10:50 +0100, Peter Zijlstra wrote: > On Thu, Feb 13, 2014 at 09:07:55PM -0800, Torvald Riegel wrote: > > That depends on what your goal is. First, I don't know why you quoted that, but without the context, quoting it doesn't make sense. Let me repeat the point. The

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

2014-02-14 Thread Paul E. McKenney
On Thu, Feb 13, 2014 at 08:43:01PM -0800, Torvald Riegel wrote: > On Thu, 2014-02-13 at 18:01 -0800, Paul E. McKenney wrote: [ . . . ] > > Another option would be to flag the conditional expression, prohibiting > > the compiler from optimizing out any conditional branches. Perhaps > > something

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

2014-02-14 Thread Peter Zijlstra
On Thu, Feb 13, 2014 at 09:07:55PM -0800, Torvald Riegel wrote: > That depends on what your goal is. A compiler that we don't need to fight in order to generate sane code would be nice. But as Linus said; we can continue to ignore you lot and go on as we've done. -- To unsubscribe from this list:

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

2014-02-14 Thread Peter Zijlstra
On Thu, Feb 13, 2014 at 09:07:55PM -0800, Torvald Riegel wrote: That depends on what your goal is. A compiler that we don't need to fight in order to generate sane code would be nice. But as Linus said; we can continue to ignore you lot and go on as we've done. -- To unsubscribe from this list:

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

2014-02-14 Thread Paul E. McKenney
On Thu, Feb 13, 2014 at 08:43:01PM -0800, Torvald Riegel wrote: On Thu, 2014-02-13 at 18:01 -0800, Paul E. McKenney wrote: [ . . . ] Another option would be to flag the conditional expression, prohibiting the compiler from optimizing out any conditional branches. Perhaps something like

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

2014-02-14 Thread Torvald Riegel
On Fri, 2014-02-14 at 10:50 +0100, Peter Zijlstra wrote: On Thu, Feb 13, 2014 at 09:07:55PM -0800, Torvald Riegel wrote: That depends on what your goal is. First, I don't know why you quoted that, but without the context, quoting it doesn't make sense. Let me repeat the point. The standard

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

2014-02-14 Thread Torvald Riegel
On Fri, 2014-02-14 at 09:29 -0800, Paul E. McKenney wrote: On Thu, Feb 13, 2014 at 08:43:01PM -0800, Torvald Riegel wrote: On Thu, 2014-02-13 at 18:01 -0800, Paul E. McKenney wrote: [ . . . ] Another option would be to flag the conditional expression, prohibiting the compiler from

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

2014-02-14 Thread Linus Torvalds
On Fri, Feb 14, 2014 at 9:29 AM, Paul E. McKenney paul...@linux.vnet.ibm.com wrote: Linus, Peter, any objections to marking places where we are relying on ordering from control dependencies against later stores? This approach seems to me to have significant documentation benefits. Quite

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

2014-02-14 Thread Linus Torvalds
On Fri, Feb 14, 2014 at 11:50 AM, Linus Torvalds torva...@linux-foundation.org wrote: Why are we still discussing this idiocy? It's irrelevant. If the standard really allows random store speculation, the standard doesn't matter, and sane people shouldn't waste their time arguing about it.

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

2014-02-14 Thread Paul E. McKenney
On Fri, Feb 14, 2014 at 12:02:23PM -0800, Linus Torvalds wrote: On Fri, Feb 14, 2014 at 11:50 AM, Linus Torvalds torva...@linux-foundation.org wrote: Why are we still discussing this idiocy? It's irrelevant. If the standard really allows random store speculation, the standard doesn't

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

2014-02-14 Thread Linus Torvalds
On Fri, Feb 14, 2014 at 6:08 PM, Paul E. McKenney paul...@linux.vnet.ibm.com wrote: One way of looking at the discussion between Torvald and myself would be as a seller (Torvald) and a buyer (me) haggling over the fine print in a proposed contract (the standard). Whether that makes you feel

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

2014-02-14 Thread Linus Torvalds
On Fri, Feb 14, 2014 at 6:44 PM, Linus Torvalds torva...@linux-foundation.org wrote: And conversely, the C11 people can walk away from us too. But if they can't make us happy (and by make us happy, I really mean no stupid games on our part) I personally think they'll have a stronger standard,

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

2014-02-14 Thread Paul E. McKenney
On Fri, Feb 14, 2014 at 06:48:02PM -0800, Linus Torvalds wrote: On Fri, Feb 14, 2014 at 6:44 PM, Linus Torvalds torva...@linux-foundation.org wrote: And conversely, the C11 people can walk away from us too. But if they can't make us happy (and by make us happy, I really mean no stupid

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

2014-02-14 Thread Paul E. McKenney
On Fri, Feb 14, 2014 at 10:35:44PM -0800, Paul E. McKenney wrote: On Fri, Feb 14, 2014 at 06:48:02PM -0800, Linus Torvalds wrote: On Fri, Feb 14, 2014 at 6:44 PM, Linus Torvalds torva...@linux-foundation.org wrote: And conversely, the C11 people can walk away from us too. But if they

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

2014-02-13 Thread Torvald Riegel
On Wed, 2014-02-12 at 10:19 +0100, Peter Zijlstra wrote: > > I don't know the specifics of your example, but from how I understand > > it, I don't see a problem if the compiler can prove that the store will > > always happen. > > > > To be more specific, if the compiler can prove that the store

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

2014-02-13 Thread Torvald Riegel
On Thu, 2014-02-13 at 18:01 -0800, Paul E. McKenney wrote: > On Thu, Feb 13, 2014 at 12:03:57PM -0800, Torvald Riegel wrote: > > On Wed, 2014-02-12 at 16:23 -0800, Paul E. McKenney wrote: > > > On Wed, Feb 12, 2014 at 12:22:53PM -0800, Linus Torvalds wrote: > > > > On Wed, Feb 12, 2014 at 10:07

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

2014-02-13 Thread Paul E. McKenney
On Thu, Feb 13, 2014 at 12:03:57PM -0800, Torvald Riegel wrote: > On Wed, 2014-02-12 at 16:23 -0800, Paul E. McKenney wrote: > > On Wed, Feb 12, 2014 at 12:22:53PM -0800, Linus Torvalds wrote: > > > On Wed, Feb 12, 2014 at 10:07 AM, Paul E. McKenney > > > wrote: > > > > > > > > Us Linux-kernel

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

2014-02-13 Thread Torvald Riegel
On Wed, 2014-02-12 at 16:23 -0800, Paul E. McKenney wrote: > On Wed, Feb 12, 2014 at 12:22:53PM -0800, Linus Torvalds wrote: > > On Wed, Feb 12, 2014 at 10:07 AM, Paul E. McKenney > > wrote: > > > > > > Us Linux-kernel hackers will often need to use volatile semantics in > > > combination with

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

2014-02-13 Thread Torvald Riegel
On Wed, 2014-02-12 at 16:23 -0800, Paul E. McKenney wrote: On Wed, Feb 12, 2014 at 12:22:53PM -0800, Linus Torvalds wrote: On Wed, Feb 12, 2014 at 10:07 AM, Paul E. McKenney paul...@linux.vnet.ibm.com wrote: Us Linux-kernel hackers will often need to use volatile semantics in

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

2014-02-13 Thread Paul E. McKenney
On Thu, Feb 13, 2014 at 12:03:57PM -0800, Torvald Riegel wrote: On Wed, 2014-02-12 at 16:23 -0800, Paul E. McKenney wrote: On Wed, Feb 12, 2014 at 12:22:53PM -0800, Linus Torvalds wrote: On Wed, Feb 12, 2014 at 10:07 AM, Paul E. McKenney paul...@linux.vnet.ibm.com wrote: Us

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

2014-02-13 Thread Torvald Riegel
On Thu, 2014-02-13 at 18:01 -0800, Paul E. McKenney wrote: On Thu, Feb 13, 2014 at 12:03:57PM -0800, Torvald Riegel wrote: On Wed, 2014-02-12 at 16:23 -0800, Paul E. McKenney wrote: On Wed, Feb 12, 2014 at 12:22:53PM -0800, Linus Torvalds wrote: On Wed, Feb 12, 2014 at 10:07 AM, Paul E.

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

2014-02-13 Thread Torvald Riegel
On Wed, 2014-02-12 at 10:19 +0100, Peter Zijlstra wrote: I don't know the specifics of your example, but from how I understand it, I don't see a problem if the compiler can prove that the store will always happen. To be more specific, if the compiler can prove that the store will

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

2014-02-12 Thread Paul E. McKenney
On Wed, Feb 12, 2014 at 12:22:53PM -0800, Linus Torvalds wrote: > On Wed, Feb 12, 2014 at 10:07 AM, Paul E. McKenney > wrote: > > > > Us Linux-kernel hackers will often need to use volatile semantics in > > combination with C11 atomics in most cases. The C11 atomics do cover > > some of the

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

2014-02-12 Thread Linus Torvalds
On Wed, Feb 12, 2014 at 10:07 AM, Paul E. McKenney wrote: > > Us Linux-kernel hackers will often need to use volatile semantics in > combination with C11 atomics in most cases. The C11 atomics do cover > some of the reasons we currently use ACCESS_ONCE(), but not all of them -- > in particular,

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

2014-02-12 Thread Paul E. McKenney
On Tue, Feb 11, 2014 at 09:13:34PM -0800, Torvald Riegel wrote: > On Sun, 2014-02-09 at 19:51 -0800, Paul E. McKenney wrote: > > On Mon, Feb 10, 2014 at 01:06:48AM +0100, Torvald Riegel wrote: > > > On Thu, 2014-02-06 at 20:20 -0800, Paul E. McKenney wrote: > > > > On Fri, Feb 07, 2014 at

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

2014-02-12 Thread Paul E. McKenney
On Tue, Feb 11, 2014 at 09:39:24PM -0800, Torvald Riegel wrote: > On Mon, 2014-02-10 at 11:09 -0800, Linus Torvalds wrote: > > On Sun, Feb 9, 2014 at 4:27 PM, Torvald Riegel wrote: > > > > > > Intuitively, this is wrong because this let's the program take a step > > > the abstract machine

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

2014-02-12 Thread Peter Zijlstra
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 to Torvald. (Hopefully I translated your example > reasonably.)

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

2014-02-12 Thread Paul E. McKenney
On Tue, Feb 11, 2014 at 10:06:34PM -0800, Torvald Riegel wrote: > On Tue, 2014-02-11 at 07:59 -0800, Paul E. McKenney wrote: > > On Mon, Feb 10, 2014 at 11:09:24AM -0800, Linus Torvalds wrote: > > > On Sun, Feb 9, 2014 at 4:27 PM, Torvald Riegel wrote: > > > > > > > > Intuitively, this is wrong

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

2014-02-12 Thread Paul E. McKenney
On Wed, Feb 12, 2014 at 10:19:07AM +0100, Peter Zijlstra wrote: > > I don't know the specifics of your example, but from how I understand > > it, I don't see a problem if the compiler can prove that the store will > > always happen. > > > > To be more specific, if the compiler can prove that the

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

2014-02-12 Thread Peter Zijlstra
> I don't know the specifics of your example, but from how I understand > it, I don't see a problem if the compiler can prove that the store will > always happen. > > To be more specific, if the compiler can prove that the store will > happen anyway, and the region of code can be assumed to

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

2014-02-12 Thread Peter Zijlstra
I don't know the specifics of your example, but from how I understand it, I don't see a problem if the compiler can prove that the store will always happen. To be more specific, if the compiler can prove that the store will happen anyway, and the region of code can be assumed to always run

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

2014-02-12 Thread Paul E. McKenney
On Wed, Feb 12, 2014 at 10:19:07AM +0100, Peter Zijlstra wrote: I don't know the specifics of your example, but from how I understand it, I don't see a problem if the compiler can prove that the store will always happen. To be more specific, if the compiler can prove that the store will

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

2014-02-12 Thread Paul E. McKenney
On Tue, Feb 11, 2014 at 10:06:34PM -0800, Torvald Riegel wrote: On Tue, 2014-02-11 at 07:59 -0800, Paul E. McKenney wrote: On Mon, Feb 10, 2014 at 11:09:24AM -0800, Linus Torvalds wrote: On Sun, Feb 9, 2014 at 4:27 PM, Torvald Riegel trie...@redhat.com wrote: Intuitively, this is

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

2014-02-12 Thread Peter Zijlstra
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 to Torvald. (Hopefully I translated your example reasonably.) My

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

2014-02-12 Thread Paul E. McKenney
On Tue, Feb 11, 2014 at 09:39:24PM -0800, Torvald Riegel wrote: On Mon, 2014-02-10 at 11:09 -0800, Linus Torvalds wrote: On Sun, Feb 9, 2014 at 4:27 PM, Torvald Riegel trie...@redhat.com wrote: Intuitively, this is wrong because this let's the program take a step the abstract machine

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

2014-02-12 Thread Paul E. McKenney
On Tue, Feb 11, 2014 at 09:13:34PM -0800, Torvald Riegel wrote: On Sun, 2014-02-09 at 19:51 -0800, Paul E. McKenney wrote: On Mon, Feb 10, 2014 at 01:06:48AM +0100, Torvald Riegel wrote: On Thu, 2014-02-06 at 20:20 -0800, Paul E. McKenney wrote: On Fri, Feb 07, 2014 at 12:44:48AM +0100,

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

2014-02-12 Thread Linus Torvalds
On Wed, Feb 12, 2014 at 10:07 AM, Paul E. McKenney paul...@linux.vnet.ibm.com wrote: Us Linux-kernel hackers will often need to use volatile semantics in combination with C11 atomics in most cases. The C11 atomics do cover some of the reasons we currently use ACCESS_ONCE(), but not all of

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

2014-02-12 Thread Paul E. McKenney
On Wed, Feb 12, 2014 at 12:22:53PM -0800, Linus Torvalds wrote: On Wed, Feb 12, 2014 at 10:07 AM, Paul E. McKenney paul...@linux.vnet.ibm.com wrote: Us Linux-kernel hackers will often need to use volatile semantics in combination with C11 atomics in most cases. The C11 atomics do cover

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

2014-02-11 Thread Torvald Riegel
On Tue, 2014-02-11 at 07:59 -0800, Paul E. McKenney wrote: > On Mon, Feb 10, 2014 at 11:09:24AM -0800, Linus Torvalds wrote: > > On Sun, Feb 9, 2014 at 4:27 PM, Torvald Riegel wrote: > > > > > > Intuitively, this is wrong because this let's the program take a step > > > the abstract machine

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

2014-02-11 Thread Torvald Riegel
On Mon, 2014-02-10 at 11:09 -0800, Linus Torvalds wrote: > On Sun, Feb 9, 2014 at 4:27 PM, Torvald Riegel wrote: > > > > Intuitively, this is wrong because this let's the program take a step > > the abstract machine wouldn't do. This is different to the sequential > > code that Peter posted

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

2014-02-11 Thread Torvald Riegel
On Sun, 2014-02-09 at 19:51 -0800, Paul E. McKenney wrote: > On Mon, Feb 10, 2014 at 01:06:48AM +0100, Torvald Riegel wrote: > > On Thu, 2014-02-06 at 20:20 -0800, Paul E. McKenney wrote: > > > On Fri, Feb 07, 2014 at 12:44:48AM +0100, Torvald Riegel wrote: > > > > On Thu, 2014-02-06 at 14:11

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

2014-02-11 Thread Paul E. McKenney
On Mon, Feb 10, 2014 at 11:09:24AM -0800, Linus Torvalds wrote: > On Sun, Feb 9, 2014 at 4:27 PM, Torvald Riegel wrote: > > > > Intuitively, this is wrong because this let's the program take a step > > the abstract machine wouldn't do. This is different to the sequential > > code that Peter

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

2014-02-11 Thread Paul E. McKenney
On Mon, Feb 10, 2014 at 11:09:24AM -0800, Linus Torvalds wrote: On Sun, Feb 9, 2014 at 4:27 PM, Torvald Riegel trie...@redhat.com wrote: Intuitively, this is wrong because this let's the program take a step the abstract machine wouldn't do. This is different to the sequential code that

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

2014-02-11 Thread Torvald Riegel
On Sun, 2014-02-09 at 19:51 -0800, Paul E. McKenney wrote: On Mon, Feb 10, 2014 at 01:06:48AM +0100, Torvald Riegel wrote: On Thu, 2014-02-06 at 20:20 -0800, Paul E. McKenney wrote: On Fri, Feb 07, 2014 at 12:44:48AM +0100, Torvald Riegel wrote: On Thu, 2014-02-06 at 14:11 -0800, Paul E.

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

2014-02-11 Thread Torvald Riegel
On Mon, 2014-02-10 at 11:09 -0800, Linus Torvalds wrote: On Sun, Feb 9, 2014 at 4:27 PM, Torvald Riegel trie...@redhat.com wrote: Intuitively, this is wrong because this let's the program take a step the abstract machine wouldn't do. This is different to the sequential code that Peter

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

2014-02-11 Thread Torvald Riegel
On Tue, 2014-02-11 at 07:59 -0800, Paul E. McKenney wrote: On Mon, Feb 10, 2014 at 11:09:24AM -0800, Linus Torvalds wrote: On Sun, Feb 9, 2014 at 4:27 PM, Torvald Riegel trie...@redhat.com wrote: Intuitively, this is wrong because this let's the program take a step the abstract machine

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

2014-02-10 Thread Peter Zijlstra
On Mon, Feb 10, 2014 at 04:08:11PM -0500, Chris Metcalf wrote: > (+LKML again) > > On 2/10/2014 3:57 PM, Peter Zijlstra wrote: > > On Mon, Feb 10, 2014 at 03:50:04PM -0500, Chris Metcalf wrote: > >> On 2/6/2014 8:52 AM, Peter Zijlstra wrote: > >>> Its been compiled on everything I have a compiler

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

2014-02-10 Thread Chris Metcalf
(+LKML again) On 2/10/2014 3:57 PM, Peter Zijlstra wrote: > On Mon, Feb 10, 2014 at 03:50:04PM -0500, Chris Metcalf wrote: >> On 2/6/2014 8:52 AM, Peter Zijlstra wrote: >>> Its been compiled on everything I have a compiler for, however frv and >>> tile are missing because they're special and I

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

2014-02-10 Thread Linus Torvalds
On Sun, Feb 9, 2014 at 4:27 PM, Torvald Riegel wrote: > > Intuitively, this is wrong because this let's the program take a step > the abstract machine wouldn't do. This is different to the sequential > code that Peter posted because it uses atomics, and thus one can't > easily assume that the

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

2014-02-10 Thread Will Deacon
On Mon, Feb 10, 2014 at 03:04:43PM +, Paul E. McKenney wrote: > On Mon, Feb 10, 2014 at 11:49:29AM +, Will Deacon wrote: > > On Mon, Feb 10, 2014 at 11:48:13AM +, Peter Zijlstra wrote: > > > On Fri, Feb 07, 2014 at 10:02:16AM -0800, Paul E. McKenney wrote: > > > > As near as I can

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

2014-02-10 Thread Paul E. McKenney
On Mon, Feb 10, 2014 at 11:49:29AM +, Will Deacon wrote: > On Mon, Feb 10, 2014 at 11:48:13AM +, Peter Zijlstra wrote: > > On Fri, Feb 07, 2014 at 10:02:16AM -0800, Paul E. McKenney wrote: > > > As near as I can tell, compiler writers hate the idea of prohibiting > > > speculative-store

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

2014-02-10 Thread Peter Zijlstra
On Mon, Feb 10, 2014 at 11:49:29AM +, Will Deacon wrote: > On Mon, Feb 10, 2014 at 11:48:13AM +, Peter Zijlstra wrote: > > On Fri, Feb 07, 2014 at 10:02:16AM -0800, Paul E. McKenney wrote: > > > As near as I can tell, compiler writers hate the idea of prohibiting > > > speculative-store

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

2014-02-10 Thread Will Deacon
On Mon, Feb 10, 2014 at 11:48:13AM +, Peter Zijlstra wrote: > On Fri, Feb 07, 2014 at 10:02:16AM -0800, Paul E. McKenney wrote: > > As near as I can tell, compiler writers hate the idea of prohibiting > > speculative-store optimizations because it requires them to introduce > > both control

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

2014-02-10 Thread Peter Zijlstra
On Fri, Feb 07, 2014 at 10:02:16AM -0800, Paul E. McKenney wrote: > As near as I can tell, compiler writers hate the idea of prohibiting > speculative-store optimizations because it requires them to introduce > both control and data dependency tracking into their compilers. Many of > them seem to

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

2014-02-10 Thread Peter Zijlstra
On Mon, Feb 10, 2014 at 01:27:51AM +0100, Torvald Riegel wrote: > > Initial state: x == y == 0 > > > > T1: r1 = atomic_load_explicit(x, memory_order_relaxed); > > atomic_store_explicit(42, y, memory_order_relaxed); > > if (r1 != 42) > > atomic_store_explicit(r1, y,

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

2014-02-10 Thread Peter Zijlstra
On Mon, Feb 10, 2014 at 01:27:51AM +0100, Torvald Riegel wrote: Initial state: x == y == 0 T1: r1 = atomic_load_explicit(x, memory_order_relaxed); atomic_store_explicit(42, y, memory_order_relaxed); if (r1 != 42) atomic_store_explicit(r1, y, memory_order_relaxed);

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

2014-02-10 Thread Peter Zijlstra
On Fri, Feb 07, 2014 at 10:02:16AM -0800, Paul E. McKenney wrote: As near as I can tell, compiler writers hate the idea of prohibiting speculative-store optimizations because it requires them to introduce both control and data dependency tracking into their compilers. Many of them seem to

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

2014-02-10 Thread Will Deacon
On Mon, Feb 10, 2014 at 11:48:13AM +, Peter Zijlstra wrote: On Fri, Feb 07, 2014 at 10:02:16AM -0800, Paul E. McKenney wrote: As near as I can tell, compiler writers hate the idea of prohibiting speculative-store optimizations because it requires them to introduce both control and data

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

2014-02-10 Thread Peter Zijlstra
On Mon, Feb 10, 2014 at 11:49:29AM +, Will Deacon wrote: On Mon, Feb 10, 2014 at 11:48:13AM +, Peter Zijlstra wrote: On Fri, Feb 07, 2014 at 10:02:16AM -0800, Paul E. McKenney wrote: As near as I can tell, compiler writers hate the idea of prohibiting speculative-store

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

2014-02-10 Thread Paul E. McKenney
On Mon, Feb 10, 2014 at 11:49:29AM +, Will Deacon wrote: On Mon, Feb 10, 2014 at 11:48:13AM +, Peter Zijlstra wrote: On Fri, Feb 07, 2014 at 10:02:16AM -0800, Paul E. McKenney wrote: As near as I can tell, compiler writers hate the idea of prohibiting speculative-store

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

2014-02-10 Thread Will Deacon
On Mon, Feb 10, 2014 at 03:04:43PM +, Paul E. McKenney wrote: On Mon, Feb 10, 2014 at 11:49:29AM +, Will Deacon wrote: On Mon, Feb 10, 2014 at 11:48:13AM +, Peter Zijlstra wrote: On Fri, Feb 07, 2014 at 10:02:16AM -0800, Paul E. McKenney wrote: As near as I can tell, compiler

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

2014-02-10 Thread Linus Torvalds
On Sun, Feb 9, 2014 at 4:27 PM, Torvald Riegel trie...@redhat.com wrote: Intuitively, this is wrong because this let's the program take a step the abstract machine wouldn't do. This is different to the sequential code that Peter posted because it uses atomics, and thus one can't easily

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

2014-02-10 Thread Chris Metcalf
(+LKML again) On 2/10/2014 3:57 PM, Peter Zijlstra wrote: On Mon, Feb 10, 2014 at 03:50:04PM -0500, Chris Metcalf wrote: On 2/6/2014 8:52 AM, Peter Zijlstra wrote: Its been compiled on everything I have a compiler for, however frv and tile are missing because they're special and I was tired.

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

2014-02-10 Thread Peter Zijlstra
On Mon, Feb 10, 2014 at 04:08:11PM -0500, Chris Metcalf wrote: (+LKML again) On 2/10/2014 3:57 PM, Peter Zijlstra wrote: On Mon, Feb 10, 2014 at 03:50:04PM -0500, Chris Metcalf wrote: On 2/6/2014 8:52 AM, Peter Zijlstra wrote: Its been compiled on everything I have a compiler for,

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

2014-02-09 Thread Paul E. McKenney
On Mon, Feb 10, 2014 at 01:06:48AM +0100, Torvald Riegel wrote: > On Thu, 2014-02-06 at 20:20 -0800, Paul E. McKenney wrote: > > On Fri, Feb 07, 2014 at 12:44:48AM +0100, Torvald Riegel wrote: > > > On Thu, 2014-02-06 at 14:11 -0800, Paul E. McKenney wrote: > > > > On Thu, Feb 06, 2014 at

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

2014-02-09 Thread Paul E. McKenney
On Mon, Feb 10, 2014 at 01:27:51AM +0100, Torvald Riegel wrote: > On Fri, 2014-02-07 at 10:02 -0800, Paul E. McKenney wrote: > > On Fri, Feb 07, 2014 at 04:55:48PM +, Will Deacon wrote: [ . . . ] > > And then it is a short and uncontroversial step to the following: > > > > Initial state: x

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

2014-02-09 Thread Paul E. McKenney
On Mon, Feb 10, 2014 at 01:27:51AM +0100, Torvald Riegel wrote: > On Fri, 2014-02-07 at 10:02 -0800, Paul E. McKenney wrote: > > On Fri, Feb 07, 2014 at 04:55:48PM +, Will Deacon wrote: > > > Hi Paul, > > > > > > On Fri, Feb 07, 2014 at 04:50:28PM +, Paul E. McKenney wrote: > > > > On

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

2014-02-09 Thread Linus Torvalds
On Sun, Feb 9, 2014 at 5:46 PM, Torvald Riegel wrote: > > IOW, I wrote that such a compiler transformation would be wrong in my > opinion. Thus, it should *not* return 42. Ahh, I am happy to have misunderstood. The "intuitively" threw me, because I thought that was building up to a "but", and

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

2014-02-09 Thread Torvald Riegel
On Sun, 2014-02-09 at 17:24 -0800, Linus Torvalds wrote: > On Sun, Feb 9, 2014 at 5:16 PM, Torvald Riegel wrote: > > > > (a) seems to say that you don't like requiring programmers to mark > > atomic accesses specially. Is that the case? > > In Paul's example, they were marked specially. > >

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

2014-02-09 Thread Linus Torvalds
On Sun, Feb 9, 2014 at 5:16 PM, Torvald Riegel wrote: > > (a) seems to say that you don't like requiring programmers to mark > atomic accesses specially. Is that the case? In Paul's example, they were marked specially. And you seemed to argue that Paul's example could possibly return anything

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

2014-02-09 Thread Torvald Riegel
On Sun, 2014-02-09 at 16:56 -0800, Linus Torvalds wrote: > On Sun, Feb 9, 2014 at 4:27 PM, Torvald Riegel wrote: > > > > I wouldn't characterize the situation like this (although I can't speak > > for others, obviously). IMHO, it's perfectly fine on sequential / > > non-synchronizing code,

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

2014-02-09 Thread Linus Torvalds
On Sun, Feb 9, 2014 at 4:27 PM, Torvald Riegel wrote: > > I wouldn't characterize the situation like this (although I can't speak > for others, obviously). IMHO, it's perfectly fine on sequential / > non-synchronizing code, because we know the difference isn't observable > by a correct program.

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

2014-02-09 Thread Torvald Riegel
On Fri, 2014-02-07 at 10:02 -0800, Paul E. McKenney wrote: > On Fri, Feb 07, 2014 at 04:55:48PM +, Will Deacon wrote: > > Hi Paul, > > > > On Fri, Feb 07, 2014 at 04:50:28PM +, Paul E. McKenney wrote: > > > On Fri, Feb 07, 2014 at 08:44:05AM +0100, Peter Zijlstra wrote: > > > > On Thu,

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

2014-02-09 Thread Torvald Riegel
On Thu, 2014-02-06 at 20:20 -0800, Paul E. McKenney wrote: > On Fri, Feb 07, 2014 at 12:44:48AM +0100, Torvald Riegel wrote: > > On Thu, 2014-02-06 at 14:11 -0800, Paul E. McKenney wrote: > > > On Thu, Feb 06, 2014 at 10:17:03PM +0100, Torvald Riegel wrote: > > > > On Thu, 2014-02-06 at 11:27

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

2014-02-09 Thread Torvald Riegel
On Thu, 2014-02-06 at 20:20 -0800, Paul E. McKenney wrote: On Fri, Feb 07, 2014 at 12:44:48AM +0100, Torvald Riegel wrote: On Thu, 2014-02-06 at 14:11 -0800, Paul E. McKenney wrote: On Thu, Feb 06, 2014 at 10:17:03PM +0100, Torvald Riegel wrote: On Thu, 2014-02-06 at 11:27 -0800, Paul E.

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

2014-02-09 Thread Torvald Riegel
On Fri, 2014-02-07 at 10:02 -0800, Paul E. McKenney wrote: On Fri, Feb 07, 2014 at 04:55:48PM +, Will Deacon wrote: Hi Paul, On Fri, Feb 07, 2014 at 04:50:28PM +, Paul E. McKenney wrote: On Fri, Feb 07, 2014 at 08:44:05AM +0100, Peter Zijlstra wrote: On Thu, Feb 06, 2014 at

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

2014-02-09 Thread Linus Torvalds
On Sun, Feb 9, 2014 at 4:27 PM, Torvald Riegel trie...@redhat.com wrote: I wouldn't characterize the situation like this (although I can't speak for others, obviously). IMHO, it's perfectly fine on sequential / non-synchronizing code, because we know the difference isn't observable by a

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

2014-02-09 Thread Torvald Riegel
On Sun, 2014-02-09 at 16:56 -0800, Linus Torvalds wrote: On Sun, Feb 9, 2014 at 4:27 PM, Torvald Riegel trie...@redhat.com wrote: I wouldn't characterize the situation like this (although I can't speak for others, obviously). IMHO, it's perfectly fine on sequential / non-synchronizing

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

2014-02-09 Thread Linus Torvalds
On Sun, Feb 9, 2014 at 5:16 PM, Torvald Riegel trie...@redhat.com wrote: (a) seems to say that you don't like requiring programmers to mark atomic accesses specially. Is that the case? In Paul's example, they were marked specially. And you seemed to argue that Paul's example could possibly

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

2014-02-09 Thread Torvald Riegel
On Sun, 2014-02-09 at 17:24 -0800, Linus Torvalds wrote: On Sun, Feb 9, 2014 at 5:16 PM, Torvald Riegel trie...@redhat.com wrote: (a) seems to say that you don't like requiring programmers to mark atomic accesses specially. Is that the case? In Paul's example, they were marked

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

2014-02-09 Thread Linus Torvalds
On Sun, Feb 9, 2014 at 5:46 PM, Torvald Riegel trie...@redhat.com wrote: IOW, I wrote that such a compiler transformation would be wrong in my opinion. Thus, it should *not* return 42. Ahh, I am happy to have misunderstood. The intuitively threw me, because I thought that was building up to a

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

2014-02-09 Thread Paul E. McKenney
On Mon, Feb 10, 2014 at 01:27:51AM +0100, Torvald Riegel wrote: On Fri, 2014-02-07 at 10:02 -0800, Paul E. McKenney wrote: On Fri, Feb 07, 2014 at 04:55:48PM +, Will Deacon wrote: Hi Paul, On Fri, Feb 07, 2014 at 04:50:28PM +, Paul E. McKenney wrote: On Fri, Feb 07, 2014

<    1   2   3   4   5   6   >