Re: [PATCH v2 02/10] MIPS: hazards: Add hazard macros for tlb read

[Ralf Baechle <ralf@linux-mips.org>]

On Tue, May 26, 2015 at 02:25:52PM +0100, Maciej W. Rozycki wrote:

> > > > - tlb_read_hazard
> > > >   Between tlbr and mfc0 (various TLB registers). This is copied from
> > > >   tlbw_use_hazard in all cases on the assumption that tlbr has similar
> > > >   data writer characteristics to tlbw, and mfc0 has similar data user
> > > >   characteristics to loads and stores.
> > > 
> > >  Be careful with this assumption, it does not stand for R4600/R4700 and 
> > > R5000 processors (4 vs 3 intervening instructions), you need an extra NOP 
> > > for them.  Likewise there is a difference with the 5K (1 vs 0 intervening 
> > > instructions), but it's already buried in our pessimistic barrier that 
> > > assumes 4 intervening instructions.
> > 
> > The TLB write hazard is 4 cycles on the 8 stage R4000 pipeline but 2 cycles
> > on the R4600 pipeline.
> 
>  I misinterpreted the numbers in the table for the R4600/R4700/R5000, 
> sorry.  It gives pipeline stage numbers rather than instruction counts, 
> unlike the 5K and some other tables.
> 
>  The difference is still there however: for TLBW_/use it's (3 - 2 - 1) => 
> 0 and for TLBR/MFC0 it's (4 - 2 - 1) => 1 (there's a one-cycle slip for 
> TLBW_ instructions causing it).  We use 3 NOPs for this variant, so it'll 
> be covered.
> 
> >  We handle this in a particularly non-obvious but
> > optimized way by exploiting the fact that the R4000 pipeline kills two
> > instructions following the branch delay slot like:
> > 
> > 	.set	noreorder
> > 	MTC0	$reg, c0_sometlbregister
> > 	B	1f
> > 1:	 NOP
> > 	TLBW
> > 
> > where the branch-nop sequence will cost 4 cycles on the R4000's eight-stage
> > pipeline but only two on the R4600 pipeline.
> 
>  And this code is where?  ISTR seeing it before, but now all I can see in 
> <asm/hazards.h> for the R4k and friends is:
> 
> #define __tlbw_use_hazard						\
> 	nop;								\
> 	nop;								\
> 	nop
> 
> It does not cover the 4-instruction hazard of the original R4000 even, so 
> it looks like it has to be fixed, perhaps by using code like you quoted.

Sorry for reciting kernel code from memory :-) I haven't checked a current
kernel before posting.  If it's been removed then this there might be a
bug or at least something that can be optimized for the R4000/R4000.

  Ralf