Date: Sat, 16 Nov 2002 23:04:42 -0800 From: David Schultz <dschultz@uclink.Berkeley.EDU> To: Gary Thorpe <gathorpe79@yahoo.com> Cc: Matthew Dillon <dillon@apollo.backplane.com>, freebsd-hackers@FreeBSD.ORG Subject: Re: cvs commit: src/bin/sleep sleep.c Message-ID: <20021117070442.GB23317@HAL9000.homeunix.com> In-Reply-To: <20021117034219.13731.qmail@web41201.mail.yahoo.com> References: <200211170158.gAH1wJhc035731@apollo.backplane.com> <20021117034219.13731.qmail@web41201.mail.yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Thus spake Gary Thorpe <gathorpe79@yahoo.com>: > > 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. BSS and modified data are not shared, and Matt is only counting zero fill and COW faults. If you have lots of copies of a shell running, pages will be shared more effectively with a static binary. A shell is about the worst thing you could possibly choose to dynamically link. Dynamic linking makes sense for X11, on the other hand, because you want to run many different binaries that share a large common library (and the binaries are slow as dirt anyway!) I've argued against dynamically linking /bin and /sbin before. (See the current@ archives around Oct 30.) I wouldn't mind if someone implemented it, but I don't want to see a dynamic /bin and /sbin become the default. (Enough people are clammoring about it that I fear that this will happen anyway.) The only half-convincing argument in support of it I've heard has been the disk space. But the default install isn't targetting embedded systems, it's targetting workstations and servers. Neither of the latter categories ought to be trading performance for 30 measly megabytes of disk and additional foot-shooting opportunities. > 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?). If you need pluggable locales, you might want dynamic linking. The other two can be done without dynamic linking, either by fixing dlopen() to work with static binaries or by creating daemons to handle the tasks. The former approach was discussed on current@ a few days ago, and I don't know much about it. The latter is also an entirely reasonable design, but someone needs to actually do the work. 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?20021117070442.GB23317>