From: Ralf Baechle <ralf@linux-mips.org>
To: "Kevin D. Kissell" <kevink@mips.com>
Cc: Dominic Sweetman <dom@mips.com>, Mike Uhler <uhler@mips.com>,
Jun Sun <jsun@mvista.com>,
linux-mips@linux-mips.org
Subject: Re: way selection bit for multi-way cache
Date: Fri, 11 Apr 2003 14:10:45 +0200 [thread overview]
Message-ID: <20030411141045.A24953@linux-mips.org> (raw)
In-Reply-To: <004a01c30002$b3b19480$10eca8c0@grendel>; from kevink@mips.com on Fri, Apr 11, 2003 at 10:15:06AM +0200
On Fri, Apr 11, 2003 at 10:15:06AM +0200, Kevin D. Kissell wrote:
> > > > 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.
> >
> > Mike was proposing a kseg0 address translating to the right physical
> > address, and used with a hit-type cacheop. I believe Ralf (and Linux)
> > are just assuming that's no good because it doesn't work if you have
> > cacheable memory above 512Mbytes physical address.
>
> More importantly, it doesn't work in the case of virtually tagged caches,
> such as those in the SB-1 and MIPS 20K.
On SB1 we just switch to a new ASID which effectivly is a cheap way to
invalidate the entire I-cache. Assuming the other process has at most
4k of code resident in the I-cache from it's previous timeslice this
even is the optimal solution. But this optimization is a heuristic that
hasn't been verified to be optimal for performance.
> > I wonder whether anything really bad would happen if you temporarily
> > changed the (machine) ASID to that of the address space you wanted to
> > invalidate?
>
> I looked at that when we were investigating the aforementioned
> issues with virtually-tagged I-caches. It looked to me as if exceptions
> can occur during the invalidation, and that processing those exceptions
> can cause signals to be raised to the current process in a manner that
> assumes that the TLB and ASID are coherent and in sync with
> the scheduler. It may be that just changing the ASID temporarily
> would work - most of the time. It may even be that, with a bit
> of lashing down of state, disabling of interrupts, setting of flags
> to be read by traps.c/signal.c, etc, etc, it could be made bulletproof.
> But I don't think that the simple, obvious hack is safe.
Yep - it seems like a can of worms sufficiently large to be left closed
for 2.4 ...
Ralf
next prev parent reply other threads:[~2003-04-11 12:10 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
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 [this message]
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=20030411141045.A24953@linux-mips.org \
--to=ralf@linux-mips.org \
--cc=dom@mips.com \
--cc=jsun@mvista.com \
--cc=kevink@mips.com \
--cc=linux-mips@linux-mips.org \
--cc=uhler@mips.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