Re: Cache flush statistics patch to c-mips32.c

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

On Wed, Apr 02, 2003 at 09:16:20PM +0200, Hartvig Ekner wrote:

> Below is a patch with some cache statistics counters added to c-mips32.c.
> They are turned on by the local define DEBUG_COUNTERS in case somebody wants to
> play with them.
> 
> A sample output:
> 
> [root@au01 root]# more /proc/cmips32_cache_stats
> 
> Cache statistics from c-mips32.c:
> 
> mips32_flush_cache_all_pc:      83384    mips32_flush_cache_all_sc:          0
> mips32_flush_cache_range_pc:    37276    mips32_flush_cache_range_sc:        0
> mips32_flush_cache_mm_pc:        2121    mips32_flush_cache_mm_sc:           0
> mips32_flush_cache_page_pc:     36282    mips32_flush_cache_page_sc:         0
> 
> mips32_flush_icache_all:            0    mips32_flush_icache_page_s:         0
> mips32_flush_icache_range:          4    mips32_flush_icache_page:       93545
> mips32_flush_data_cache_page:   31905    mips32_flush_cache_sigtramp:     2467
> 
> dma_cache_wback_inv_pc:          7029    dma_cache_wback_inv_sc:             0
> dma_cache_inv_pc:                   0    dma_cache_inv_sc:                   0

As already mentioned, c-mips32.c is a pretty lousy piece of code.  It's
basically a cut'n'paste from an ancient, rotten version of r4xx0.c.  So
it also includes wrecked support for R4000SC-style second level caches,
that's all the _sc functions above which aren't called ever.  As of like
an hour ago I've removed all this dead code.

Similarly flush_icache_all, it's only used for processors that have a
virtually indexed virtually tagged I-cache.  Currently there only two of
these processors do exist, the one is Sibyte's SB1 core which is used in
the BCM1250 SOC and the other is MIPS's upcoming 20kc core.

> These counts are from a system which has just booted, nothing else. While
> running some programs, the flush_cache_all is called up to 400 times pr.
> second (!).

Flush_cache_all is invoked by the overkill implementation of sys_cacheflush.
These calls are usually done only by certain code constructs and the only
common user is glibc.  The part of glibc using cacheflush(2) is the
dynamic linker so the penalty for longer running processes is getting
lower.

Anyway, c-mips32.c is frightening for processors with alias-free caches
such as the virtually indexed 16kb 4-way caches of your Au1500.  For
example flush_cache_all() and flush_dcache_page() should be empty and
flush_cache_page() only needs to do something at all for pages that do
contain code etc.  There's a major speedup hidden there.

  Ralf