Date: Sat, 16 Nov 2002 22:42:19 -0500 (EST) From: Gary Thorpe <gathorpe79@yahoo.com> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: freebsd-hackers@freebsd.org Subject: Re: cvs commit: src/bin/sleep sleep.c Message-ID: <20021117034219.13731.qmail@web41201.mail.yahoo.com> In-Reply-To: <200211170158.gAH1wJhc035731@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--- Matthew Dillon <dillon@apollo.backplane.com> wrote:
> :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.
Remember that those 38 pages may be completely shared in a dynamic
library, leading to memory usage reductions. What is true is that the
startup time for dynamic binaries is most likely slower.
> 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
Other (major?) reasons I have heard in favor of dynamically linking
root:
a. locale support
b. nsswitch.conf support
c. PAM support (maybe this encompasses b.)
Dynamic linking has been said to be the only way to get locale support
and support for multiple authentication schemes. I don't know if
dynamic linking is absolutely necessary to supports these things from a
technical standpoint, but it would be nice to know (does anyone know?).
For embedded devices, a single crunchgened binary would probably
smaller anyway e.g. PicoBSD and installation floppies (?).
______________________________________________________________________
Post your free ad now! http://personals.yahoo.ca
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?20021117034219.13731.qmail>