Subject: Re: ddb & shared libs: second results
To: None <jiho@postal.c-zone.net>
From: Ty Sarna <tsarna@endicor.com>
List: tech-kern
Date: 03/31/1998 16:03:09
In article <XFMail.980330174120.jiho@mail.c-zone.net> you write:
> Now that raises an interesting point. There's more than one way to look at
> speed. Nothing slows a system down like going into swap.
>
> In the past, I've noticed a lot of attention being paid to improving the way
> systems handle memory shortages, but not much to minimizing their occurence to
Not sure of the point you're getting at here. However, the box in
question has 32M and doesn't need to go to swap for "make build". So, I
don't believe low memory performance is an issue in this case. The
thing is just plain faster at spawning processes. Much faster -- I'd
almost have believed it if someone told me they'd switched the 486DX100
for a Pentium 133, unless I'd looked at the compile times for large
files (where the processes 'real' CPU time starts to win out -- make build
spends a lot of time spawning relatively short-lived processes, and so
the apparent great inefficiency of the Mach VM in that case is amplified
substantially).
At least a not insignificant part of this must be due to UVM proper and
not the new i386 pmap or vfork, because it was reported that a UVM VAX
kernel finished /etc/rc quite a bit faster (>20%, from memory), and I
don't believe vfork comes into play much if at all during that (since sh
doesn't use vfork).
> This is NOT to belittle the vm work Chuck and others have done, which certainly
> seems to fill a need -- I just haven't had a chance to evaluate any of it yet,
> so I don't know if my concerns are answered (to the extent that my concerns
> involve the way the kernel itself works). The desire to do so is obstructed by
> the necessity of installing a complete new distribution, and setting up a
> working envoirnment almost from scratch.
I don't think this is unreasonable. VM is so fundamental you can't
expect it to be much of a drop-in replacement. I was plesently
supprised how well UVM seems to coexist in the same tree, even so. I
remember FreeBSD's VM changes had seeming endless reprecussions all over
their tree. And they started with the same base, rather than from
near-scratch, as Chuck did.
And at any rate, if you really want to evaluate it, especially in terms
of "sloppyness" and handling of extreme conditions, you'll have to read
the source, and all you need to do that is ~600K of disk space.