On Wed, 2014-02-19 at 16:53 -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
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?
>
> Not as far as I know. Also, as far as I know, there is no difference
> between consume and relaxed in the
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
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 identical stores that the compiler
> > could pull
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
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 of
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, as far as I know, there is no difference
between consume and relaxed
On Wed, 2014-02-19 at 16:53 -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* contain any
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 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
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, but the consume(p) ? a : b would *not* have
such an ordering
On Wed, 2014-02-19 at 20:43 -0800, Linus Torvalds wrote:
[Paul has already answered many of your questions, and my reply to your
previous email should also answer some.]
If the consumer of an atomic load isn't a pointer chasing operation,
then the consume should be defined to be the same as
On Thu, 2014-02-20 at 00:30 -0800, Paul E. McKenney wrote:
Well, all the compilers currently convert consume to acquire, so you have
your wish there. Of course, that also means that they generate actual
unneeded memory-barrier instructions, which seems extremely sub-optimal
to me.
GCC
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.
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 to
On Thu, 2014-02-20 at 09:34 -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, but the
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
On Thu, 2014-02-20 at 09:01 -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, as
On Thu, Feb 20, 2014 at 9:49 AM, Torvald Riegel trie...@redhat.com wrote:
Yes, mo_consume is more tricky than mo_acquire.
However, that has an advantage because you can avoid getting stronger
barriers if you don't need them (ie, you can avoid the auto-update to
acquire you seem to have in
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,
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 that that is wrong, that the standard is badly written,
and should be fixed.
On Thu, 2014-02-20 at 10:11 -0800, Paul E. McKenney wrote:
But yes, the compiler guys would be extremely happy to simply drop
memory_order_consume from the standard, as it is the memory order
that they most love to hate.
Getting them to agree to any sort of peep-hole optimization semantics
On Thu, 2014-02-20 at 10:32 -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.
Huh?
The standard says that
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 that
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 to
On Thu, Feb 20, 2014 at 10:25 AM, Linus Torvalds
torva...@linux-foundation.org wrote:
While in my *sane* model, where you can consume things even if they
then result in control dependencies, there will still eventually be a
sync instruction on powerpc (because you really need one between the
On Thu, Feb 20, 2014 at 11:02 AM, Linus Torvalds
torva...@linux-foundation.org wrote:
Again, the way I'd expect a compiler writer to actually *do* this is
to just default to ac
Oops, pressed send by mistake too early.
I was almost done:
I'd expect a compiler to just default to acquire
On Thu, Feb 20, 2014 at 10:53 AM, Torvald Riegel trie...@redhat.com wrote:
On Thu, 2014-02-20 at 10:32 -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
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];
Then gcc optimized this to:
i = atomic_load(idx,
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];
On Thu, Feb 20, 2014 at 2:10 PM, Paul E. McKenney
paul...@linux.vnet.ibm.com wrote:
Linus, given that you are calling me out for pushing legalistic and bad
things, syntactic bullshit, and playing little games, I am forced
to conclude that you have never attended any sort of standards-committee
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 identical stores that the compiler
> could pull out of the "if" and merge. The same might also be true for ?:
> for all I
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
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 clarity of the model. It has a *lot* of
>> verbiage, but it's pretty
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
On Wed, Feb 19, 2014 at 6:40 AM, Torvald Riegel wrote:
>
> If all those other threads written in whichever way use the same memory
> model and ABI for synchronization (e.g., choice of HW barriers for a
> certain memory_order), it doesn't matter whether it's a hardware thread,
> microcode,
On Wed, 2014-02-19 at 07:23 -0800, David Lang wrote:
> On Tue, 18 Feb 2014, Torvald Riegel wrote:
>
> > On Tue, 2014-02-18 at 22:40 +0100, Peter Zijlstra wrote:
> >> On Tue, Feb 18, 2014 at 10:21:56PM +0100, Torvald Riegel wrote:
> >>> Well, that's how atomics that aren't volatile are defined in
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 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:
> > > >
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
On Tue, 18 Feb 2014, Torvald Riegel wrote:
On Tue, 2014-02-18 at 22:40 +0100, Peter Zijlstra wrote:
On Tue, Feb 18, 2014 at 10:21:56PM +0100, Torvald Riegel wrote:
Well, that's how atomics that aren't volatile are defined in the
standard. I can see that you want something else too, but that
On Tue, 2014-02-18 at 14:14 -0800, Linus Torvalds wrote:
> On Tue, Feb 18, 2014 at 1:21 PM, Torvald Riegel wrote:
> >>
> >> So imagine that you have some clever global optimizer that sees that
> >> the program never ever actually sets the dirty bit at all in any
> >> thread, and then uses that
On Wed, Feb 19, 2014 at 12:07:02PM +0100, Torvald Riegel wrote:
> > Its not only hardware; also the kernel/user boundary has this same
> > problem. We cannot a-priory say what userspace will do; in fact, because
> > we're a general purpose OS, we must assume it will willfully try its
> > bestest
On Tue, 2014-02-18 at 22:47 +0100, Peter Zijlstra wrote:
> On Tue, Feb 18, 2014 at 10:21:56PM +0100, Torvald Riegel wrote:
> > Yes, I do. But that seems to be "volatile" territory. It crosses the
> > boundaries of the abstract machine, and thus is input/output. Which
> > fraction of your atomic
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 at VMSDVM9)
> >
> > On Tue, 2014-02-18 at 09:16 -0800, Paul E.
On Tue, 2014-02-18 at 22:52 +0100, Peter Zijlstra wrote:
> > > 4.Some drivers allow user-mode code to mmap() some of their
> > > state. Any changes undertaken by the user-mode code would
> > > be invisible to the compiler.
> >
> > A good point, but a compiler that doesn't try to
On Tue, 2014-02-18 at 23:48 +, Peter Sewell wrote:
> On 18 February 2014 20:43, Torvald Riegel wrote:
> > On Tue, 2014-02-18 at 12:12 +, Peter Sewell wrote:
> >> Several of you have said that the standard and compiler should not
> >> permit speculative writes of atomics, or (effectively)
On Tue, 2014-02-18 at 23:48 +, Peter Sewell wrote:
On 18 February 2014 20:43, Torvald Riegel trie...@redhat.com wrote:
On Tue, 2014-02-18 at 12:12 +, Peter Sewell wrote:
Several of you have said that the standard and compiler should not
permit speculative writes of atomics, or
On Tue, 2014-02-18 at 22:52 +0100, Peter Zijlstra wrote:
4.Some drivers allow user-mode code to mmap() some of their
state. Any changes undertaken by the user-mode code would
be invisible to the compiler.
A good point, but a compiler that doesn't try to (incorrectly)
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 at VMSDVM9)
On Tue, 2014-02-18 at 09:16 -0800, Paul E. McKenney
On Tue, 2014-02-18 at 22:47 +0100, Peter Zijlstra wrote:
On Tue, Feb 18, 2014 at 10:21:56PM +0100, Torvald Riegel wrote:
Yes, I do. But that seems to be volatile territory. It crosses the
boundaries of the abstract machine, and thus is input/output. Which
fraction of your atomic accesses
On Wed, Feb 19, 2014 at 12:07:02PM +0100, Torvald Riegel wrote:
Its not only hardware; also the kernel/user boundary has this same
problem. We cannot a-priory say what userspace will do; in fact, because
we're a general purpose OS, we must assume it will willfully try its
bestest to wreck
On Tue, 2014-02-18 at 14:14 -0800, Linus Torvalds wrote:
On Tue, Feb 18, 2014 at 1:21 PM, Torvald Riegel trie...@redhat.com wrote:
So imagine that you have some clever global optimizer that sees that
the program never ever actually sets the dirty bit at all in any
thread, and then uses
On Tue, 18 Feb 2014, Torvald Riegel wrote:
On Tue, 2014-02-18 at 22:40 +0100, Peter Zijlstra wrote:
On Tue, Feb 18, 2014 at 10:21:56PM +0100, Torvald Riegel wrote:
Well, that's how atomics that aren't volatile are defined in the
standard. I can see that you want something else too, but that
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 at
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 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:
On Wed, 2014-02-19 at 07:23 -0800, David Lang wrote:
On Tue, 18 Feb 2014, Torvald Riegel wrote:
On Tue, 2014-02-18 at 22:40 +0100, Peter Zijlstra wrote:
On Tue, Feb 18, 2014 at 10:21:56PM +0100, Torvald Riegel wrote:
Well, that's how atomics that aren't volatile are defined in the
On Wed, Feb 19, 2014 at 6:40 AM, Torvald Riegel trie...@redhat.com wrote:
If all those other threads written in whichever way use the same memory
model and ABI for synchronization (e.g., choice of HW barriers for a
certain memory_order), it doesn't matter whether it's a hardware thread,
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 the
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* contain any clarity of the model. It has a *lot* of
verbiage, but it's
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*
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
could pull out of the if and merge. The same might also be true for
On 18 February 2014 20:43, Torvald Riegel wrote:
> On Tue, 2014-02-18 at 12:12 +, 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
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
On Tue, Feb 18, 2014 at 1:21 PM, Torvald Riegel wrote:
>>
>> So imagine that you have some clever global optimizer that sees that
>> the program never ever actually sets the dirty bit at all in any
>> thread, and then uses that kind of non-local knowledge to make
>> optimization decisions. THAT
> > 4. Some drivers allow user-mode code to mmap() some of their
> > state. Any changes undertaken by the user-mode code would
> > be invisible to the compiler.
>
> A good point, but a compiler that doesn't try to (incorrectly) assume
> something about the semantics of mmap will simply
On Tue, Feb 18, 2014 at 10:21:56PM +0100, Torvald Riegel wrote:
> Yes, I do. But that seems to be "volatile" territory. It crosses the
> boundaries of the abstract machine, and thus is input/output. Which
> fraction of your atomic accesses can read values produced by hardware?
> I would still
On Tue, 2014-02-18 at 22:40 +0100, Peter Zijlstra wrote:
> On Tue, Feb 18, 2014 at 10:21:56PM +0100, Torvald Riegel wrote:
> > Well, that's how atomics that aren't volatile are defined in the
> > standard. I can see that you want something else too, but that doesn't
> > mean that the other thing
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 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
On Tue, Feb 18, 2014 at 10:21:56PM +0100, Torvald Riegel wrote:
> Well, that's how atomics that aren't volatile are defined in the
> standard. I can see that you want something else too, but that doesn't
> mean that the other thing is broken.
Well that other thing depends on being able to see
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
On Tue, 2014-02-18 at 08:49 -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 - and
On Tue, 2014-02-18 at 18:21 +, Peter Sewell wrote:
> On 18 February 2014 17:38, Linus Torvalds
> wrote:
> > On Tue, Feb 18, 2014 at 4:12 AM, Peter Sewell
> > wrote:
> >>
> >> For example, suppose we have, in one compilation unit:
> >>
> >> void f(int ra, int*rb) {
> >> if
On Tue, 2014-02-18 at 12:12 +, 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
On Tue, 2014-02-18 at 08:55 -0800, Paul E. McKenney wrote:
> 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
On Tue, 2014-02-18 at 09:44 -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 I can find a
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,
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, 2014-02-17 at 16:05 -0800, Linus
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?
On Tue, Feb 18, 2014 at 10:23 AM, Peter Sewell
wrote:
>
> interesting list. So are you saying that value-range-analysis and
> such-like (I say glibly, without really knowing what "such-like"
> refers to here) are fundamentally incompatible with
> the kernel code
No, it's fine to do things like
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 a concurrent context.
So I agree, but I think that's a generic issue with
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, 2014-02-17 at 16:05 -0800, Linus Torvalds wrote:
>> >> And exactly because I know enough, I would *really*
On 18 February 2014 17:38, Linus Torvalds wrote:
> On Tue, Feb 18, 2014 at 4:12 AM, Peter Sewell
> wrote:
>>
>> For example, suppose we have, in one compilation unit:
>>
>> void f(int ra, int*rb) {
>> if (ra==42)
>> *rb=42;
>> else
>> *rb=42;
>> }
>
> So this
On Mon, 2014-02-17 at 16:09 -0800, Linus Torvalds wrote:
> On Mon, Feb 17, 2014 at 3:17 PM, Torvald Riegel wrote:
> > On Mon, 2014-02-17 at 14:32 -0800,
> >
> >> Stop claiming it "can return 1".. It *never* returns 1 unless you do
> >> the load and *verify* it, or unless the load itself can be
On Tue, Feb 18, 2014 at 8:17 AM, Torvald Riegel wrote:
>>
>> "Consume operation: no reads in the current thread dependent on the
>> value currently loaded can be reordered before this load"
>
> I can't remember seeing that language in the standard (ie, C or C++).
> Where is this from?
That's
On Tue, Feb 18, 2014 at 4:12 AM, Peter Sewell wrote:
>
> For example, suppose we have, in one compilation unit:
>
> void f(int ra, int*rb) {
> if (ra==42)
> *rb=42;
> else
> *rb=42;
> }
So this is a great example, and in general I really like your page at:
>
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
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
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
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:
> > > >
> > > > Which example do
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 - and *local* - rules about how they
>> can be combined and optimized.
>
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 not
> >> permit speculative
On Mon, 2014-02-17 at 19:42 -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).
>
> Hmm. The
On 18 February 2014 12:53, Peter Zijlstra 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 speculative writes of atomics, or (effectively) that the
>> compiler should preserve dependencies.
>
>
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:
> > >
> > > Which example do you have in mind here? Haven't we resolved all the
> > > debated examples, or did
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 about here: "no sense" is a ultimately a
> > matter of
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 not
>> permit speculative writes of atomics, or (effectively) that the
>> compiler should preserve
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 - and *local* - rules about how they
> can be combined and optimized.
"Local"?
> None of this "if you can prove that the read has
Hi Paul,
Thanks for the document. I'm looking forward to reading the bits about
dependency chains in Linux.
> One point of confusion for me... Example 4 says "language must allow".
> Shouldn't that be "language is permitted to allow"?
When we say "allow", we mean that the optimised execution
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
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.
The example below only deals with control dependencies; so
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 general it's not so clear what the
language should guarantee,
201 - 300 of 570 matches
Mail list logo
