Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759910AbXHPUqu (ORCPT ); Thu, 16 Aug 2007 16:46:50 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752914AbXHPUqj (ORCPT ); Thu, 16 Aug 2007 16:46:39 -0400 Received: from gate.crashing.org ([63.228.1.57]:44571 "EHLO gate.crashing.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751583AbXHPUqi (ORCPT ); Thu, 16 Aug 2007 16:46:38 -0400 In-Reply-To: <18115.48863.331246.638826@cargo.ozlabs.ibm.com> References: <20070809131423.GA9927@shell.boston.redhat.com> <46C2D6F3.3070707@s5r6.in-berlin.de> <18115.35524.56393.347841@cargo.ozlabs.ibm.com> <20070816003948.GY9645@linux.vnet.ibm.com> <18115.44462.622801.683446@cargo.ozlabs.ibm.com> <20070816020042.GA30650@gondor.apana.org.au> <18115.45316.702491.681906@cargo.ozlabs.ibm.com> <18115.48863.331246.638826@cargo.ozlabs.ibm.com> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Christoph Lameter , heiko.carstens@de.ibm.com, horms@verge.net.au, Stefan Richter , Satyam Sharma , Linux Kernel Mailing List , "Paul E. McKenney" , netdev@vger.kernel.org, ak@suse.de, cfriesen@nortel.com, rpjday@mindspring.com, jesper.juhl@gmail.com, linux-arch@vger.kernel.org, Andrew Morton , zlynx@acm.org, schwidefsky@de.ibm.com, Chris Snook , Herbert Xu , davem@davemloft.net, Linus Torvalds , wensong@linux-vs.org, wjiang@resilience.com From: Segher Boessenkool Subject: Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures Date: Thu, 16 Aug 2007 21:39:18 +0200 To: Paul Mackerras X-Mailer: Apple Mail (2.623) Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1241 Lines: 30 >> I can't speak for this particular case, but there could be similar >> code >> examples elsewhere, where we do the atomic ops on an atomic_t object >> inside a higher-level locking scheme that would take care of the kind >> of >> problem you're referring to here. It would be useful for such or >> similar >> code if the compiler kept the value of that atomic object in a >> register. > > If there is a higher-level locking scheme then there is no point to > using atomic_t variables. Atomic_t is specifically for the situation > where multiple CPUs are updating a variable without locking. And don't forget about the case where it is an I/O device that is updating the memory (in buffer descriptors or similar). The driver needs to do a "volatile" atomic read to get at the most recent version of that data, which can be important for optimising latency (or throughput even). There is no other way the kernel can get that info -- doing an MMIO read is way way too expensive. Segher - 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/