William J. Earl (firstname.lastname@example.org) ....
is of course right.
> The secondary cache is essentially independent of the primary
> caches, and is write-through.
The R5000 and QED RM527x share this kind of secondary cache. It's
becoming obsolete - partly because it's not very efficient, and
partly because it depends on some special tag RAMs which nobody makes
any more. [But it does work quite well in internet routers where a
big secondary can hold large chunks of routing table...]
QED's RM7000 has an internal secondary cache which is more like (but
not compatible with) an R4000. As part of our Linux familiarisation
we'll try to get that working. It's 4-way set associative, 256Kbytes
big, unified and write-back; so that should shake out some more bugs.
MIPS started off with the (fairly sound) argument that software should
manage the caches because software-invisible snoopy caches (x86-style)
cost a lot of hardware complication but don't buy any performance.
The argument is based on the observation (correct, then as now) that
the cache is so busy that snooping invariably makes the CPU wait.
I used to be an advocate of the MIPS position; but what this argument
ignores is the difficulty of maintaining a portable software base,
particulary an OS which (like Linux) has grown up with invisible x86
To make sure that Linux/MIPS kernels are and remain robust we have to
convince lots of people to take the trouble to learn about visible
caches - even though the systems they're working on don't have them.
And we have to hope that driver writers will do the right thing, even
though they've never used a system which needs cache management code
and have none at hand to test their drivers with...
This would be unlikely even if we all agreed what the word 'flush'
meant (does it mean "invalidate"? or "write-back"? or perhaps "both,
if necessary"? and can you build a robust OS without knowing the
It *could* happen. MIPS are not the only family of CPUs with visible
caches - though I think they probably have by far the most complicated
ones, because of their high-end history.
The meeting of Linux and MIPS is in this respect really good for Linux
- great at finding portability problems. But it's not particularly
good for MIPS. For now, Linux/MIPS kernels will only be reliable if
maintained by people who understand this stuff, keep a safe distance
from the x86 mainstream, and use only sanity-checked drivers.
Kevin, I think you'd better tell your colleagues who design the chips
that they'd better put some snooping in, and soon...