Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932317AbWBBVwn (ORCPT ); Thu, 2 Feb 2006 16:52:43 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S932314AbWBBVwn (ORCPT ); Thu, 2 Feb 2006 16:52:43 -0500 Received: from xenotime.net ([66.160.160.81]:25799 "HELO xenotime.net") by vger.kernel.org with SMTP id S932317AbWBBVwn (ORCPT ); Thu, 2 Feb 2006 16:52:43 -0500 Date: Thu, 2 Feb 2006 13:52:41 -0800 (PST) From: "Randy.Dunlap" X-X-Sender: rddunlap@shark.he.net To: Alan Stern cc: Roland Dreier , Kernel development list Subject: Re: Question about memory barriers In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 965 Lines: 25 On Thu, 2 Feb 2006, Alan Stern wrote: > On Thu, 2 Feb 2006, Roland Dreier wrote: > > > Most of this is correct, except that mb() is stronger than just rmb() > > and wmb() put together. All memory operations before the mb() will > > complete before any operations after the mb(). A better way to > > understand this is to look at the sparc64 definition: > > > > #define mb() \ > > membar_safe("#LoadLoad | #LoadStore | #StoreStore | #StoreLoad") > > Thanks for the explanation. Is there any appropriate place, say in > Documentation/, where these things could be spelled out more completely? Info could be added to Documentation/DocBook/kernel-locking.tmpl which already has some barrier info. -- ~Randy - 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/