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

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

To: Dominic Sweetman <dom@algor.co.uk>
Subject: Re: PROPOSAL : multi-way cache support in Linux/MIPS
From: Jun Sun <jsun@mvista.com>
Date: Wed, 02 Aug 2000 14:38:52 -0700
Cc: linux@engr.sgi.com, linux-mips@fnet.fr, ralf@oss.sgi.com
References: <398762B9.D8507860@mvista.com> <200008021812.TAA11550@mudchute.algor.co.uk>
Sender: jsun@hermes.mvista.com
Dominic Sweetman wrote:
> 
> 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". 

Actually Sony's R4500 uses the same low bits mechanism.

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

Ideally - but no in reality.  Linux stills uses index-operations a lot.

Theorically, indexed flush is faster if the flushing are is bigger than
the cache size.

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

If Vr5432 is really that unique, I think that is probably best way, at
least for now.

Jun

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