linux-mips
[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: Jason Gunthorpe <jgg@debian.org>
Date: Wed, 30 Jan 2002 13:02:21 -0700 (MST)
Cc: linux-mips@fnet.fr, linux-mips@oss.sgi.com
In-reply-to: <Pine.GSO.3.96.1020130151155.2880D-100000@delta.ds2.pg.gda.pl>
Reply-to: Jason Gunthorpe <jgg@debian.org>
Sender: owner-linux-mips@oss.sgi.com
On Wed, 30 Jan 2002, Maciej W. Rozycki wrote:

> worse, recently I've identified a case it doesn't work at all on an
> R4400SC CPU -- values written to an i/o memory resource were not committed
> to the device even after executing over 40 subsequent instructions. 

Nice patch!

I was under the impression that the mb() functions existed to maintain
order of memory access and were not defined as flushes per say - so is
the time delay a concern (perhaps sticking a sync before ERET is
appropriate?)

I spent some time talking with the Sandcraft people about memory barrier
issues, and it turns out that at least on the SR71000 (and in most cases
the RM7K) the order of SysAD transactions will always match the order of
the instruction stream, but all writes are posted and all reads are split
- that is the CPU can execute two back to back uncached loads and several
back to back uncached stores without stalling the pipeline, or getting the
IO's out of order. Adding sync's and uncached loads only slows things down
for these chips. 

I understand this is because the CPUs have a single load/store unit and do
not do out of order execution. Many older/embedded MIPS designs probably
have a similar configuration, they could likely also run with out the
syncs. 

So - could you add something like CONFIG_IN_ORDER_IO which would nullify
the syncs for these processors?

BTW, does anyone know what CONFIG_WB is ment to mean? The CPU has a write
buffer that does not preserve order? 

Thanks,
Jason



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