> 
> FreeBSD, on the other hand, encumbered with more Mach code, apparently continues
> to impose the same copy-on-write semantics on the parent vmspace, and this is
> apparently not undone in the exec().  The net result would thus appear to be --
> as in the old Mach vm I'm using with NetBSD 1.2 -- that the parent process will
> generate duplicate pages until the pageout daemon intervenes in a crisis
> (partly caused by the duplicate pages themselves) and triggers an object
> collapse (if indeed that happens, I'm not clear on that).
> 
FreeBSD does not need to use or create three pages like the old VM code
did, and hasn't for the last year++.  The source says it all!!!  If you
have a parent and child, there will normally only be two pages after COW,
unlike the older (seriously broken) VM code.  Collapse operations happen
very efficiently on FreeBSD, and that has been preliminarily fixed for the
last 4yrs, and fully fixed for the last 3yrs.  There was a time that we
did gratuitious collapse, but that was a result of legacy and not need.
If collapse operations were an issue at all in the performance picture,
we would have "fixed" the problem.  Frankly, the use of the VM object
inheritance scheme vs. other schemes is a matter of opinion.  At the
end of the day, the difference will be negligible, because that isn't
where the (performance or bug) problems have been in FreeBSD for years.

There are superficial similarities between the MACH and the FreeBSD VM code,
generalizing between the two is almost ludricrious nowadays.  EVERY modification
to the code was done with a reason directed towards scalability, bugfixing,
portability and even a little low-level efficiency.

The ONLY valid test for the code is to run the code under real-world conditions,
or with a properly modeled benchmark.  Lmbench and light loaded latency tests are
mostly only good for such benchmark loads.


John