All of lore.kernel.org
 help / color / mirror / Atom feed
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.
> 

...

  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.