Subject: Re: MIPS cache rototill
To: None <thorpej@zembu.com>
From: None <cgd@sibyte.com>
List: port-mips
Date: 07/09/2001 13:38:18
thorpej@zembu.com ("Jason R Thorpe") writes:
> What I'm looking for here is comments on the primivites.

based on your comments way in the middle of the text, arguments are
(valid) virtual addresses and lengths?

Are they the actual addresses that you want flushed, or are they crud
constructed out of the indices that you want flushed?  (The latter
seems to be what's done now, in a lot of places ... and is ... not so
good.)

This is an important distinction.  Say you have a 32KB 4-way
set-associative virtually-indexed cache and the kernel is using 4KB
pages (as NetBSD's kernel currently does):

If you're using the actual address range you want flushed, you can do
a single set of Hit ops which flush only that range.

If you're using "constructed crud," then you have to use index ops to
flush out the _8_ possible sets of matching indices!

That'll blow a nice big hole in your cache.  8-)



You seem to define Primary-{I,D}, Secondary {I,D}.

I don't know any modern cpus which support split secondary caches.

There are, however, chips out there which have tertiary caches.
(IIRC, those use the "Secondary-I" cache code -- now also thought of
as the tertiary cache code.  8-)

Indeed, if you look at e.g. the MIPS32 and MIPS64 instruction set
documents published by MIPS, they indicate the following types of
caches, for cache ops:

	(0) Primary I
	(1) Primary D (or unified primary)
	(2) Tertiary
	(3) Secondary

So, if you want to be fully general, you probably need to define ops:

	primary I/D
	secondary I/D
	tertiary (unified)

and then have the operations you define later invoke _them_.


>  * Finally, these primitives are grouped together in reasonable
>  * ways.  For all operations described here, first the primary
>  * cache is frobbed, then the secondary cache frobbed, if the
>  * operation for the secondary cache exists.
>  *
>  *	mips_icache_inv_all	Invalidate I-cache
>  *
>  *	mips_icache_inv_range	Invalidate I-cache range
>  *
>  *	mips_dcache_wbinv_all	Write-back Invalidate D-cache
>  *
>  *	mips_dcache_wbinv_range	Write-back Invalidate D-cache range
>  *
>  *	mips_dcache_inv_range	Invalidate D-cache range
>  *
>  *	mips_dcache_wb_range	Write-back D-cache range

I'm wondering about the meaning of the icache invalidate ops.

Are these intended to mean "sync I-cache"?  or are they really
intended to just invalidate it?  (in what circumstances is that
useful?)

If they actually mean "sync I-cache", then they also have to wbinv the
d-cache.  8-)



chris