From owner-freebsd-alpha Sat Dec 16 0:31:59 2000 From owner-freebsd-alpha@FreeBSD.ORG Sat Dec 16 00:31:57 2000 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from front1.grolier.fr (front1.grolier.fr [194.158.96.51]) by hub.freebsd.org (Postfix) with ESMTP id EBD1F37B400; Sat, 16 Dec 2000 00:31:56 -0800 (PST) Received: from nas1-218.mea.club-internet.fr (nas1-218.mea.club-internet.fr [195.36.139.218]) by front1.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id JAA20399; Sat, 16 Dec 2000 09:31:48 +0100 (MET) Date: Sat, 16 Dec 2000 08:31:42 +0100 (CET) From: =?ISO-8859-1?Q?G=E9rard_Roudier?= X-Sender: groudier@linux.local To: Matthew Jacob 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=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, 15 Dec 2000, Matthew Jacob wrote: > > } > >=20 > > There is obviously no relevance here in trying to drain something to > > memory. Note that thinking about a mb() as something that drains to mem= ory > > is a serious mistake in my opinion. We want to order there, not to drai= n > > anything anywhere. >=20 > 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 dat= a > that needs to arrive at it's 'real' location. >=20 >=20 > > However, the mb() above does have the effect of throwing away any read= =20 > > 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. >=20 > I don't *believe* that this is an issue for Alpha. It is for sparc which = is > not a memory coherent model. This has nothing to do with memory coherency model but has to do with the ability of a CPU to exececutee LOADs out of order. > 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. Handbook 1.0 1992 was already clear on this point. Unforgivable for having missed it you may well be. :-) G=E9rard. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message