Subject: Re: a new pmap_copy_page() and pmap_zero_page()
To: None <port-mips@netbsd.org>
From: Toru Nishimura <locore32@gaea.ocn.ne.jp>
List: port-mips
Date: 10/07/2003 17:31:54
> It's not perfect solution to have the new copy/zero because the whole issue
> here comes from the fact those pmap routines have no clue of target VA.
> Necessity to change some in MI (U)VM arena.

It'd not be hard to do after all.   Let say that the target MIPS processor has
32KB 4way configuration.  This brings 8KB cache slide, that is, two page
worth of VA to cover the cache, page and odd page.  Kernel can reserve
2 page worth of VA range in this case.

Now, pmap_zero_page() is called as the consequence of ZFOD (zero fill on
demand for a page) event occurs.  If pmap_zero_page() knew the target VA,
it could assign an appropriate range of reserved VA (even or odd) to clear
out the target page content.  There would be no necessity to flush/invalidate
the write-back cache lines since forthcoming page access does hit the correct
cache lines which were left by pmap_zero_page() call.

pmap_copy_page() is used (mostly?) in the event of COW (copy on write for
a page).  This means src VA and dst VA are identical between processes.
Selecting the _right_ reserved VA range to copy would eliminate the
flush/invalidating maneuver for write-back cache and cache lines would
remain useful for later access.

There are possible cases when src VA and dst VA might disagree in cache
slide, for example, fancy address sharing to go.  However, kernel should
have full control in choosing the new VA of these cases, and then difficulties
can be avoid.

Toru Nishimura/ALKYL Technology