From: "H. Peter Anvin" <hpa@zytor.com>
To: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: paulmck@linux.vnet.ibm.com,
Peter Hurley <peter@hurleysoftware.com>,
One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>,
Jakub Jelinek <jakub@redhat.com>,
Mikael Pettersson <mikpelinux@gmail.com>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Richard Henderson <rth@twiddle.net>,
Oleg Nesterov <oleg@redhat.com>,
Miroslav Franc <mfranc@redhat.com>,
Paul Mackerras <paulus@samba.org>,
linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
linux-arch@vger.kernel.org, Tony Luck <tony.luck@intel.com>,
linux-ia64@vger.kernel.org
Subject: Re: bit fields && data tearing
Date: Mon, 08 Sep 2014 19:30:29 -0700 [thread overview]
Message-ID: <540E6645.6040209@zytor.com> (raw)
In-Reply-To: <1410215994.2027.86.camel@jarvis.lan>
On 09/08/2014 03:39 PM, James Bottomley wrote:
>
> I don't understand what you mean by "pass each other". Atomicity
> guarantees are not ordering guarantees in a SMP environment. The
> guarantee is that if you follow the rules when two CPUs update the same
> natural width aligned object simultaneously using the same primitive,
> the result is either one or the other of their updates. Which one wins
> (the ordering) isn't defined.
>
I'm trying to figure out why it would possibly make a difference in any
kind of sane system if gcc fuses accesses.
Assuming bigendian for the moment, I would expect that if CPU 1 does a
write of 0x01020304 to address 0 and CPU 2 does a write of 0x0506 to
address 2, that the end result would be either 0x01020304 or 0x01020506.
Similarly, I would expect that if these operations are both done on the
same CPU in that order, that the result would unambiguously be 0x01020506.
I would strongly suspect an architecture which does not provide those
guarantees is an outlier.
-hpa
WARNING: multiple messages have this Message-ID (diff)
From: "H. Peter Anvin" <hpa@zytor.com>
To: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: paulmck@linux.vnet.ibm.com,
Peter Hurley <peter@hurleysoftware.com>,
One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>,
Jakub Jelinek <jakub@redhat.com>,
Mikael Pettersson <mikpelinux@gmail.com>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Richard Henderson <rth@twiddle.net>,
Oleg Nesterov <oleg@redhat.com>,
Miroslav Franc <mfranc@redhat.com>,
Paul Mackerras <paulus@samba.org>,
linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
linux-arch@vger.kernel.org, Tony Luck <tony.luck@intel.com>,
linux-ia64@vger.kernel.org
Subject: Re: bit fields && data tearing
Date: Tue, 09 Sep 2014 02:30:29 +0000 [thread overview]
Message-ID: <540E6645.6040209@zytor.com> (raw)
In-Reply-To: <1410215994.2027.86.camel@jarvis.lan>
On 09/08/2014 03:39 PM, James Bottomley wrote:
>
> I don't understand what you mean by "pass each other". Atomicity
> guarantees are not ordering guarantees in a SMP environment. The
> guarantee is that if you follow the rules when two CPUs update the same
> natural width aligned object simultaneously using the same primitive,
> the result is either one or the other of their updates. Which one wins
> (the ordering) isn't defined.
>
I'm trying to figure out why it would possibly make a difference in any
kind of sane system if gcc fuses accesses.
Assuming bigendian for the moment, I would expect that if CPU 1 does a
write of 0x01020304 to address 0 and CPU 2 does a write of 0x0506 to
address 2, that the end result would be either 0x01020304 or 0x01020506.
Similarly, I would expect that if these operations are both done on the
same CPU in that order, that the result would unambiguously be 0x01020506.
I would strongly suspect an architecture which does not provide those
guarantees is an outlier.
-hpa
WARNING: multiple messages have this Message-ID (diff)
From: "H. Peter Anvin" <hpa@zytor.com>
To: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: Jakub Jelinek <jakub@redhat.com>,
One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>,
Tony Luck <tony.luck@intel.com>,
linux-ia64@vger.kernel.org,
Peter Hurley <peter@hurleysoftware.com>,
Mikael Pettersson <mikpelinux@gmail.com>,
Oleg Nesterov <oleg@redhat.com>,
linux-kernel@vger.kernel.org, Paul Mackerras <paulus@samba.org>,
linux-arch@vger.kernel.org, paulmck@linux.vnet.ibm.com,
linuxppc-dev@lists.ozlabs.org, Miroslav Franc <mfranc@redhat.com>,
Richard Henderson <rth@twiddle.net>
Subject: Re: bit fields && data tearing
Date: Mon, 08 Sep 2014 19:30:29 -0700 [thread overview]
Message-ID: <540E6645.6040209@zytor.com> (raw)
In-Reply-To: <1410215994.2027.86.camel@jarvis.lan>
On 09/08/2014 03:39 PM, James Bottomley wrote:
>
> I don't understand what you mean by "pass each other". Atomicity
> guarantees are not ordering guarantees in a SMP environment. The
> guarantee is that if you follow the rules when two CPUs update the same
> natural width aligned object simultaneously using the same primitive,
> the result is either one or the other of their updates. Which one wins
> (the ordering) isn't defined.
>
I'm trying to figure out why it would possibly make a difference in any
kind of sane system if gcc fuses accesses.
Assuming bigendian for the moment, I would expect that if CPU 1 does a
write of 0x01020304 to address 0 and CPU 2 does a write of 0x0506 to
address 2, that the end result would be either 0x01020304 or 0x01020506.
Similarly, I would expect that if these operations are both done on the
same CPU in that order, that the result would unambiguously be 0x01020506.
I would strongly suspect an architecture which does not provide those
guarantees is an outlier.
-hpa
next prev parent reply other threads:[~2014-09-09 2:30 UTC|newest]
Thread overview: 311+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-12 18:13 bit fields && data tearing Oleg Nesterov
2014-07-12 18:13 ` Oleg Nesterov
2014-07-12 20:51 ` Oleg Nesterov
2014-07-12 20:51 ` Oleg Nesterov
2014-07-12 23:34 ` Benjamin Herrenschmidt
2014-07-12 23:34 ` Benjamin Herrenschmidt
2014-07-13 12:29 ` Oleg Nesterov
2014-07-13 12:29 ` Oleg Nesterov
2014-07-13 13:15 ` Peter Hurley
2014-07-13 13:15 ` Peter Hurley
2014-07-13 22:25 ` Benjamin Herrenschmidt
2014-07-13 22:25 ` Benjamin Herrenschmidt
2014-07-15 13:54 ` Peter Hurley
2014-07-15 13:54 ` Peter Hurley
2014-07-15 15:02 ` Richard Henderson
2014-07-15 15:02 ` Richard Henderson
2014-09-03 22:51 ` Peter Hurley
2014-09-03 22:51 ` Peter Hurley
2014-09-03 22:51 ` Peter Hurley
2014-09-03 23:11 ` Benjamin Herrenschmidt
2014-09-03 23:11 ` Benjamin Herrenschmidt
2014-09-03 23:11 ` Benjamin Herrenschmidt
2014-09-03 23:11 ` Benjamin Herrenschmidt
2014-09-04 8:43 ` David Laight
2014-09-04 8:43 ` David Laight
2014-09-04 8:43 ` David Laight
2014-09-04 8:43 ` David Laight
2014-09-04 9:52 ` Benjamin Herrenschmidt
2014-09-04 9:52 ` Benjamin Herrenschmidt
2014-09-04 9:52 ` Benjamin Herrenschmidt
2014-09-04 22:14 ` H. Peter Anvin
2014-09-04 22:14 ` H. Peter Anvin
2014-09-04 22:14 ` H. Peter Anvin
2014-09-05 0:59 ` Peter Hurley
2014-09-05 0:59 ` Peter Hurley
2014-09-05 0:59 ` Peter Hurley
2014-09-05 2:08 ` H. Peter Anvin
2014-09-05 2:08 ` H. Peter Anvin
2014-09-05 2:08 ` H. Peter Anvin
2014-09-05 2:08 ` H. Peter Anvin
2014-09-05 15:31 ` Peter Hurley
2014-09-05 15:31 ` Peter Hurley
2014-09-05 15:31 ` Peter Hurley
2014-09-05 15:41 ` H. Peter Anvin
2014-09-05 15:41 ` H. Peter Anvin
2014-09-05 15:41 ` H. Peter Anvin
2014-09-08 17:52 ` One Thousand Gnomes
2014-09-08 17:52 ` One Thousand Gnomes
2014-09-08 17:52 ` One Thousand Gnomes
2014-09-08 17:59 ` H. Peter Anvin
2014-09-08 17:59 ` H. Peter Anvin
2014-09-08 17:59 ` H. Peter Anvin
2014-09-08 19:17 ` One Thousand Gnomes
2014-09-08 19:17 ` One Thousand Gnomes
2014-09-08 19:17 ` One Thousand Gnomes
2014-09-09 11:18 ` Peter Hurley
2014-09-09 11:18 ` Peter Hurley
2014-09-09 11:18 ` Peter Hurley
2014-09-08 22:47 ` Peter Hurley
2014-09-08 22:47 ` Peter Hurley
2014-09-08 22:47 ` Peter Hurley
2014-09-09 1:59 ` Paul E. McKenney
2014-09-09 1:59 ` Paul E. McKenney
2014-09-09 1:59 ` Paul E. McKenney
2014-09-09 11:14 ` Peter Hurley
2014-09-09 11:14 ` Peter Hurley
2014-09-09 11:14 ` Peter Hurley
2014-09-11 10:04 ` One Thousand Gnomes
2014-09-11 10:04 ` One Thousand Gnomes
2014-09-11 10:04 ` One Thousand Gnomes
2014-09-11 16:16 ` Paul E. McKenney
2014-09-11 16:16 ` Paul E. McKenney
2014-09-11 16:16 ` Paul E. McKenney
2014-09-11 20:01 ` Peter Hurley
2014-09-11 20:01 ` Peter Hurley
2014-09-11 20:01 ` Peter Hurley
2014-09-14 23:24 ` One Thousand Gnomes
2014-09-14 23:24 ` One Thousand Gnomes
2014-09-14 23:24 ` One Thousand Gnomes
2014-09-22 19:51 ` Paul E. McKenney
2014-09-22 19:51 ` Paul E. McKenney
2014-09-22 19:51 ` Paul E. McKenney
2014-09-23 18:19 ` Peter Hurley
2014-09-23 18:19 ` Peter Hurley
2014-09-23 18:19 ` Peter Hurley
2014-09-23 18:39 ` One Thousand Gnomes
2014-09-23 18:39 ` One Thousand Gnomes
2014-09-23 18:39 ` One Thousand Gnomes
2014-09-23 18:39 ` One Thousand Gnomes
2014-09-08 18:13 ` James Bottomley
2014-09-08 18:13 ` James Bottomley
2014-09-08 18:13 ` James Bottomley
2014-09-10 20:18 ` H. Peter Anvin
2014-09-10 20:18 ` H. Peter Anvin
2014-09-10 20:18 ` H. Peter Anvin
2014-09-10 21:10 ` Rob Landley
2014-09-10 21:10 ` Rob Landley
2014-09-10 21:10 ` Rob Landley
2014-09-05 2:08 ` H. Peter Anvin
2014-09-05 2:08 ` H. Peter Anvin
2014-09-05 2:08 ` H. Peter Anvin
2014-09-05 8:16 ` Michael Cree
2014-09-05 8:16 ` Michael Cree
2014-09-05 8:16 ` Michael Cree
2014-09-05 8:16 ` Michael Cree
2014-09-05 18:09 ` Paul E. McKenney
2014-09-05 18:09 ` Paul E. McKenney
2014-09-05 18:31 ` Paul E. McKenney
2014-09-05 18:31 ` Paul E. McKenney
2014-09-05 19:52 ` Peter Zijlstra
2014-09-05 19:52 ` Peter Zijlstra
2014-09-05 19:52 ` Peter Zijlstra
2014-09-05 20:01 ` Peter Hurley
2014-09-05 20:01 ` Peter Hurley
2014-09-05 20:01 ` Peter Hurley
2014-09-05 20:12 ` Peter Zijlstra
2014-09-05 20:12 ` Peter Zijlstra
2014-09-05 20:12 ` Peter Zijlstra
2014-09-05 20:15 ` H. Peter Anvin
2014-09-05 20:15 ` H. Peter Anvin
2014-09-05 20:15 ` H. Peter Anvin
2014-09-05 20:19 ` Paul E. McKenney
2014-09-05 20:19 ` Paul E. McKenney
2014-09-05 20:19 ` Paul E. McKenney
2014-09-05 18:50 ` Peter Hurley
2014-09-05 18:50 ` Peter Hurley
2014-09-05 19:05 ` Paul E. McKenney
2014-09-05 19:05 ` Paul E. McKenney
2014-09-05 19:05 ` Paul E. McKenney
2014-09-05 19:24 ` Peter Hurley
2014-09-05 19:24 ` Peter Hurley
2014-09-05 19:24 ` Peter Hurley
2014-09-05 20:09 ` Paul E. McKenney
2014-09-05 20:09 ` Paul E. McKenney
2014-09-05 20:09 ` Paul E. McKenney
2014-09-05 20:09 ` Paul E. McKenney
2014-09-05 19:38 ` Marc Gauthier
2014-09-05 19:38 ` Marc Gauthier
2014-09-05 19:38 ` Marc Gauthier
2014-09-05 20:14 ` Peter Hurley
2014-09-05 20:14 ` Peter Hurley
2014-09-05 20:14 ` Peter Hurley
2014-09-05 20:34 ` H. Peter Anvin
2014-09-05 20:34 ` H. Peter Anvin
2014-09-05 20:34 ` H. Peter Anvin
2014-09-05 20:42 ` Michael Cree
2014-09-05 20:42 ` Michael Cree
2014-09-05 20:42 ` Michael Cree
2014-09-05 20:43 ` Paul E. McKenney
2014-09-05 20:43 ` Paul E. McKenney
2014-09-05 20:43 ` Paul E. McKenney
2014-09-05 20:48 ` Thomas Gleixner
2014-09-05 20:48 ` Thomas Gleixner
2014-09-05 20:48 ` Thomas Gleixner
2014-09-05 21:05 ` Paul E. McKenney
2014-09-05 21:05 ` Paul E. McKenney
2014-09-05 21:05 ` Paul E. McKenney
2014-09-05 20:39 ` Michael Cree
2014-09-05 20:39 ` Michael Cree
2014-09-05 20:39 ` Michael Cree
2014-09-05 21:12 ` Peter Hurley
2014-09-05 21:12 ` Peter Hurley
2014-09-05 21:27 ` Michael Cree
2014-09-05 21:27 ` Michael Cree
2014-09-05 21:27 ` Michael Cree
2014-09-05 20:42 ` Paul E. McKenney
2014-09-05 20:42 ` Paul E. McKenney
2014-09-05 20:42 ` Paul E. McKenney
2014-09-04 8:57 ` Mikael Pettersson
2014-09-04 8:57 ` Mikael Pettersson
2014-09-04 8:57 ` Mikael Pettersson
2014-09-04 8:57 ` Mikael Pettersson
2014-09-04 9:09 ` Jakub Jelinek
2014-09-04 9:09 ` Jakub Jelinek
2014-09-04 9:09 ` Jakub Jelinek
2014-09-04 12:24 ` Peter Hurley
2014-09-04 12:24 ` Peter Hurley
2014-09-04 12:24 ` Peter Hurley
2014-09-04 12:29 ` Jakub Jelinek
2014-09-04 12:29 ` Jakub Jelinek
2014-09-04 12:29 ` Jakub Jelinek
2014-09-04 16:50 ` One Thousand Gnomes
2014-09-04 16:50 ` One Thousand Gnomes
2014-09-04 16:50 ` One Thousand Gnomes
2014-09-04 16:50 ` One Thousand Gnomes
2014-09-04 19:42 ` Peter Hurley
2014-09-04 19:42 ` Peter Hurley
2014-09-04 19:42 ` Peter Hurley
2014-09-04 22:16 ` H. Peter Anvin
2014-09-04 22:16 ` H. Peter Anvin
2014-09-04 22:16 ` H. Peter Anvin
2014-09-05 0:17 ` Paul E. McKenney
2014-09-05 0:17 ` Paul E. McKenney
2014-09-05 0:17 ` Paul E. McKenney
2014-09-05 1:57 ` Peter Hurley
2014-09-05 1:57 ` Peter Hurley
2014-09-05 1:57 ` Peter Hurley
2014-09-05 2:11 ` James Bottomley
2014-09-05 2:11 ` James Bottomley
2014-09-05 2:11 ` James Bottomley
2014-09-05 2:47 ` Peter Hurley
2014-09-05 2:47 ` Peter Hurley
2014-09-05 2:47 ` Peter Hurley
2014-09-05 4:06 ` Paul E. McKenney
2014-09-05 4:06 ` Paul E. McKenney
2014-09-05 4:06 ` Paul E. McKenney
2014-09-05 8:30 ` David Laight
2014-09-05 8:30 ` David Laight
2014-09-05 8:30 ` David Laight
2014-09-05 8:30 ` David Laight
2014-09-05 12:31 ` Peter Hurley
2014-09-05 12:31 ` Peter Hurley
2014-09-05 12:31 ` Peter Hurley
2014-09-05 12:37 ` David Laight
2014-09-05 12:37 ` David Laight
2014-09-05 12:37 ` David Laight
2014-09-05 12:37 ` David Laight
2014-09-05 16:17 ` Peter Hurley
2014-09-05 16:17 ` Peter Hurley
2014-09-05 16:17 ` Peter Hurley
2014-09-25 16:12 ` Pavel Machek
2014-09-25 16:12 ` Pavel Machek
2014-09-25 16:12 ` Pavel Machek
2014-09-07 5:07 ` James Bottomley
2014-09-07 5:07 ` James Bottomley
2014-09-07 5:07 ` James Bottomley
2014-09-07 16:21 ` Paul E. McKenney
2014-09-07 16:21 ` Paul E. McKenney
2014-09-07 16:21 ` Paul E. McKenney
2014-09-07 19:04 ` James Bottomley
2014-09-07 19:04 ` James Bottomley
2014-09-07 19:04 ` James Bottomley
2014-09-07 20:41 ` Peter Hurley
2014-09-07 20:41 ` Peter Hurley
2014-09-07 20:41 ` Peter Hurley
2014-09-08 5:50 ` James Bottomley
2014-09-08 5:50 ` James Bottomley
2014-09-08 5:50 ` James Bottomley
2014-09-08 20:45 ` Chris Metcalf
2014-09-08 20:45 ` Chris Metcalf
2014-09-08 20:45 ` Chris Metcalf
2014-09-08 20:45 ` Chris Metcalf
2014-09-08 22:43 ` James Bottomley
2014-09-08 22:43 ` James Bottomley
2014-09-08 22:43 ` James Bottomley
2014-09-09 2:27 ` H. Peter Anvin
2014-09-09 2:27 ` H. Peter Anvin
2014-09-09 2:27 ` H. Peter Anvin
2014-09-09 2:27 ` H. Peter Anvin
2014-09-09 8:11 ` Arnd Bergmann
2014-09-09 8:11 ` Arnd Bergmann
2014-09-09 8:11 ` Arnd Bergmann
2014-09-08 23:30 ` Peter Hurley
2014-09-08 23:30 ` Peter Hurley
2014-09-08 23:30 ` Peter Hurley
2014-09-09 2:56 ` James Bottomley
2014-09-09 2:56 ` James Bottomley
2014-09-09 2:56 ` James Bottomley
2014-09-09 3:20 ` H. Peter Anvin
2014-09-09 3:20 ` H. Peter Anvin
2014-09-09 3:20 ` H. Peter Anvin
2014-09-09 4:30 ` H. Peter Anvin
2014-09-09 4:30 ` H. Peter Anvin
2014-09-09 4:30 ` H. Peter Anvin
2014-09-09 4:30 ` H. Peter Anvin
2014-09-09 10:40 ` Peter Hurley
2014-09-09 10:40 ` Peter Hurley
2014-09-09 10:40 ` Peter Hurley
2014-09-10 21:48 ` James Bottomley
2014-09-10 21:48 ` James Bottomley
2014-09-10 21:48 ` James Bottomley
2014-09-10 23:50 ` Peter Hurley
2014-09-10 23:50 ` Peter Hurley
2014-09-10 23:50 ` Peter Hurley
2014-09-11 10:23 ` Will Deacon
2014-09-11 10:23 ` Will Deacon
2014-09-11 10:23 ` Will Deacon
2014-09-07 23:00 ` Paul E. McKenney
2014-09-07 23:00 ` Paul E. McKenney
2014-09-07 23:00 ` Paul E. McKenney
2014-09-07 23:17 ` H. Peter Anvin
2014-09-07 23:17 ` H. Peter Anvin
2014-09-07 23:17 ` H. Peter Anvin
2014-09-07 23:36 ` Paul E. McKenney
2014-09-07 23:36 ` Paul E. McKenney
2014-09-07 23:36 ` Paul E. McKenney
2014-09-07 23:39 ` H. Peter Anvin
2014-09-07 23:39 ` H. Peter Anvin
2014-09-07 23:39 ` H. Peter Anvin
2014-09-08 5:56 ` James Bottomley
2014-09-08 5:56 ` James Bottomley
2014-09-08 5:56 ` James Bottomley
2014-09-08 18:12 ` H. Peter Anvin
2014-09-08 18:12 ` H. Peter Anvin
2014-09-08 18:12 ` H. Peter Anvin
2014-09-08 19:09 ` James Bottomley
2014-09-08 19:09 ` James Bottomley
2014-09-08 19:09 ` James Bottomley
2014-09-08 19:12 ` H. Peter Anvin
2014-09-08 19:12 ` H. Peter Anvin
2014-09-08 19:12 ` H. Peter Anvin
2014-09-08 19:12 ` H. Peter Anvin
2014-09-08 22:39 ` James Bottomley
2014-09-08 22:39 ` James Bottomley
2014-09-08 22:39 ` James Bottomley
2014-09-09 2:30 ` H. Peter Anvin [this message]
2014-09-09 2:30 ` H. Peter Anvin
2014-09-09 2:30 ` H. Peter Anvin
2014-09-08 19:12 ` H. Peter Anvin
2014-09-08 19:12 ` H. Peter Anvin
2014-09-08 19:12 ` H. Peter Anvin
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=540E6645.6040209@zytor.com \
--to=hpa@zytor.com \
--cc=James.Bottomley@HansenPartnership.com \
--cc=benh@kernel.crashing.org \
--cc=gnomes@lxorguk.ukuu.org.uk \
--cc=jakub@redhat.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-ia64@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mfranc@redhat.com \
--cc=mikpelinux@gmail.com \
--cc=oleg@redhat.com \
--cc=paulmck@linux.vnet.ibm.com \
--cc=paulus@samba.org \
--cc=peter@hurleysoftware.com \
--cc=rth@twiddle.net \
--cc=tony.luck@intel.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.