[Top] [All Lists]

Re: Instability / caching problems on Qube 2 - solved ?

To: Dominic Sweetman <>
Subject: Re: Instability / caching problems on Qube 2 - solved ?
From: Ralf Baechle <>
Date: Mon, 15 Dec 2003 20:51:18 +0100
Cc: Peter Horton <>,
In-reply-to: <>
Original-recipient: rfc822;
References: <20031214162605.GA18357@skeleton-jack> <> <20031215083236.GA1164@skeleton-jack> <>
User-agent: Mutt/1.4.1i
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 ...


<Prev in Thread] Current Thread [Next in Thread>