On Mon, Dec 15, 2003 at 09:04:49AM +0000, Dominic Sweetman wrote:
> My prejudices are showing but...
> o Shouldn't the kernel should have a zero-tolerance policy towards cache
> aliases? That is, no D-cache alias should ever be permitted to
> happen, not even in data you reasonably hope might be read-only?
We're already trying hard to avoid such aliases. The case found by Peter
is clearly a bug and nothing else.
> Aliases only appeared by a kind of mistake when the R4000 was
> opportunistically repackaged without the secondary cache (the L2
> cache tags used to keep track of the virtually-indexed L1s, and you
> got an exception if you created an L1-alias).
> They really aren't a feature to be tolerated in the hope you can
> clean up before disaster strikes.
These days R4000SC is only an ancient processor - but very valuable for
Linux maintenance because it's virtual coherency exception is the
only available hardware detector for aliases.
> o And I could never get my brains round cache maintenance if I used
> the same word ("flush") both for invalidate and write-back.
I once had a discussion about the terminology with maintainers of other
architectures. Turned none of the MIPS terms were really unambigious;
does flush imply a writeback, does it imply invalidation? Does
invalidate imply writing back to memory or writeback imply invalidation
etc. etc. ad infinitum. Confusion pure ...