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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 ...

  Ralf


[Index of Archives]     [Linux MIPS Home]     [LKML Archive]     [Linux ARM Kernel]     [Linux ARM]     [Linux]     [Git]     [Yosemite News]     [Linux SCSI]     [Linux Hams]

  Powered by Linux