At Tue, 03 Jul 2012 16:43:04 +0200, Johnny Billquist
<bqt%update.uu.se@localhost> wrote:
Subject: Re: NetBSD/vax performance (Was: /etc/disktab on vax)
>
> Kernel size isn't the problem. I have a 4000/90 with 128MB of memory,
> and it makes no difference... It's become bog slow.
> gcc in itself makes a difference when you are compiling, but I suspect
> the biggest cost is additional code paths all over the kernel, such as
> kauth. Same for userland, where you have pam. They are all rather
> heavy. I remember when we switched from sendmail to postfix. Startup
> time for a VAX increased from a few seconds to over a minute to just
> start the mail daemon...
That slow-down smells mostly like dynamic linking to me.... If you turn
on system accounting how much time goes to ld.so? Postfix starts many
more processes when it starts than sendmail does, and that means running
ld.so for each and every new exec().
I'd be curious to see the difference if you were to boot the system with
all binaries crunchgen'ed into one static-linked file such that all code
pages are shared _entirely_ and with zero exec startup cost (just the
fork) -- indeed often only a single page will have to be loaded to start
_any_ new process. A new shell image started by an exec, for example,
starts immediately with no I/O regardless of which user starts it
(because all the pages will already be in RAM), whereas on a dynamic
linked system each new shell (i.e. when started by a non-shell, such as
by login) has to be link-loaded by ld.so _again_, even if there's
already a shell running for another user. Even on a modern multi-core
x86-64 machine with blindingly fast disks the speed-up is quite
noticeable, and on a small modern system, such as an AMD GEODE based
board, the difference is massive, even over plain static linking. For a
VAX the difference should be out of this world! The memory savings for
a running system are also stunning, and equivalent to the disk savings.
My binary, with almost all of userland in it (except toolchain, named,
and postfix (and csh)) is just:
$ size ramdiskbin
text data bss dec hex filename
9338817 268924 4224976 13832717 d3120d ramdiskbin
$ ls -l ramdiskbin
-rwxr-xr-x 1 woods wheel 9608808 Sep 11 12:48 ramdiskbin
There are 270 different programs in there. That's everything you need
to run a normal unix box with networking (sans toolchain and a mailer).
No matter how many processes you run, and no matter how diverse the mix
of programs is, your system will never need more than 9MB of RAM for
text space, even if you run every different program a dozen times over
and all at the same time. The same set of binaries, static-linked,
requires almost a gigabyte of disk space. Even dynamic-linked they
would likely require a couple of orders of magnitude more disk space
(100MB or more -- I don't know for sure as I have no accessible systems
that are dynamic linked!).
I don't have postfix in my crunchgen binary yet, but I could try fitting
it in there and then send someone the config file if they wanted to try
it out. Right now I only build it as part of a ramdisk system, and I
want to try splitting that out too so that I can build regular
production systems with entirely crunchgen'ed userlands.
--
Greg A. Woods
Planix, Inc.
<woods%planix.com@localhost> +1 250 762-7675 http://www.planix.com/
Attachment:
pgpqqDkW_STvE.pgp
Description: PGP signature