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

From: Ralf Baechle <[email-masked]>
Date: Mon, 2 Feb 2004 16:08:06 +0100

On Mon, Jan 26, 2004 at 06:12:43PM +0100, Maciej W. Rozycki wrote:

>  The R4000/R4400 has a coprocessor 0 hazard when a P-cache operation is
> less than two non-load, non-cache instructions apart from a store to the
> same line.  For processors without a secondary cache, the code in pg-r4k.c
> currently issues a Create Dirty Exclusive D-cache operation and then
> immediately executes consecutive stores to the same line, therefore 
> fulfilling the conditions for the hazard.

The wording is "There must be two non-load, non-CACHE instructions between
a store and a CACHE instruction directed to the same primary cache line as
the store."  My interpretation of that is the problem only exists if a
store instruction is followed by a cache instruction, not if the
cache instruction is followed by the store?  I've not found any hints in
the manual to verify or falsify this theory.  In case you're right we've
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.

Any DECstations using the R4[04]00PC CPU variant?

>  The following patch changes the problematic operations to be performed on 
> the cache line following the one to be written immediately.  It is safe to 
> do so, because the cache operations are only a performance hint and are 
> not required for data coherency.  However it is essential not to bypass 
> the end of the page, so the trailing area of the page is excluded from 
> these cache operation, similarly to what has already been done for 
> prefetching.
> 
>  Actually, I'd like to optimize the functions a bit further, specifically 
> to avoid multiple cacheops to the same line (if you don't mind),

Please do so - cacheops are fairly expensive, we must use them as
intelligently as possible.

> but 
> currently I'd like to apply this change to assure correct operation.  As I 
> have no non-SC R4000/R4400 system, this was untested, but perhaps studying 
> the problem covered by the -scache patch sent previously will show if the 
> hazard is indeed avoided.

Have you actually been hit by that hazard?  

>  The patch also increases the buffers a bit for three reasons:
> 
> 1. copy_page_array is already too small for the 128-byte S-cache line 
> case. ;-)
>
> 2. The trail for non-SC R4000/R4400 increases buffer consumption and I was 
> too lazy to calculate the requirements.
> 
> 3. The planned optimization will likely require a little bit more space as 
> well.
> 
> BTW, I was unable to reproduce your instruction count calculation for the
> prefetch case; other results seem OK.

Yep, the patch I just checked in increased the allocation size to handle
the worst case appropriately.  In the end I think we really want to trade
memory for performance here.

>  OK to apply?

Most of your changes conflict with my fixes, so I guess that need redoing ...

  Ralf

---

From: Karsten Merker <[email-masked]>
Date: Mon, 2 Feb 2004 19:38:06 +0100

> Any DECstations using the R4[04]00PC CPU variant?

Not that I know of - only R4[04]00SC.

Regards,
Karsten
-- 
#include <standard_disclaimer>
Nach Paragraph 28 Abs. 3 Bundesdatenschutzgesetz widerspreche ich der Nutzung
oder Uebermittlung meiner Daten fuer Werbezwecke oder fuer die Markt- oder
Meinungsforschung.

---

From: "Maciej W. Rozycki" <[email-masked]>
Date: Tue, 3 Feb 2004 16:11:43 +0100 (CET)

> the manual to verify or falsify this theory.  In case you're right we've

 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.

> 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?

> 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.

> Have you actually been hit by that hazard?  

 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.

> Most of your changes conflict with my fixes, so I guess that need redoing ...

 I can see you've already resolved a few problems -- I'll check if any
remained.

  Maciej

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: [email-masked], PGP key available        +

---

From: Ralf Baechle <[email-masked]>
Date: Tue, 3 Feb 2004 16:42:18 +0100

> mean the table is correct, but I'd assume so, for safety, if not anything 

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

> 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.

> 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

---

From: "Maciej W. Rozycki" <[email-masked]>
Date: Tue, 3 Feb 2004 17:03:29 +0100 (CET)

> generating now that is it violates this hazard.

 OK then.

> combination of both.  Anyway, what is now in CVS is tested on R4400SC V4.0.

 After rereading the description I agree with you, so I am going to get at 
the code again soon.