From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756118AbaIICf5 (ORCPT ); Mon, 8 Sep 2014 22:35:57 -0400 Received: from terminus.zytor.com ([198.137.202.10]:34514 "EHLO mail.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752923AbaIICfy (ORCPT ); Mon, 8 Sep 2014 22:35:54 -0400 Message-ID: <540E6645.6040209@zytor.com> Date: Mon, 08 Sep 2014 19:30:29 -0700 From: "H. Peter Anvin" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0 MIME-Version: 1.0 To: James Bottomley CC: paulmck@linux.vnet.ibm.com, Peter Hurley , One Thousand Gnomes , Jakub Jelinek , Mikael Pettersson , Benjamin Herrenschmidt , Richard Henderson , Oleg Nesterov , Miroslav Franc , Paul Mackerras , linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, Tony Luck , linux-ia64@vger.kernel.org Subject: Re: bit fields && data tearing References: <5408C0AB.6050801@hurleysoftware.com> <20140905001751.GL5001@linux.vnet.ibm.com> <1409883098.5078.14.camel@jarvis.lan> <5409243C.4080704@hurleysoftware.com> <20140905040645.GO5001@linux.vnet.ibm.com> <1410066442.12512.13.camel@jarvis.lan> <20140907162146.GK5001@linux.vnet.ibm.com> <1410116687.2027.19.camel@jarvis.lan> <20140907230019.GO5001@linux.vnet.ibm.com> <6092b453-e0c9-4f6d-922b-48bce988f774@email.android.com> <20140907233655.GR5001@linux.vnet.ibm.com> <154b540a-df47-4f3e-bdda-ab5d2e72723a@email.android.com> <1410155802.2027.36.camel@jarvis.lan> <540DF17C.9080509@zytor.com> <1410203369.2027.56.camel@jarvis.lan> <540DFFB2.4000509@zytor.com> <1410215994.2027.86.camel@jarvis.lan> In-Reply-To: <1410215994.2027.86.camel@jarvis.lan> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.zytor.com (terminus.zytor.com [IPv6:2001:1868:205::10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 6816B1A0019 for ; Tue, 9 Sep 2014 12:35:43 +1000 (EST) Message-ID: <540E6645.6040209@zytor.com> Date: Mon, 08 Sep 2014 19:30:29 -0700 From: "H. Peter Anvin" MIME-Version: 1.0 To: James Bottomley Subject: Re: bit fields && data tearing References: <5408C0AB.6050801@hurleysoftware.com> <20140905001751.GL5001@linux.vnet.ibm.com> <1409883098.5078.14.camel@jarvis.lan> <5409243C.4080704@hurleysoftware.com> <20140905040645.GO5001@linux.vnet.ibm.com> <1410066442.12512.13.camel@jarvis.lan> <20140907162146.GK5001@linux.vnet.ibm.com> <1410116687.2027.19.camel@jarvis.lan> <20140907230019.GO5001@linux.vnet.ibm.com> <6092b453-e0c9-4f6d-922b-48bce988f774@email.android.com> <20140907233655.GR5001@linux.vnet.ibm.com> <154b540a-df47-4f3e-bdda-ab5d2e72723a@email.android.com> <1410155802.2027.36.camel@jarvis.lan> <540DF17C.9080509@zytor.com> <1410203369.2027.56.camel@jarvis.lan> <540DFFB2.4000509@zytor.com> <1410215994.2027.86.camel@jarvis.lan> In-Reply-To: <1410215994.2027.86.camel@jarvis.lan> Content-Type: text/plain; charset=UTF-8 Cc: Jakub Jelinek , One Thousand Gnomes , Tony Luck , linux-ia64@vger.kernel.org, Peter Hurley , Mikael Pettersson , Oleg Nesterov , linux-kernel@vger.kernel.org, Paul Mackerras , linux-arch@vger.kernel.org, paulmck@linux.vnet.ibm.com, linuxppc-dev@lists.ozlabs.org, Miroslav Franc , Richard Henderson List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: "H. Peter Anvin" Date: Tue, 09 Sep 2014 02:30:29 +0000 Subject: Re: bit fields && data tearing Message-Id: <540E6645.6040209@zytor.com> List-Id: References: <5408C0AB.6050801@hurleysoftware.com> <20140905001751.GL5001@linux.vnet.ibm.com> <1409883098.5078.14.camel@jarvis.lan> <5409243C.4080704@hurleysoftware.com> <20140905040645.GO5001@linux.vnet.ibm.com> <1410066442.12512.13.camel@jarvis.lan> <20140907162146.GK5001@linux.vnet.ibm.com> <1410116687.2027.19.camel@jarvis.lan> <20140907230019.GO5001@linux.vnet.ibm.com> <6092b453-e0c9-4f6d-922b-48bce988f774@email.android.com> <20140907233655.GR5001@linux.vnet.ibm.com> <154b540a-df47-4f3e-bdda-ab5d2e72723a@email.android.com> <1410155802.2027.36.camel@jarvis.lan> <540DF17C.9080509@zytor.com> <1410203369.2027.56.camel@jarvis.lan> <540DFFB2.4000509@zytor.com> <1410215994.2027.86.camel@jarvis.lan> In-Reply-To: <1410215994.2027.86.camel@jarvis.lan> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: James Bottomley Cc: paulmck@linux.vnet.ibm.com, Peter Hurley , One Thousand Gnomes , Jakub Jelinek , Mikael Pettersson , Benjamin Herrenschmidt , Richard Henderson , Oleg Nesterov , Miroslav Franc , Paul Mackerras , linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, Tony Luck , linux-ia64@vger.kernel.org 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