From owner-freebsd-hackers Sat Nov 16 17:58:24 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 15F9C37B401 for ; Sat, 16 Nov 2002 17:58:23 -0800 (PST) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9533343E75 for ; Sat, 16 Nov 2002 17:58:22 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.12.5/8.12.5) with ESMTP id gAH1wJFC035732; Sat, 16 Nov 2002 17:58:19 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.5/8.12.5/Submit) id gAH1wJhc035731; Sat, 16 Nov 2002 17:58:19 -0800 (PST) (envelope-from dillon) Date: Sat, 16 Nov 2002 17:58:19 -0800 (PST) From: Matthew Dillon Message-Id: <200211170158.gAH1wJhc035731@apollo.backplane.com> To: "M. Warner Losh" Cc: bright@mu.org, nate@root.org, hackers@FreeBSD.ORG Subject: Re: cvs commit: src/bin/sleep sleep.c References: <200211151925.gAFJPsgh037805@apollo.backplane.com> <20021115194347.GG50692@elvis.mu.org> <200211152017.gAFKHbFS044142@apollo.backplane.com> <20021116.174331.28768088.imp@bsdimp.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG :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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message