Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751920Ab1BNSyB (ORCPT ); Mon, 14 Feb 2011 13:54:01 -0500 Received: from blu0-omc1-s37.blu0.hotmail.com ([65.55.116.48]:44484 "EHLO blu0-omc1-s37.blu0.hotmail.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751655Ab1BNSx4 (ORCPT ); Mon, 14 Feb 2011 13:53:56 -0500 X-Originating-IP: [174.91.193.52] X-Originating-Email: [pdumas9@sympatico.ca] Message-ID: Date: Mon, 14 Feb 2011 13:53:49 -0500 From: Mathieu Desnoyers To: Peter Zijlstra CC: Will Newton , Steven Rostedt , Jason Baron , hpa@zytor.com, mingo@elte.hu, tglx@linutronix.de, andi@firstfloor.org, roland@redhat.com, rth@redhat.com, masami.hiramatsu.pt@hitachi.com, fweisbec@gmail.com, avi@redhat.com, davem@davemloft.net, sam@ravnborg.org, ddaney@caviumnetworks.com, michael@ellerman.id.au, linux-kernel@vger.kernel.org, Mike Frysinger , Chris Metcalf , dhowells , Martin Schwidefsky , "heiko.carstens" , benh Subject: Re: [PATCH 0/2] jump label: 2.6.38 updates References: <1297700754.5226.110.camel@laptop> <20110214162947.GA3449@redhat.com> <1297701438.5226.113.camel@laptop> <1297702013.23343.51.camel@gandalf.stny.rr.com> <1297703892.23343.71.camel@gandalf.stny.rr.com> <1297704447.5226.127.camel@laptop> <1297705428.5226.142.camel@laptop> <1297707868.5226.189.camel@laptop> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline In-Reply-To: <1297707868.5226.189.camel@laptop> X-Editor: vi X-Info: http://krystal.dyndns.org:8080 X-Operating-System: Linux/2.6.27.31-grsec (i686) X-Uptime: 13:48:08 up 313 days, 4:37, 7 users, load average: 2.08, 1.94, 1.83 User-Agent: Mutt/1.5.18 (2008-05-17) X-OriginalArrivalTime: 14 Feb 2011 18:53:54.0957 (UTC) FILETIME=[876053D0:01CBCC78] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1793 Lines: 46 * Peter Zijlstra (peterz@infradead.org) wrote: > On Mon, 2011-02-14 at 17:50 +0000, Will Newton wrote: > > > > It would observe a stale value, but that value would only be updated > > when the cache line was reloaded from main memory which would have to > > be triggered by either eviction or cache flushing. So it could get > > pretty stale. Whilst that's probably within the spec. of atomic_read I > > suspect it would lead to problems in practice. I could be wrong > > though. > > Right, so the typical scenario that could cause pain is something like: > > while (atomic_read(&foo) != n) > cpu_relax(); > > and the problem is that cpu_relax() doesn't know which particular > cacheline to flush in order to make things go faster, hm? As an information point, this is why I mapped "uatomic_read()" to "CMM_LOAD_SHARED" in my userspace RCU library rather than just doing a volatile access. On cache-coherent architectures, the arch-specific code turns CMM_LOAD_SHARED into a simple volatile access, but for non-cache-coherent architectures, it can call the required architecture-level primitives to fetch the stale data. FWIW, I also have "CMM_STORE_SHARED" which does pretty much the same thing. I use these for rcu_assign_pointer() and rcu_dereference() (thus replacing "ACCESS_ONCE()"). The more detailed comment and macros are found at http://git.lttng.org/?p=userspace-rcu.git;a=blob;f=urcu/system.h I hope this helps, Mathieu -- Mathieu Desnoyers Operating System Efficiency R&D Consultant EfficiOS Inc. http://www.efficios.com -- 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/