In message <041215231717.M0126847@mirage.ceres.dti.ne.jp>, you write: 

-> In article <20041215133810.E6EB92356B@thoreau.thistledown.com.au>
-> simonb@wasabisystems.com wrote:
-> 
-> > So we want the reverse of the above - add a CPU_MIPS_VCE flag for R4000
-> > and R4400.  Is it the case that the R10000 doesn't need any L2 and still
-> > handles cache aliases properly (and so we'd need a separate flag for the
-> > R10000)?
-> 
-> According to nisimura-san, L2 cache is mandatory for R10000.
-> (i.e. all R10000 systems have L2 cache)
-> 
-> Maybe we should try some benchmark to see if the CPU_MIPS_VCE (or so)
-> flag makes some performance benefits.
-> 
-> IIRC, it was a bit faster to flush cache pmap_{copy,zero}_page()
-> implicitly and remove cache flush from cpu_lwp_fork().

As some point (last spring?) I actually had a go at whacking the copy/zero
page routines to map the pages (reserving a bit of virtual address space 
in the pmap just for this) and doing the zero/copy via the the mapped
address and even ran some performance numbers which (IIRC) showed that
things got a bit faster at least on the R5k.

I stalled on a couple of things, the first being lack of time to test on
the R4k/R4600 and the second being not knowing how the change would be
affect other CPUs I didn't have to play with.  In the end I went with a
function-pointer based approact for the zero/copy operations, setting them
based on CPU type.

The final piece I stalled on was on a way to have UVM pass down mapping
hints for the pages being copied/zeroed so that the mapping used in the
pmap could be color-compatible with the actual (or intended) mapping of
the page.

I'll try and unearth this stuff (both code and performance data) sometime
over the christmas holiday (if it's not already in the archives of either
port-mips or port-sgimips).

--rafal

----
Rafal Boni                                                     rafal@pobox.com
  We are all worms.  But I do believe I am a glowworm.  -- Winston Churchill