From owner-freebsd-alpha Fri Dec 15 14:31:12 2000 From owner-freebsd-alpha@FreeBSD.ORG Fri Dec 15 14:31:10 2000 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 6A4A837B400; Fri, 15 Dec 2000 14:31:10 -0800 (PST) Received: from zeppo.feral.com (IDENT:mjacob@zeppo [192.67.166.71]) by feral.com (8.9.3/8.9.3) with ESMTP id OAA31566; Fri, 15 Dec 2000 14:31:13 -0800 Date: Fri, 15 Dec 2000 14:31:05 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: =?ISO-8859-1?Q?G=E9rard_Roudier?= Cc: John Baldwin , Bernd Walter , freebsd-alpha@FreeBSD.ORG Subject: RE: mb and wmb in atomic_ In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > } > > There is obviously no relevance here in trying to drain something to > memory. Note that thinking about a mb() as something that drains to memory > is a serious mistake in my opinion. We want to order there, not to drain > anything anywhere. That's correct. The 'drain' notion comes from the idea that write buffers (either from devices to memory or from memory to devices) may contain data that needs to arrive at it's 'real' location. > However, the mb() above does have the effect of throwing away any read > that may have been prefetched by the CPU. If we need that here, we must > not remove the mb(), otherwise the mb() can be removed. I don't *believe* that this is an issue for Alpha. It is for sparc which is not a memory coherent model. We went around and around with this discussion a while back. Since then I've gotten the newer Alpha architecture book. I'm swamped at the moment, but I'll post the relevant pages about this some time this weekend. -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message