_clear_page semantics

_clear_page semantics

[Justin Carlson]

Looking at the existing clear_page implementations for r4xx0, rm7k, and mips32
in the mips/ tree, I see everyone issuing cache op 0xd for the address range of
the page being cleared.

I'm wondering what the purpose is of these cache flushes...given a physically
tagged dcache, my understanding of the semantics of clear_page are that it just
zeros the page, in which case the cache ops are pointless overhead.

Especially in the mips32 case, which uses cache op 0xd, which is undefined
implementation dependent according to my mips32 spec.

Am I missing something here?

Thanks,
Justin

Re: _clear_page semantics

[Ralf Baechle]

On Tue, Jan 09, 2001 at 05:48:11PM -0800, Justin Carlson wrote:

> Looking at the existing clear_page implementations for r4xx0, rm7k, and mips32
> in the mips/ tree, I see everyone issuing cache op 0xd for the address range of
> the page being cleared.
> 
> I'm wondering what the purpose is of these cache flushes...given a physically
> tagged dcache, my understanding of the semantics of clear_page are that it just
> zeros the page, in which case the cache ops are pointless overhead.
> 
> Especially in the mips32 case, which uses cache op 0xd, which is undefined
> implementation dependent according to my mips32 spec.

The idea is to avoid unnecessary memory reads - all the read data would
be overwritten anyway.  The last time I benchmarked this routine on some
machine it made a difference of about 4000 vs. 2500 c0_count cycles.  I
think that was on a R4600 RM200.

  Ralf

Re: _clear_page semantics

[Carsten Langgaard]

Justin Carlson wrote:

> Looking at the existing clear_page implementations for r4xx0, rm7k, and mips32
> in the mips/ tree, I see everyone issuing cache op 0xd for the address range of
> the page being cleared.
>
> I'm wondering what the purpose is of these cache flushes...given a physically
> tagged dcache, my understanding of the semantics of clear_page are that it just
> zeros the page, in which case the cache ops are pointless overhead.
>
> Especially in the mips32 case, which uses cache op 0xd, which is undefined
> implementation dependent according to my mips32 spec.

You are absolutely right, it is implementation dependent.
I just tend to use the mips32 implementation for my R4000s as well, and here as
Ralf mention it is performance improving.
Actually we have included a CPU option flag (MIPS_CPU_CACHE_CDEX), what tells us
if the CPU has the Create_Dirty_Exclusive CACHE operation available.
So we should probably use it, now it is here :-)

Thanks.

>
> Am I missing something here?
>
> Thanks,
> Justin

--
_    _ ____  ___   Carsten Langgaard   Mailto:carstenl@mips.com
|\  /|||___)(___   MIPS Denmark        Direct: +45 4486 5527
| \/ |||    ____)  Lautrupvang 4B      Switch: +45 4486 5555
  TECHNOLOGIES     2750 Ballerup       Fax...: +45 4486 5556
                   Denmark             http://www.mips.com

Re: _clear_page semantics

[Ralf Baechle]

On Wed, Jan 10, 2001 at 09:08:08AM +0100, Carsten Langgaard wrote:

> You are absolutely right, it is implementation dependent.
> I just tend to use the mips32 implementation for my R4000s as well, and here as
> Ralf mention it is performance improving.
> Actually we have included a CPU option flag (MIPS_CPU_CACHE_CDEX), what tells us
> if the CPU has the Create_Dirty_Exclusive CACHE operation available.
> So we should probably use it, now it is here :-)

Homework for somebody with some time at his hands - we have a large number
of unrolled loops for all sorts of cache variations in r4xx0.c.  Benchmark
if they actually improve performance.  I wouldn't wonder if due to a large
number of pipeline stalls in one of those routines the whole unrolling
business doesn't buy us anything.

  Ralf