linux-mips-fnet
[Top] [All Lists]

Re: [PATCH]: Linux for Baget/MIPS (r3k & VME box)

To: Dominic Sweetman <dom@algor.co.uk>, linux-mips@fnet.fr
Subject: Re: [PATCH]: Linux for Baget/MIPS (r3k & VME box)
From: ralf@uni-koblenz.de
Date: Mon, 24 Aug 1998 15:30:51 +0200
In-reply-to: <199808231337.OAA00405@gladsmuir.algor.co.uk>; from Dominic Sweetman on Sun, Aug 23, 1998 at 02:37:21PM +0100
References: <35DBDCAC.95D9FF44@niisi.msk.ru> <XFMail.980820215355.harald.koerfgen@netcologne.de> <199808210832.JAA00304@gladsmuir.algor.co.uk> <19980822114626.23656@uni-koblenz.de> <199808231337.OAA00405@gladsmuir.algor.co.uk>
On Sun, Aug 23, 1998 at 02:37:21PM +0100, Dominic Sweetman wrote:

> > Most caches today on other architectures are virtual indexed;
> > they're usually just implemented somewhat more clever such that they
> > feel like physical indexed caches to the OS.
> 
> It's common practice to restrict the cache set size to match the
> memory translation page size, so that only in-page addresses are used
> in the cache index - so from the index point of view virtual and
> physical addresses are the same.  Is that what you meant?  I can't see
> any other way of avoiding aliases in a virtually-indexed
> physically-addressed cache.

Yes, it's what I mean and in fact I don't see any other way either except
the R10000 style solution.  They seem to have some solution to cleanup
virtual aliases by automatically writing back / invalidating the affected
cache lines.

> The RM7000 has no aliases because it's 16Kbyte caches are 4-way set
> associative - 4Kbyte sets, equal to the page size.  However, that's
> only possible with the RM7000's relatively small primary cache, which
> in turn is practicable because it also has an onchip secondary cache.
> 
> I recall the first SuperSPARC chip had a 5-way set-associative 20Kbyte
> cache for the same reason.

Some PowerPC chips have 8-way associative caches for this reason.  I
just cannot imagine that going beyond 4-way associative caches will
still improve cache hits for them.

  Ralf

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