linux-mips-fnet
[Top] [All Lists]

Re: PROPOSAL : multi-way cache support in Linux/MIPS

To: Jun Sun <jsun@mvista.com>
Subject: Re: PROPOSAL : multi-way cache support in Linux/MIPS
From: Dominic Sweetman <dom@algor.co.uk>
Date: Wed, 2 Aug 2000 19:12:34 +0100 (BST)
Cc: linux@engr.sgi.com, linux-mips@fnet.fr, ralf@oss.sgi.com
In-reply-to: <398762B9.D8507860@mvista.com>
References: <398762B9.D8507860@mvista.com>
Jun Sun (jsun@mvista.com) writes:

> The first issue is multi-way cache support.  DDB5476 uses R5432 CPU
> which has two-way set-associative cache.  The problematic part is
> the index-based cache operations in r4xxcache.h does not cover all
> ways in a set.
> 
> I think this is a problem in general.  So far I have seen MIPS
> processors with 2-way, 4-way and 8-way sets.  And I have seen them
> using ether least- significant-addressing-bits or
> most-significant-addressing-bits within a cache line to select ways.

So far as I know the Vr5432 is the only CPU to do anything so silly as
using the lowest index bits to select the "way".  Certainly most CPUs
put the "way" bits above the cache-store-index; and MIPS now require
it to be done like that for MIPS32 and MIPS64 compatible parts.

The MS-selects-way organisation permits the cache to be initialised
without the software ever needing to know how many ways it has (just
crank the index up, but being careful about the tendency to recycle
the same way when pre-filling cache data).

Cache maintenance should always use "hit" type instructions, and you
don't need to know the cache organisation for those, even with the
Vr5432. 

I suggest you should implement the don't-care method, and then have a
cpu_info-driven special case for the unique and deprecated Vr5432.

Dominic Sweetman
Algorithmics Ltd
dom@algor.co.uk

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