Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751028Ab1BNRuI (ORCPT ); Mon, 14 Feb 2011 12:50:08 -0500 Received: from mail-pw0-f46.google.com ([209.85.160.46]:60967 "EHLO mail-pw0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750843Ab1BNRuF (ORCPT ); Mon, 14 Feb 2011 12:50:05 -0500 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Rh/mJgXoiJI2zUi5AMWkB8+cHccxvGoXQQ64kNgmPFh2xv0Ex/+BNcsRjn5t5ljABY hbPll9ZvsZWJlY6xB247mHKgbT1BEzLtO4qix9u5G8sBlfYMu6meW7tOUPSJ65QwSk8p dMhxAqf3ZQrahuMd/gbsHrp7CIIJPTcbL8kMA= MIME-Version: 1.0 In-Reply-To: <1297705428.5226.142.camel@laptop> References: <1297452328.5226.89.camel@laptop> <1297460297.5226.99.camel@laptop> <1297536465.5226.108.camel@laptop> <20110214155113.GA2840@redhat.com> <1297699024.2401.12.camel@twins> <20110214160437.GB2840@redhat.com> <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> Date: Mon, 14 Feb 2011 17:50:04 +0000 Message-ID: Subject: Re: [PATCH 0/2] jump label: 2.6.38 updates From: Will Newton To: Peter Zijlstra Cc: Steven Rostedt , Jason Baron , Mathieu Desnoyers , 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 Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1416 Lines: 31 On Mon, Feb 14, 2011 at 5:43 PM, Peter Zijlstra wrote: > On Mon, 2011-02-14 at 17:38 +0000, Will Newton wrote: >> On Mon, Feb 14, 2011 at 5:27 PM, Peter Zijlstra wrote: >> >> >> So all but a few have basically (as you said on IRC) >> >> #define atomic_read(v) ACCESS_ONCE(v) >> > >> > ACCESS_ONCE(v->counter), but yeah :-) >> >> I maintain an out-of-tree architecture where that isn't the case >> unfortunately [1]. Not expecting any special favours for being >> out-of-tree of course, but just thought I would add that data point. >> >> [1] Our atomic operations go around the cache rather than through it, >> so the value of an atomic cannot be read with a normal load >> instruction. > > Cannot how? It would observe a stale value? That is acceptable for > atomic_read(). 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. -- 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/