Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1761445AbXIJVgp (ORCPT ); Mon, 10 Sep 2007 17:36:45 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1760720AbXIJVge (ORCPT ); Mon, 10 Sep 2007 17:36:34 -0400 Received: from netops-testserver-4-out.sgi.com ([192.48.171.29]:57115 "EHLO relay.sgi.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1756685AbXIJVgc (ORCPT ); Mon, 10 Sep 2007 17:36:32 -0400 Date: Mon, 10 Sep 2007 14:36:26 -0700 (PDT) From: Christoph Lameter X-X-Sender: clameter@schroedinger.engr.sgi.com To: "Paul E. McKenney" cc: Segher Boessenkool , Paul Mackerras , heiko.carstens@de.ibm.com, horms@verge.net.au, Stefan Richter , Satyam Sharma , Linux Kernel Mailing List , David Miller , Ilpo =?iso-8859-1?Q?J=E4rvinen?= , ak@suse.de, cfriesen@nortel.com, rpjday@mindspring.com, Netdev , jesper.juhl@gmail.com, linux-arch@vger.kernel.org, Andrew Morton , zlynx@acm.org, schwidefsky@de.ibm.com, Chris Snook , Herbert Xu , Linus Torvalds , wensong@linux-vs.org, wjiang@resilience.com Subject: Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures In-Reply-To: <20070910205434.GF11801@linux.vnet.ibm.com> Message-ID: References: <18115.52863.638655.658466@cargo.ozlabs.ibm.com> <20070816053945.GB32442@gondor.apana.org.au> <18115.62741.807704.969977@cargo.ozlabs.ibm.com> <20070816070907.GA964@gondor.apana.org.au> <46C4ABA5.9010804@redhat.com> <20070910205434.GF11801@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 951 Lines: 19 On Mon, 10 Sep 2007, Paul E. McKenney wrote: > The one exception to this being the case where process-level code is > communicating to an interrupt handler running on that same CPU -- on > all CPUs that I am aware of, a given CPU always sees its own writes > in order. Yes but that is due to the code path effectively continuing in the interrupt handler. The cpu makes sure that op codes being executed always see memory in a consistent way. The basic ordering problem with out of order writes is therefore coming from other processors concurrently executing code and holding variables in registers that are modified elsewhere. The only solution that I know of are one or the other form of barrier. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/