Re: way selection bit for multi-way cache

[Ralf Baechle <ralf@linux-mips.org>]

On Thu, Apr 10, 2003 at 01:28:41PM -0700, Mike Uhler wrote:

> > 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.

Linux has a flush_cache_page() cache operation which is used to invalidate
a page given by a virtual user-space address.  That page might be the
page of a current processor which is the easy case - it might also belong
to another process.  In the later case the TLB would miss-translate
the virtual address because the translation in the TLB is actually for
the current process.  So this is what we're doing then:

[...]
        /*
         * Do indexed flush, too much work to get the (possible) TLB refills
         * to work correctly.
	 *
	 * Note: page is the physical address of the page to invalidate.
         */
        page = (KSEG0 + (page & (dcache_size - 1)));
	/*
	 * The following two flush operations have to flush the page from
	 * all cache ways!
	 */
        blast_dcache_page_indexed(page);
        if (exec)
                blast_icache_page_indexed(page);
[...]

This can be a rather expensive operation in particular for caches with
a high degree of associativity.  The worst case would be something like
a page containing code for a processor with a 32k 8-way associative
caches where we'd have to flush the entire cache - costly overkill and
the refills might be even slower ...

  Ralf