From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21641 invoked by alias); 10 Jan 2007 00:39:40 -0000 Received: (qmail 21633 invoked by uid 22791); 10 Jan 2007 00:39:39 -0000 X-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,FORGED_RCVD_HELO X-Spam-Check-By: sourceware.org Received: from tomts43.bellnexxia.net (HELO tomts43-srv.bellnexxia.net) (209.226.175.110) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 10 Jan 2007 00:39:33 +0000 Received: from krystal.dyndns.org ([67.68.204.133]) by tomts43-srv.bellnexxia.net (InterMail vM.5.01.06.13 201-253-122-130-113-20050324) with ESMTP id <20070110003930.JIKS11361.tomts43-srv.bellnexxia.net@krystal.dyndns.org> for ; Tue, 9 Jan 2007 19:39:30 -0500 Received: from localhost (localhost [127.0.0.1]) (uid 1000) by krystal.dyndns.org with local; Tue, 09 Jan 2007 19:39:27 -0500 id 000C3E12.45A435BF.00000426 Date: Wed, 10 Jan 2007 00:39:00 -0000 From: Mathieu Desnoyers To: Pavel Machek Cc: linux-kernel@vger.kernel.org, Andrew Morton , Ingo Molnar , Greg Kroah-Hartman , Christoph Hellwig , ltt-dev@shafik.org, systemtap@sources.redhat.com, Douglas Niehaus , "Martin J. Bligh" , Thomas Gleixner Subject: Re: [PATCH] local_t : Documentation - update Message-ID: <20070110003926.GA27830@Krystal> References: <20061221001545.GP28643@Krystal> <20061223093358.GF3960@ucw.cz> <20070109031446.GA29426@Krystal> <20070109224100.GB6555@elf.ucw.cz> <20070109232155.GA25387@Krystal> <20070109234511.GB7798@elf.ucw.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline In-Reply-To: <20070109234511.GB7798@elf.ucw.cz> X-Editor: vi X-Info: http://krystal.dyndns.org:8080 X-Operating-System: Linux/2.4.32-grsec (i686) X-Uptime: 19:18:31 up 139 days, 21:25, 5 users, load average: 0.82, 0.86, 0.73 User-Agent: Mutt/1.5.13 (2006-08-11) X-IsSubscribed: yes Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org X-SW-Source: 2007-q1/txt/msg00031.txt.bz2 * Pavel Machek (pavel@ucw.cz) wrote: > > index dfeec94..bd854b3 100644 > > --- a/Documentation/local_ops.txt > > +++ b/Documentation/local_ops.txt > > @@ -22,6 +22,13 @@ require disabling interrupts to protect from interrupt handlers and it permits > > coherent counters in NMI handlers. It is especially useful for tracing purposes > > and for various performance monitoring counters. > > > > +Local atomic operations only guarantee variable modification atomicity wrt the > > +CPU which owns the data. Therefore, care must taken to make sure that only one > > +CPU writes to the local_t data. This is done by using per cpu data and making > > +sure that we modify it from within a preemption safe context. It is however > > +permitted to read local_t data from any CPU : it will then appear to be written > > +out of order wrt other memory writes on the owner CPU. > > So it is "one cpu may write, other cpus may read", and as big as > long. Are you sure obscure architectures (sparc?) can implement this > in useful way? ... maybe yes, unless obscure architecture exists where > second other cpu can see garbage data when first cpu writes into long > ...? > > Sparc64 uses a memory barrier around the atomic operations in the SMP case (see arch/sparc64/lib/atomic.S). The same is true for sparc. As I am not a sparc expert, I left the asm-generic default behavior, but I think it should be safe to implement local.S code derived from atomic.S to optimize the speed of the local_t operations on sparc and sparc64. Can anyone confirm this ? I don't know any architecture where an aligned memory access (read or write) to a pointer type is not atomic. Size of longs are either 32 or 64 bits, but always smaller than the pointer size (LLP64 has 32 bits longs, LP64 has 64 bits longs, ILP64 has 64 bits longs). Mathieu -- OpenPGP public key: http://krystal.dyndns.org:8080/key/compudj.gpg Key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68