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

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

To: "Kevin D. Kissell" <kevink@mips.com>
Subject: Re: PROPOSAL : multi-way cache support in Linux/MIPS
From: Jun Sun <jsun@mvista.com>
Date: Wed, 02 Aug 2000 10:05:57 -0700
Cc: linux@cthulhu.engr.sgi.com, linux-mips@fnet.fr, ralf@oss.sgi.com
References: <008601bffc5b$6714c0a0$0deca8c0@Ulysses>
Sender: jsun@hermes.mvista.com
Kevin,

This looks great, something exactly I was hoping for!

A couple of questions :

. What about the actual cache operation routines (flush_cache_page,
...)?  Are they divided into R4xxx, R3xx, etc?  I guess I am curious how
the code is organized.

. Your structure gives the number of ways, but no info about how to
select a way.  How would do an index-based cache operation?  It seems to
me you probably need something like cache_way_selection_offset in the
cpu table.

Jun

"Kevin D. Kissell" wrote:
> 
> Rather than re-invent the wheel, please consider the
> cache descriptor data structures we developed at
> MIPS to deal with this problem.  I believe that the
> updated cache.h file, and maybe even the cpu_probe.c
> file, was checked into the 2.2 repository at SGI long ago.
> There are also a set of initialisation and invalidation routines
> that key off the cache descriptor structure, but those aren't
> in the SGI  repository (though anyone can get them from
> ftp.mips.com or www.paralogos.com).  The CPU probe
> logic (also on those sites, and already integrated
> into several variants because it also supports setting
> up state needed by the software FPU emulation)
> is table-based, and for each PrID value, there is
> a template for the cache characteristics, which
> can either be taken "as is" or probed, depending
> on a flag in the descriptor.  Since the number of
> "ways" cannot always be determined by probing,
> if the number of ways is specified, it is preserved
> even if a cache probe is performed.   I won't attach the
> full set of cache probe routines (which would only confuse
> things), but here is the cache data structure definition
> and the CPU descriptor template table that we use.
> 

...

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