[Top] [All Lists]

Re: [PATCH]: Linux for Baget/MIPS (r3k & VME box)

To: Dominic Sweetman <>
Subject: Re: [PATCH]: Linux for Baget/MIPS (r3k & VME box)
Date: Sat, 22 Aug 1998 11:46:26 +0200
In-reply-to: <>; from Dominic Sweetman on Fri, Aug 21, 1998 at 09:32:25AM +0100
References: <> <> <>
On Fri, Aug 21, 1998 at 09:32:25AM +0100, Dominic Sweetman wrote:

> o R4000+ primary cache - odd arrangement using virtual addresses to
>   index the cache, but the physical 'tag' (that's the cache-held field
>   which holds the physical address so the CPU can check whether the
>   cache holds the data it wants).
>   The mix of virtual index and physical tags can lead to the strange
>   and feared "cache aliases" mentioned by an earlier correspondent;
>   it's possible to get copies of the same memory location stored in
>   different cache lines, if that location is being accessed at two
>   different virtual addresses.
>   [R4000's designers took the risk because it gave them a higher clock
>    rate - the cache lookup with the virtual address can now be done
>    in parallel with address translation.  Neat.]

Most caches today on other architectures are virtual indexed; they're
usually just implemented somewhat more clever such that they feel like
physical indexed caches to the OS.  The Alpha or PPC caches are examples.
I think the Rm7000 is the first 64 bit MIPS CPU where they got it right.

> You would only need to do something if your OS deliberately maps pages
> so as to risk cache aliases; this is possible on the R4000SC and
> R4000MC CPUs, because they use their secondary cache tags to watch for
> aliases and report (via an exception) when one tries to happen.
> Most OS' avoid cache aliases.  This is in fact quite easy.  Because
> MIPS memory virtual->physical translation is paged in 4K chunks, 
> address bits 0-11 are the same as physical addresses.  An 8K
> direct-mapped primary cache only employs address bits up to 12 in its
> index; so a particularly *physical* location can only ever appear in
> two places in the cache - depending on the value of bit 13 in the
> virtual address which currently maps to it.

Unfortunately the R4000SC / R4400SC always verify 3 bits of the virtual
tags in the second level cache.  And there is no provision in the Linux
kernel to allocate physical pages matches a special property like
physical_address[12:13]=2; adding is non-trivial.  As things are virtual
aliases are something that happens very common under Linux.  Linux uses
a single zero filled page like for example in the case when mmap(2)ing
/dev/zero and reading from one of the mapped pages.  Stupid SC/MC CPUs
will send VCE exceptions when accessing these mappings.  (``Stupid''
because VCE exceptions when neither the memory was an access

This was the simple case to fix - on R4000SC / R4400SC we just allocate
8 zero filled pages and match the physical page colour with the virtual
page colour when mmaping.


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