From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28946 invoked by alias); 9 Jan 2007 23:45:31 -0000 Received: (qmail 28937 invoked by uid 22791); 9 Jan 2007 23:45:30 -0000 X-Spam-Status: No, hits=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO X-Spam-Check-By: sourceware.org Received: from gprs189-60.eurotel.cz (HELO amd.ucw.cz) (160.218.189.60) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 09 Jan 2007 23:45:25 +0000 Received: by amd.ucw.cz (Postfix, from userid 8) id 8A4CB2BCB5; Wed, 10 Jan 2007 00:45:11 +0100 (CET) Date: Tue, 09 Jan 2007 23:45:00 -0000 From: Pavel Machek To: Mathieu Desnoyers 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: <20070109234511.GB7798@elf.ucw.cz> References: <20061221001545.GP28643@Krystal> <20061223093358.GF3960@ucw.cz> <20070109031446.GA29426@Krystal> <20070109224100.GB6555@elf.ucw.cz> <20070109232155.GA25387@Krystal> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070109232155.GA25387@Krystal> X-Warning: Reading this can be dangerous to your mental health. User-Agent: Mutt/1.5.11+cvs20060126 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/msg00030.txt.bz2 Hi! > > AFAICT this fails to mention... Is local_t as big as int? As big as > > long? Or perhaps smaller because high bits may be needed for locking? > > Hi Pavel, > > Here is an update that adds the information you mentionned in this reply and the > one to Andrew. Thanks for the comments. > > Mathieu > > > 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 ...? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html