From: "Mike Uhler" <uhler@mips.com>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: Mike Uhler <uhler@mips.com>, Jun Sun <jsun@mvista.com>,
linux-mips@linux-mips.org, uhler@mips.com
Subject: Re: way selection bit for multi-way cache
Date: Thu, 10 Apr 2003 13:28:41 -0700 [thread overview]
Message-ID: <200304102028.h3AKSf211575@uhler-linux.mips.com> (raw)
In-Reply-To: Your message of "Thu, 10 Apr 2003 22:09:06 +0200." <20030410220906.B519@linux-mips.org>
> On Thu, Apr 10, 2003 at 12:37:47PM -0700, Mike Uhler wrote:
>
> > > The question came up between Jun and me when revising the way of handling
> > > multi-way caches. There is the MIPS32 / MIPS64 way of selecting the
> > > cache way - but that scheme was originally already introduced by the
> > > R4600. The second somewhat less common scheme is using the lowest bits
> > > of the address. That was originally introduced with the R10000 but a
> > > few other processors such as the R5432 and the TX49 series are using it
> > > as well. Unfortunately there has been way to much creativity (usually
> > > a positive property but ...) among designers so this posting is an
> > > attempt to achieve completeness.
> >
> > Exactly why we made it a standard in MIPS32 and MIPS64.
>
> Yep, of the existing variations that was certainly the nicest. Only a
> single function had to be taught about multi-way caches and that only
> because it's a bit hard to flush caches for another process due to the
> TLB translation required for the hit cacheops. Alternative schemes need
> more support by the code.
I'm not sure what you mean by TLB translations required for hit cacheops.
If you mean the Index Writeback or Index Invalidate functions, note that
you can (and should) use a kseg0 address to do this. This bypasses
the TLB, while still giving you the index that you want. We simply
OR the kseg0 base address into the index that we've calculated and
use that as the argument to the CACHE instruction. There's actually
words to this effect in the MIPS32/MIPS64 spec, but it is, perhaps,
not clear enough.
/gmu
WARNING: multiple messages have this Message-ID (diff)
From: "Mike Uhler" <uhler@mips.com>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: Mike Uhler <uhler@mips.com>, Jun Sun <jsun@mvista.com>,
linux-mips@linux-mips.orguhler@mips.com
Subject: Re: way selection bit for multi-way cache
Date: Thu, 10 Apr 2003 13:28:41 -0700 [thread overview]
Message-ID: <200304102028.h3AKSf211575@uhler-linux.mips.com> (raw)
Message-ID: <20030410202841.4CNYcz31DPSeml3fU4Wl6Q5ykUgK7Ndr9N12HhjGGjs@z> (raw)
In-Reply-To: Your message of "Thu, 10 Apr 2003 22:09:06 +0200." <20030410220906.B519@linux-mips.org>
> On Thu, Apr 10, 2003 at 12:37:47PM -0700, Mike Uhler wrote:
>
> > > The question came up between Jun and me when revising the way of handling
> > > multi-way caches. There is the MIPS32 / MIPS64 way of selecting the
> > > cache way - but that scheme was originally already introduced by the
> > > R4600. The second somewhat less common scheme is using the lowest bits
> > > of the address. That was originally introduced with the R10000 but a
> > > few other processors such as the R5432 and the TX49 series are using it
> > > as well. Unfortunately there has been way to much creativity (usually
> > > a positive property but ...) among designers so this posting is an
> > > attempt to achieve completeness.
> >
> > Exactly why we made it a standard in MIPS32 and MIPS64.
>
> Yep, of the existing variations that was certainly the nicest. Only a
> single function had to be taught about multi-way caches and that only
> because it's a bit hard to flush caches for another process due to the
> TLB translation required for the hit cacheops. Alternative schemes need
> more support by the code.
I'm not sure what you mean by TLB translations required for hit cacheops.
If you mean the Index Writeback or Index Invalidate functions, note that
you can (and should) use a kseg0 address to do this. This bypasses
the TLB, while still giving you the index that you want. We simply
OR the kseg0 base address into the index that we've calculated and
use that as the argument to the CACHE instruction. There's actually
words to this effect in the MIPS32/MIPS64 spec, but it is, perhaps,
not clear enough.
/gmu
next prev parent reply other threads:[~2003-04-10 20:28 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-04-10 18:05 way selection bit for multi-way cache Jun Sun
2003-04-10 18:50 ` Mike Uhler
2003-04-10 18:55 ` Jun Sun
2003-04-10 19:24 ` Ralf Baechle
2003-04-10 19:37 ` Mike Uhler
2003-04-10 19:37 ` Mike Uhler
2003-04-10 20:09 ` Ralf Baechle
2003-04-10 20:28 ` Mike Uhler [this message]
2003-04-10 20:28 ` Mike Uhler
2003-04-10 20:52 ` Ralf Baechle
2003-04-11 6:33 ` Dominic Sweetman
2003-04-11 8:15 ` Kevin D. Kissell
2003-04-11 8:15 ` Kevin D. Kissell
2003-04-11 12:10 ` Ralf Baechle
2003-04-11 11:35 ` Ralf Baechle
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=200304102028.h3AKSf211575@uhler-linux.mips.com \
--to=uhler@mips.com \
--cc=jsun@mvista.com \
--cc=linux-mips@linux-mips.org \
--cc=ralf@linux-mips.org \
/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