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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox