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

Re: [patch] linux 2.4.17: An mb() rework

To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Subject: Re: [patch] linux 2.4.17: An mb() rework
From: Ralf Baechle <ralf@oss.sgi.com>
Date: Mon, 4 Feb 2002 18:02:58 +0100
Cc: Jason Gunthorpe <jgg@debian.org>, linux-mips@fnet.fr, linux-mips@oss.sgi.com
In-reply-to: <Pine.GSO.3.96.1020131115837.5578A-100000@delta.ds2.pg.gda.pl>; from macro@ds2.pg.gda.pl on Thu, Jan 31, 2002 at 01:17:39PM +0100
References: <Pine.LNX.3.96.1020130123109.11192A-100000@wakko.deltatee.com> <Pine.GSO.3.96.1020131115837.5578A-100000@delta.ds2.pg.gda.pl>
User-agent: Mutt/1.2.5i
On Thu, Jan 31, 2002 at 01:17:39PM +0100, Maciej W. Rozycki wrote:

>  Certain DECstation models have a write-back buffer that needs to be
> handled explicitly.  For example rmb() is "1: bc0f 1b" for the R3220 WB
> chip.  Wmb() is null, certainly, as the buffer is strongly-ordered.  See
> arch/mips/dec/wbflush.c for details.

Just as an aside that isn't directly relevant to DECstations.  To date
all MIPS _processors_ are strongly ordered.  I now know of at least one
processor that implements a weakly ordered memory model, so the assumption
of a strongly ordered memory model has become void for large parts of the
kernel.  Even before that some systems had strongly ordered processors in
system environments that may reorder requests.

Bugs due to surprise memory reordering are entirely unfun to debug, so be
paranoid.  They're out there to get you ...

  Ralf

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