linux-mips-fnet
[Top] [All Lists]

Re: [patch] linux 2.4.17: The second mb() rework (final)

To: Dominic Sweetman <dom@algor.co.uk>
Subject: Re: [patch] linux 2.4.17: The second mb() rework (final)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Date: Fri, 15 Feb 2002 13:53:50 +0100 (MET)
Cc: "Kevin D. Kissell" <kevink@mips.com>, Atsushi Nemoto <nemoto@toshiba-tops.co.jp>, mdharm@momenco.com, ralf@uni-koblenz.de, linux-mips@fnet.fr, linux-mips@oss.sgi.com
In-reply-to: <200202151156.LAA17485@mudchute.algor.co.uk>
Organization: Technical University of Gdansk
On Fri, 15 Feb 2002, Dominic Sweetman wrote:

> That's only a problem if the CPU permitted reads to overtake buffered
> writes.  [Early R3000 write buffers did that (with an address check to
> avoid the disaster of allowing a read to overtake a write to the same
> location).]

 The R2020 and the R3220 write buffers that are used in older DECstations
seem to provide buffered values themselves if hit by a read.  This way
they are completely safe for ordinary memory references and there is no
need to stall for a write-back completion for memory operations.  At least
this is what DECstation specifications imply -- it seems hard to get to
original docs for the chips these days.

 For I/O resources implying side effects a stall is needed, of course. 

 The way the chips work is not that uncommon -- e.g. Intel's i486 does
exactly the same.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

<Prev in Thread] Current Thread [Next in Thread>