Re: how i can know the linux-mips implememt cache strategy?

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

On Sat, Nov 21, 2009 at 09:18:26AM -0600, Shane McDonald wrote:

> > The kernel will always use cache stategy 3 for non-coherent systems and
> > caching strategy 5 for cache coherent systems.  These two select the most
> > aggressive caching strategy on all processors and that's what gives the
> > best performance.
> 
> OK, dumb question -- how is this implemented?  Poking through the code,
> it looks to me that the cache strategy used comes from the K0 field of the
> coprocessor 0 Config register, which I think is whatever gets set up by
> the bootloader, or if that wasn't done, the default value of that
> field for the processor.

The K0 field's value after reset is undefined btw.  The kernel assumes that
the firmware on a particular platforms knows the the right values and
just uses it.

> See function coherency_setup() in arch/mips/mm/c-r4k.c:
> 
>         if (cca < 0 || cca > 7)
>                 cca = read_c0_config() & CONF_CM_CMASK;
>         _page_cachable_default = cca << _CACHE_SHIFT;
> 
> This can be overridden on the kernel command line with the "cca" parameter,

This is a special feature for MTI's multi-core product.  Tbh, I can't quite
recall why it was added but I have faint memories of this being required
to work around a miss-features in early revisions of PMON for it.  In the
best spirit of free software the cca= command line argument however is
available for anybody to shoot themselves into their feet.  It'd probably
be quite interesting to try a few benchmarks.

> but as Ralf said in
> http://www.linux-mips.org/archives/linux-mips/2008-06/msg00186.html,
> "passing a CCA value on the command line is nothing a user should
> ever, ever have to do".

Because users almost certainly don't understand the implications.  I mean
having to know ISA interrupts was stupid yet comparably trivial ...

> I can see how this was implemented in 2.6.25, but commit 3513369
> [MIPS] Allow setting of the cache attribute at run time, seems to have changed
> from the behaviour Ralf described.

  Ralf