Date: Sat, 16 Nov 2002 17:58:19 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: "M. Warner Losh" <imp@bsdimp.com> Cc: bright@mu.org, nate@root.org, hackers@FreeBSD.ORG Subject: Re: cvs commit: src/bin/sleep sleep.c Message-ID: <200211170158.gAH1wJhc035731@apollo.backplane.com> References: <200211151925.gAFJPsgh037805@apollo.backplane.com> <20021115194347.GG50692@elvis.mu.org> <200211152017.gAFKHbFS044142@apollo.backplane.com> <20021116.174331.28768088.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
:I personally thing that we should have a shared /{s,}bin in 5.0 and
:that it should be the dafult and that it should work with / and /usr
:being on different partitions. Preliminary indications are that we'd
:save on the order of 25M-30M on /, which makes up for the additional
:kernel modules we now install.
:
:Warner
Well, I actually have an objection to having a shared [s]bin by default.
There is no reason to save disk space if you have plenty of it, and a
dynamic binary eats a lot more memory when running then a static one.
This may not matter for programs like chmod or chown, but it does matter
for programs which are separately exec'd (rather then fork'd) such as
/bin/sh and /bin/csh. A shared sh or csh will create a noticeable
detriment on multi-user machines which are running a lot of instances of
them.
Take /bin/csh (aka tcsh) for example.
Startup overhead if static: 144 pages faults, 113 zero fill, 64 COW
Startup overhead if dynamic: 310 page faults, 131 zero fill, 84 COW
So the difference is 38 pages of memory = 152KB per instance.
That's fairly significant on a multi-user system that might have
several hundred csh's running. I specifically compile certain
non-forked binaries on my system static precisely to reduce their
memory footprint.
The only real usefulness of a dynamic [s]bin (and a mini-c static
or dynamic [s]bin for that matter), is going to be in turnkey
products or for bootstrapping purposes (e.g. like a two-floppy boot),
and for such products I do not see any particular need of a
/recovery feature. They serve no other useful purpose.
I suppose that is an argument against a static/mini-c combination
which leaves only a dynamic/mini-c combination useful. This would
also argue that the only usefulness of a mini-c in this case is to
strip as much out of it as possible. For example, to strip out
YP, to dummy-up stdio, and so forth... to create a result that
would be significantly useful in an embedded system but just as
significantly NON-useful in a normal system.
-Matt
Matthew Dillon
<dillon@backplane.com>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200211170158.gAH1wJhc035731>