Subject: third results (was: ddb & shared libs)
To: Chuck Cranor <chuck@maria.wustl.edu>
From: None <jiho@postal.c-zone.net>
List: tech-kern
Date: 04/01/1998 21:33:57
On 30-Mar-98 Chuck Cranor wrote:

>> I do hope UVM is more efficient that this sucker.
>
> well you can always try it and see.    
>
> in the mean time, if you want to keep looking at Mach code, you should
> also check out the FreeBSD stuff.

In comparing UVM and FreeBSD, what interests me is the implementation of
vfork(), since that would seem to be at the heart of the problem I've been
moaning about.

Looking in the current source, UVM appears to do the right thing.  The parent
vmspace is used by the child until exec(), where it's released and a new
vmspace created for the child.  No funny business is inflicted on the parent. 
Very fast, very clean.

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).

Which would explain why, when I briefly evaluated a FreeBSD pre-3.0 snapshot, I
didn't see any improvement over NetBSD 1.2.  In fact it looked somewhat worse,
due to its dynamic buffer cache growing a bit larger than NetBSD's fixed buffer
cache.  (It would give most of that up, of course.)

So, without having evaluated UVM at all, and having evaluated a preview of the
next FreeBSD only quickly and superficially, I'd speculate that UVM ought to
solve the problem while FreeBSD won't.


--Jim Howard  <jiho@mail.c-zone.net>


----------------------------------
E-Mail: jiho@mail.c-zone.net
Date: 01-Apr-98
Time: 21:33:57

This message was sent by XFMail
----------------------------------