linux-mips
[Top] [All Lists]

Re: way selection bit for multi-way cache

To: "Kevin D. Kissell" <kevink@mips.com>
Subject: Re: way selection bit for multi-way cache
From: Ralf Baechle <ralf@linux-mips.org>
Date: Fri, 11 Apr 2003 14:10:45 +0200
Cc: Dominic Sweetman <dom@mips.com>, Mike Uhler <uhler@mips.com>, Jun Sun <jsun@mvista.com>, linux-mips@linux-mips.org
In-reply-to: <004a01c30002$b3b19480$10eca8c0@grendel>; from kevink@mips.com on Fri, Apr 11, 2003 at 10:15:06AM +0200
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <20030410220906.B519@linux-mips.org><200304102028.h3AKSf211575@uhler-linux.mips.com><20030410225212.A3294@linux-mips.org> <16022.24992.314581.716649@gladsmuir.mips.com> <004a01c30002$b3b19480$10eca8c0@grendel>
Sender: linux-mips-bounce@linux-mips.org
User-agent: Mutt/1.2.5.1i
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

<Prev in Thread] Current Thread [Next in Thread>