From: Jun Sun <jsun@mvista.com>
To: "Kevin D. Kissell" <kevink@mips.com>
Cc: linux@cthulhu.engr.sgi.com, linux-mips@fnet.fr, ralf@oss.sgi.com
Subject: Re: PROPOSAL : multi-way cache support in Linux/MIPS
Date: Wed, 02 Aug 2000 10:05:57 -0700 [thread overview]
Message-ID: <398854F5.EB3E73D6@mvista.com> (raw)
In-Reply-To: 008601bffc5b$6714c0a0$0deca8c0@Ulysses
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.
>
...
next prev parent reply other threads:[~2000-08-02 17:09 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-08-02 8:26 PROPOSAL : multi-way cache support in Linux/MIPS Kevin D. Kissell
2000-08-02 8:26 ` Kevin D. Kissell
2000-08-02 17:05 ` Jun Sun [this message]
-- strict thread matches above, loose matches on Subject: below --
2000-08-02 22:44 Kevin D. Kissell
2000-08-02 22:44 ` Kevin D. Kissell
2000-08-02 23:10 ` Jun Sun
2000-08-02 23:31 ` Ralf Baechle
2000-08-02 18:36 Kevin D. Kissell
2000-08-02 18:36 ` Kevin D. Kissell
2000-08-02 18:15 Kevin D. Kissell
2000-08-02 18:15 ` Kevin D. Kissell
2000-08-02 21:50 ` Jun Sun
2000-08-01 23:52 Jun Sun
2000-08-02 18:12 ` Dominic Sweetman
2000-08-02 21:38 ` Jun Sun
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=398854F5.EB3E73D6@mvista.com \
--to=jsun@mvista.com \
--cc=kevink@mips.com \
--cc=linux-mips@fnet.fr \
--cc=linux@cthulhu.engr.sgi.com \
--cc=ralf@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.