On Mon, 2 Feb 2004, Ralf Baechle 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 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. > 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? > 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. > > 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? 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. > > OK to apply? > > 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: macro@ds2.pg.gda.pl, PGP key available +
