Subject: Re: pmap_copy() is a lose
To: None <thorpej@zembu.com>
From: Paul Kranenburg <pk@cs.few.eur.nl>
List: tech-kern
Date: 06/16/2000 00:00:04
>  > So, I've disabled pmap_copy() on the i386 port.  I suggest that
>  > port-masters do the same for other ports which implement it.
> 
> The only other platforms that implement pmap_copy() are the sh3
> and pc532 -- i.e. the other platforms that have pmaps drived from
> the new UVM pmap for i386.  The SPARC has a pmap_copy(), but the
> body of the function is #if 0'd out.

I toyed with pmap_copy() on the sparc using a preliminary version
of UVM (this was three years ago) and came to the same conclusion
that it wasn't helpful. That's why it's still #if 0'd.

From a discussion with Chuck Cranor at the time:

> I tested a pmap_copy() on a sun4m. Basically, it does:
> 
>         for all pages in range 
>                 if src_addr has valid PTE
>                 pmap_enter(dst_map, dst_addr, PTE, ...)
> 
> I ran a program that tries to do as many fork()s as it can. The results
> are mildly interesting: while the number of faults/second decreases
> dramatically (a factor 10 or so), the system time is up by a factor
> of 3.
> 
> I suspect pmap_copy() is spending a lot of time copying mappings which
> are never used in the child processes. Since most fork()s will be
> followed by exec() pretty soon, I am now a bit doubtful on the
> benefits of pmap_copy().. but more varied testing should be done.