linux-mips
[Top] [All Lists]

Re: [patch] pg-r4k.c cp0 hazards for R4000/R4400

To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Subject: Re: [patch] pg-r4k.c cp0 hazards for R4000/R4400
From: Ralf Baechle <ralf@linux-mips.org>
Date: Tue, 3 Feb 2004 16:42:18 +0100
Cc: linux-mips@linux-mips.org
In-reply-to: <Pine.LNX.4.55.0402031504030.16076@jurand.ds.pg.gda.pl>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <Pine.LNX.4.55.0401261755460.26076@jurand.ds.pg.gda.pl> <20040202150806.GA27819@linux-mips.org> <Pine.LNX.4.55.0402031504030.16076@jurand.ds.pg.gda.pl>
Sender: linux-mips-bounce@linux-mips.org
User-agent: Mutt/1.4.1i
On Tue, Feb 03, 2004 at 04:11:43PM +0100, Maciej W. Rozycki wrote:

>  I'm pretty sure the hazard is in both directions -- why?  Because it's 
> marked both in the "CP0 Data Used, Stage Used" and the "CP0 Data Written, 
> Stage Available" column.  I interpret that as a requirement for the CACHE 
> instructions to "start using data" two instructions ahead and "finish 
> writing data" two instructions after itself.  If your assumption was true, 
> I'd put the marking only in the former column.  Of course that does not 
> mean the table is correct, but I'd assume so, for safety, if not anything 
> else.

I was just trying to explain why the PC variants used to work fine.

> > violated this hazard since almost beginning of the time, see
> > http://www.linux-mips.org/cvsweb/linux/arch/mips/mm/Attic/pg-r4k.S?rev=1.9
> > and I've not heared of any problems arising from this.
> 
>  Perhaps it wasn't really tested.  Have you ever run the code on a PC 
> variant?  Has anyone else?

Yes, it has.  Olivetti M700-10, around 2.2 or so.  The code used at that
time in arch/mips/mm/r4xx0.c was not much different from what pg-r4k.c is
generating now that is it violates this hazard.

> > Any DECstations using the R4[04]00PC CPU variant?
> 
>  None.  That would normally be a downgrade in memory throughput as the
> R2k/R3k DECstations used to have 64kB of I-cache + 64kB of D-cache,
> typically, and sometimes (with the 33MHz variant) even 128kB of D-cache.

>  I suppose so -- without the "mips-pg-r4k-scache" patch my system is very
> unstable and the difference is essentially that in addition to
> Create_Dirty_Excl_SD there are additional Create_Dirty_Excl_D ones, that,
> apart from being a performance hit, shouldn't have any effect.  I have to
> investigate it further yet.

Interesting, I was expecting somewhat better performance from the
combination of both.  Anyway, what is now in CVS is tested on R4400SC V4.0.

  Ralf

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