From: Linus Torvalds <torvalds@linux-foundation.org>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>,
Zhang Rui <rui.zhang@intel.com>,
LKML <linux-kernel@vger.kernel.org>,
ACPI Devel Maling List <linux-acpi@vger.kernel.org>,
pm list <linux-pm@lists.linux-foundation.org>
Subject: Re: Async resume patch (was: Re: [GIT PULL] PM updates for 2.6.33)
Date: Wed, 9 Dec 2009 13:52:44 -0800 (PST) [thread overview]
Message-ID: <alpine.LFD.2.00.0912091317330.3560@localhost.localdomain> (raw)
In-Reply-To: <Pine.LNX.4.44L0.0912091356200.4120-100000@iolanthe.rowland.org>
On Wed, 9 Dec 2009, Alan Stern wrote:
>
> That could be attributed to reordering on CPU2, so let's take CPU2's
> peculiarities out of the picture (initially everything is set to 0):
>
> CPU1 CPU2
> ---- ----
> if (x == 1) z = y;
> y = 5; mb();
> x = 1;
>
> This gets at the heart of the question: Can a write move up past a
> control dependency?
> [ .. ]
> Can z end up equal to 5 in any of these examples?
In any _practical_ microarchitecture I know of, the above will never
result in 'z' being 5, even though CPU1 doesn't really have a memory
barrier. But if I read the alpha memory ordering guarantees rigth, then at
least in theory you really can end up with z=5.
Let me write that as five events (with the things in brackets being what
the alpha memory ordering manual calls them):
- A is "read of x returns 1" on CPU1 [ P1:R(x,1) ]
- B is "write of value 5 to y" on CPU1 [ P1:W(y,5) ]
- C is "read of y returns 5" on CPU2 [ P2:R(y,5) ]
- D is "write of value 1 to x" on CPU2 [ P2:W(x,1) ]
- 'MB' is the mb() on CPU2 [ P2:MB ]
(The write of 'z' is irrelevant, we can think of it as a register, the end
result is the same).
And yes, if I read the alpha memory ordering rules correctly, you really
can end up with z=5, although I don't think you will ever find an alpha
_implementation_ that does it.
Why?
The alpha memory ordering literally defines ordering in two ways:
- "location access order". But that is _only_ defined per actual
location, so while 'x' can have a location access order specified by
seeing certain values, there is no "location access order" for two
different memory locations (x and y).
The alpha architecture manual uses "A << B" to say "event A" is before
"event B" when there is a defined ordering.
So in the example above, there is a location access ordering between
P2:W(x,1) << P1:R(x, 1)
and
P2:R(y,5) << P1:W(y,5)
ie you have D << A and B << C.
Good so far, but that doesn't define anything else: there's only
ordering between the pairs (D,A) and (B,C), nothing between them.
- "Processor issue order" for two instruction is _only_ defined by either
(a) memory barriers or (b) accesses to the _same_ locations. The alpha
architecture manual uses "A < B" to say that "event A" is before "event
B" in processor issue order.
So there is a "Processor issue order" on CPU2 due to the memory
barrier: P2:R(y,5) < P2:MB < P2:W(x,1), or put another way C < MB < D:
C < D.
Now, the question is, can we actually get the behaviour of reading 5 on
CPU2 (ie P2:R(y,5)), and that is only possible if we can find an ordering
that satisfies all the constraints. We have
D << A
B << C
C < D
and it seems to be that it is a possible situation: "B C D A"
really does satisfy all the constraints afaik.
So yes, according to the actual alpha architecture memory ordering rules,
you can see '5' from that first read of 'y'. DESPITE having a mb() on
CPU2.
In order to not see 5, you need to also specify "A < B", and the _only_
way to do that processor issue order specification is with a memory
barrier (or if the locations are the same, which they aren't).
"Causality" simply is nowhere in the officially defined alpha memory
ordering. The fact that we test 'x == 1' and conditionally do the write
simply doesn't enter the picture. I suspect you'd have a really hard time
not having causality in practice, but there _are_ things that can break
causality (value prediction etc), so it's not like you'd have to actually
violate physics of reality to do it.
IOW, you could at least in theory implement a CPU that does every
instruction speculatively in parallel, and then validates the end result
afterwards according to the architecture rules. And that CPU would require
the memory barrier on alpha.
(On x86, 'causality' is defined to be part of the memory ordering rules,
so on x86, you _do_ have a 'A < B' relationship. But not on alpha).
Linus
next prev parent reply other threads:[~2009-12-09 21:54 UTC|newest]
Thread overview: 234+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-12-05 21:16 [GIT PULL] PM updates for 2.6.33 Rafael J. Wysocki
2009-12-05 21:43 ` Linus Torvalds
2009-12-05 21:58 ` Linus Torvalds
2009-12-05 23:55 ` Rafael J. Wysocki
2009-12-06 0:45 ` Arjan van de Ven
2009-12-06 1:26 ` Rafael J. Wysocki
2009-12-06 1:58 ` Arjan van de Ven
2009-12-06 8:39 ` Ingo Molnar
2009-12-06 0:48 ` Linus Torvalds
2009-12-06 1:54 ` Rafael J. Wysocki
2009-12-06 1:57 ` Rafael J. Wysocki
2009-12-06 2:05 ` Linus Torvalds
2009-12-06 2:36 ` Rafael J. Wysocki
2009-12-06 15:23 ` Alan Stern
2009-12-06 19:04 ` [linux-pm] " Victor Lowther
2009-12-07 3:57 ` Zhang Rui
2009-12-07 5:57 ` Linus Torvalds
2009-12-07 6:15 ` Linus Torvalds
2009-12-17 23:28 ` Benjamin Herrenschmidt
2009-12-07 6:37 ` Arjan van de Ven
2009-12-07 15:13 ` Alan Stern
2009-12-07 16:31 ` Linus Torvalds
2009-12-07 16:55 ` Linus Torvalds
2009-12-07 17:52 ` Alan Stern
2009-12-07 18:05 ` Linus Torvalds
2009-12-07 20:37 ` Alan Stern
2009-12-07 20:48 ` Linus Torvalds
2009-12-07 21:32 ` Alan Stern
2009-12-07 21:41 ` Linus Torvalds
2009-12-07 21:47 ` Rafael J. Wysocki
2009-12-07 22:01 ` Alan Stern
2009-12-07 22:06 ` Linus Torvalds
2009-12-07 22:21 ` Alan Stern
2009-12-07 22:26 ` Linus Torvalds
2009-12-07 23:16 ` Alan Stern
2009-12-07 22:02 ` Rafael J. Wysocki
2009-12-07 22:16 ` Linus Torvalds
2009-12-07 23:51 ` Rafael J. Wysocki
2009-12-08 3:27 ` Alan Stern
2009-12-08 12:23 ` Async resume patch (was: Re: [GIT PULL] PM updates for 2.6.33) Rafael J. Wysocki
2009-12-08 12:35 ` Rafael J. Wysocki
2009-12-08 15:35 ` Linus Torvalds
2009-12-08 15:55 ` Alan Stern
2009-12-08 16:42 ` Linus Torvalds
2009-12-08 18:08 ` Alan Stern
2009-12-08 18:41 ` Linus Torvalds
2009-12-08 18:52 ` Linus Torvalds
2009-12-08 19:34 ` Alan Stern
2009-12-08 19:30 ` Alan Stern
2009-12-08 20:48 ` Linus Torvalds
2009-12-08 21:32 ` Alan Stern
2009-12-08 21:52 ` Christian Borntraeger
2009-12-08 22:16 ` Linus Torvalds
2009-12-09 19:06 ` Alan Stern
2009-12-09 21:52 ` Linus Torvalds [this message]
2009-12-08 19:44 ` Rafael J. Wysocki
2009-12-08 20:16 ` Alan Stern
2009-12-08 20:30 ` Rafael J. Wysocki
2009-12-08 20:44 ` Alan Stern
2009-12-08 20:52 ` Rafael J. Wysocki
2009-12-08 21:40 ` Alan Stern
2009-12-08 21:48 ` spinlock in completion_done() (was: Re: Async resume patch (was: Re: [GIT PULL] PM updates for 2.6.33)) Rafael J. Wysocki
2009-12-09 9:29 ` Ingo Molnar
2009-12-09 22:37 ` Rafael J. Wysocki
2009-12-10 7:59 ` Ingo Molnar
2009-12-11 4:10 ` Dave Chinner
2009-12-11 7:54 ` Ingo Molnar
2009-12-12 23:07 ` [PATCH] sched: Make wakeup side variants of completion API irq safe (was: Re: spinlock in completion_done()) Rafael J. Wysocki
2009-12-08 22:18 ` Async resume patch (was: Re: [GIT PULL] PM updates for 2.6.33) Linus Torvalds
2009-12-09 2:11 ` Alan Stern
2009-12-08 21:08 ` Linus Torvalds
2009-12-08 21:13 ` Linus Torvalds
2009-12-08 22:07 ` Alan Stern
2009-12-08 22:30 ` Rafael J. Wysocki
2009-12-09 2:23 ` Alan Stern
2009-12-09 21:56 ` Rafael J. Wysocki
2009-12-09 22:27 ` Alan Stern
2009-12-08 22:32 ` Linus Torvalds
2009-12-09 2:35 ` Alan Stern
2009-12-09 2:54 ` Linus Torvalds
2009-12-09 15:24 ` Alan Stern
2009-12-09 15:38 ` Linus Torvalds
2009-12-09 15:57 ` Alan Stern
2009-12-25 17:09 ` Pavel Machek
2009-12-09 13:38 ` Mark Brown
2009-12-09 15:49 ` Alan Stern
2009-12-09 16:02 ` Mark Brown
2009-12-09 16:23 ` Alan Stern
2009-12-09 16:46 ` Mark Brown
2009-12-09 16:57 ` Linus Torvalds
2009-12-09 17:45 ` Mark Brown
2009-12-09 17:57 ` Linus Torvalds
2009-12-09 18:27 ` Mark Brown
2009-12-09 17:10 ` Alan Stern
2009-12-09 17:19 ` Linus Torvalds
2009-12-09 18:08 ` Mark Brown
2009-12-08 21:04 ` Linus Torvalds
2009-12-08 21:40 ` Rafael J. Wysocki
2009-12-08 22:03 ` Rafael J. Wysocki
2009-12-08 22:55 ` Async suspend-resume patch w/ rwsems " Rafael J. Wysocki
2009-12-08 23:24 ` Rafael J. Wysocki
2009-12-09 20:15 ` Alan Stern
2009-12-09 22:18 ` Rafael J. Wysocki
2009-12-09 22:38 ` Alan Stern
2009-12-09 23:18 ` Async suspend-resume patch w/ completions (was: Re: Async suspend-resume patch w/ rwsems) Rafael J. Wysocki
2009-12-10 2:51 ` Linus Torvalds
2009-12-10 19:40 ` Rafael J. Wysocki
2009-12-10 23:30 ` Linus Torvalds
2009-12-11 1:02 ` Rafael J. Wysocki
2009-12-11 1:25 ` Linus Torvalds
2009-12-11 3:42 ` Alan Stern
2009-12-11 22:17 ` Rafael J. Wysocki
2009-12-12 0:38 ` Alan Stern
2009-12-11 22:11 ` Rafael J. Wysocki
2009-12-11 22:31 ` Linus Torvalds
2009-12-11 23:48 ` Rafael J. Wysocki
2009-12-11 23:53 ` Linus Torvalds
2009-12-12 17:48 ` Rafael J. Wysocki
2009-12-12 18:54 ` Linus Torvalds
2009-12-12 22:34 ` Rafael J. Wysocki
2009-12-12 22:40 ` Rafael J. Wysocki
2009-12-14 18:21 ` Linus Torvalds
2009-12-14 22:11 ` Rafael J. Wysocki
2009-12-14 22:41 ` Linus Torvalds
2009-12-14 22:43 ` Linus Torvalds
2009-12-14 23:18 ` Rafael J. Wysocki
2009-12-15 0:10 ` Linus Torvalds
2009-12-15 0:11 ` Linus Torvalds
2009-12-15 11:14 ` Rafael J. Wysocki
2009-12-15 15:31 ` Linus Torvalds
2009-12-15 11:03 ` Rafael J. Wysocki
2009-12-15 15:26 ` Linus Torvalds
2009-12-15 15:55 ` Alan Stern
2009-12-15 16:28 ` Linus Torvalds
2009-12-15 18:57 ` Linus Torvalds
2009-12-15 20:26 ` Alan Stern
2009-12-15 21:26 ` Rafael J. Wysocki
2009-12-15 22:01 ` Alan Stern
2009-12-15 21:54 ` Linus Torvalds
2009-12-15 22:27 ` Alan Stern
2009-12-16 2:11 ` Rafael J. Wysocki
2009-12-16 6:40 ` Dmitry Torokhov
2009-12-18 22:43 ` Rafael J. Wysocki
2009-12-19 19:59 ` Dmitry Torokhov
2009-12-19 21:33 ` Rafael J. Wysocki
2009-12-19 22:29 ` Rafael J. Wysocki
2009-12-19 22:43 ` Dmitry Torokhov
2009-12-19 22:47 ` Dmitry Torokhov
2009-12-19 23:10 ` Rafael J. Wysocki
2009-12-19 23:22 ` Dmitry Torokhov
2009-12-19 23:33 ` Rafael J. Wysocki
2009-12-19 23:23 ` Linus Torvalds
2009-12-19 23:40 ` Rafael J. Wysocki
2009-12-19 23:46 ` Linus Torvalds
2009-12-19 23:47 ` Linus Torvalds
2009-12-19 23:54 ` Rafael J. Wysocki
2009-12-19 23:53 ` Rafael J. Wysocki
2009-12-20 0:09 ` Linus Torvalds
2009-12-20 0:35 ` Rafael J. Wysocki
2009-12-20 2:41 ` Dmitry Torokhov
2009-12-20 19:25 ` [linux-pm] " Rafael J. Wysocki
2009-12-21 7:39 ` [linux-pm] Async suspend-resume patch w/ completions (was: Re: Async?suspend-resume " Dmitry Torokhov
2009-12-21 11:20 ` Vojtech Pavlik
2009-12-20 2:45 ` Async suspend-resume patch w/ completions (was: Re: Async suspend-resume " Dmitry Torokhov
2009-12-20 3:59 ` Alan Stern
2009-12-20 12:52 ` Rafael J. Wysocki
2009-12-20 17:12 ` Alan Stern
2009-12-20 18:10 ` Rafael J. Wysocki
2009-12-20 19:38 ` Alan Stern
2009-12-20 19:51 ` Rafael J. Wysocki
2009-12-16 15:22 ` Alan Stern
2009-12-16 19:26 ` Rafael J. Wysocki
2009-12-16 15:47 ` Linus Torvalds
2009-12-16 19:27 ` Rafael J. Wysocki
2009-12-16 20:59 ` Linus Torvalds
2009-12-16 21:57 ` Rafael J. Wysocki
2009-12-16 22:11 ` Linus Torvalds
2009-12-16 22:33 ` Rafael J. Wysocki
2009-12-16 23:04 ` Alan Stern
2009-12-16 23:18 ` Rafael J. Wysocki
2009-12-17 1:30 ` Rafael J. Wysocki
2009-12-17 1:49 ` Rafael J. Wysocki
2009-12-17 20:06 ` Alan Stern
2009-12-17 20:36 ` Rafael J. Wysocki
2009-12-18 1:51 ` Rafael J. Wysocki
2009-12-18 17:26 ` Alan Stern
2009-12-19 21:41 ` Rafael J. Wysocki
2009-12-20 3:48 ` Alan Stern
2009-12-20 12:55 ` Rafael J. Wysocki
2009-12-18 23:42 ` Rafael J. Wysocki
2009-12-13 13:08 ` Rafael J. Wysocki
2009-12-13 17:30 ` Alan Stern
2009-12-13 19:02 ` [linux-pm] " Alan Stern
2009-12-12 0:43 ` Alan Stern
2009-12-12 17:35 ` Rafael J. Wysocki
2009-12-10 15:31 ` Alan Stern
2009-12-10 15:45 ` Linus Torvalds
2009-12-10 18:37 ` Alan Stern
2009-12-10 23:51 ` Linus Torvalds
2009-12-10 21:14 ` Rafael J. Wysocki
2009-12-10 22:17 ` Alan Stern
2009-12-10 23:45 ` Rafael J. Wysocki
2009-12-07 15:15 ` [GIT PULL] PM updates for 2.6.33 Rafael J. Wysocki
2009-12-07 16:37 ` Linus Torvalds
2009-12-07 20:47 ` Rafael J. Wysocki
2009-12-07 20:56 ` Linus Torvalds
2009-12-07 5:20 ` Linus Torvalds
2009-12-07 15:42 ` Alan Stern
2009-12-06 19:35 ` Arjan van de Ven
2009-12-06 19:58 ` Linus Torvalds
2009-12-06 20:18 ` Arjan van de Ven
2009-12-06 21:08 ` Linus Torvalds
2009-12-06 22:54 ` Dmitry Torokhov
2009-12-07 0:55 ` Arjan van de Ven
2009-12-07 2:27 ` Dmitry Torokhov
2009-12-07 5:26 ` Arjan van de Ven
2009-12-07 6:00 ` Dmitry Torokhov
2009-12-21 9:01 ` Pavel Machek
2009-12-07 1:18 ` Arjan van de Ven
2009-12-07 2:27 ` Dmitry Torokhov
2009-12-07 5:31 ` Arjan van de Ven
2009-12-07 6:15 ` Dmitry Torokhov
2009-12-07 6:31 ` Arjan van de Ven
2009-12-07 6:32 ` Dmitry Torokhov
2009-12-07 15:17 ` Rafael J. Wysocki
2009-12-06 20:36 ` Alan Stern
2009-12-06 21:17 ` Arjan van de Ven
2009-12-06 21:46 ` Alan Stern
2009-12-06 21:57 ` Arjan van de Ven
2009-12-06 22:04 ` Alan Stern
2009-12-06 0:29 ` Rafael J. Wysocki
2009-12-06 0:52 ` Linus Torvalds
2009-12-06 1:24 ` Rafael J. Wysocki
2009-12-06 1:50 ` Linus Torvalds
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.LFD.2.00.0912091317330.3560@localhost.localdomain \
--to=torvalds@linux-foundation.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@lists.linux-foundation.org \
--cc=rjw@sisk.pl \
--cc=rui.zhang@intel.com \
--cc=stern@rowland.harvard.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox