From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e36.co.us.ibm.com (8.13.8/8.13.8) with ESMTP id m45ERnn7027472 for ; Mon, 5 May 2008 10:27:49 -0400 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v8.7) with ESMTP id m45ERmse102796 for ; Mon, 5 May 2008 08:27:48 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m45ERm6a031807 for ; Mon, 5 May 2008 08:27:48 -0600 Date: Mon, 5 May 2008 07:27:46 -0700 From: "Paul E. McKenney" Subject: Re: [patch 1/2] read_barrier_depends fixlets Message-ID: <20080505142746.GC14809@linux.vnet.ibm.com> Reply-To: paulmck@linux.vnet.ibm.com References: <20080505112021.GC5018@wotan.suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080505112021.GC5018@wotan.suse.de> Sender: owner-linux-mm@kvack.org Return-Path: To: Nick Piggin Cc: Linus Torvalds , Hugh Dickins , linux-arch@vger.kernel.org, Linux Memory Management List List-ID: On Mon, May 05, 2008 at 01:20:21PM +0200, Nick Piggin wrote: > While considering the impact of read_barrier_depends, it occurred to > me that it should really be really a noop for the compiler. At least, it is > better to have every arch the same than to have a few that are slightly > different. (Does this mean SMP Alpha's read_barrier_depends could drop the > "memory" clobber too?) SMP Alpha's read_barrier_depends() needs the "memory" clobber because the compiler is otherwise free to move code across the smp_read_barrier_depends(), which would defeat its purpose. > -- > It would be a highly unusual compiler that might try to issue a load of > data1 before it loads a data2 which is data-dependant on data1. A bit unusual, perhaps, but not unprecedented. Value speculating compilers, for example. > There is the problem of the compiler trying to reload data1 _after_ > loading data2, and thus having a newer data1 than data2. However if the > compiler is so inclined, then it could perform such a load at any point > after the barrier, so the barrier itself will not guarantee correctness. > > I think we've mostly hoped the compiler would not to do that. Well, this does point me at one thing I missed with preemptable RCU, namely all the open-coded sequences using smp_read_barrier_depends(). Quite embarrassing!!! But a lot easier having you point me at it than however long it would have taken me to figure it out on my own, so thank you very much!!! > This brings alpha and frv into line with all other architectures. Assuming that we apply ACCESS_ONCE() as needed to the uses of smp_read_barrier_depends(): Acked-by: Paul E. McKenney > Signed-off-by: Nick Piggin > > Index: linux-2.6/include/asm-alpha/barrier.h > =================================================================== > --- linux-2.6.orig/include/asm-alpha/barrier.h > +++ linux-2.6/include/asm-alpha/barrier.h > @@ -24,7 +24,7 @@ __asm__ __volatile__("mb": : :"memory") > #define smp_mb() barrier() > #define smp_rmb() barrier() > #define smp_wmb() barrier() > -#define smp_read_barrier_depends() barrier() > +#define smp_read_barrier_depends() do { } while (0) > #endif > > #define set_mb(var, value) \ > Index: linux-2.6/include/asm-frv/system.h > =================================================================== > --- linux-2.6.orig/include/asm-frv/system.h > +++ linux-2.6/include/asm-frv/system.h > @@ -179,7 +179,7 @@ do { \ > #define mb() asm volatile ("membar" : : :"memory") > #define rmb() asm volatile ("membar" : : :"memory") > #define wmb() asm volatile ("membar" : : :"memory") > -#define read_barrier_depends() barrier() > +#define read_barrier_depends() do { } while (0) > > #ifdef CONFIG_SMP > #define smp_mb() mb() -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org