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

From: "Kevin D. Kissell" <[email-masked]>
Date: Wed, 2 Aug 2000 10:26:38 +0200

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.

            Regads,

            Kevin K.

-----Original Message-----
From: Jun Sun <[email-masked]>
To: [email-masked] <[email-masked]>;
[email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Date: Wednesday, August 02, 2000 2:01 AM
Subject: PROPOSAL : multi-way cache support in Linux/MIPS

>Ralf,
>
>I have got NEC DDB5476 running stable enough that I am comfortable to
>check in
>my code.  Will you take it?
>
>Assuming the answer is yes, there are several issues regarding checking
>in.
>I will bring them up one by one.
>
>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.
>
>Here is my proposal :
>
>. introduce two variables,
>        cache_num_ways - number of ways in a set
>        cache_way_selection_offset - the offset added to the address to
>select
>                next cache line in the same set.  For LSBs addressing,
>it is
>                equal to 1.  For MSBs addressing, it is equal to
>                cache_line_size / cache_num_ways.  (It can potentially
>take
>                care of some future weired way-selection scheme as long
>as
>                the offset is uniform)
>
>. These variables are initialized in cpu_probe().
>
>  (Alternatively, I think we should have cpu_info table, that contains
>all
>   these cpu information.  Then a general routine can fill in the based
>on
>   the cpu id.  This can get rid of a bunch of ugly switch/case
>statements.)
>
>. in the include/asm/r4kcache.h file, all Index-based cache operation
>needs
>  to changed like the following (for illustration only; need
>optimization) :
>
>-----
>        while(start < end) {
>                cache16_unroll32(start,Index_Writeback_Inv_D);
>                start += 0x200;
>        }
>+++++
>        while(start < end) {
>                for (i=0; i< cache_num_ways; i++) {
>                        cache16_unroll32(start +
>i*cache_way_selection_offset,
>                                         Index_Writeback_Inv_D);
>                }
>                start += 0x200;
>        }
>=====
>
>What do you think?  If it is OK, I can do the patch.  The cpu_info table
>is a nice wish, but I don't think I know enough to do that job yet.
>
>Jun

---

From: Jun Sun <[email-masked]>
Date: Wed, 02 Aug 2000 10:05:57 -0700

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

> and the CPU descriptor template table that we use.

...