From owner-freebsd-arch Thu Nov 9 19:26:15 2000 Delivered-To: freebsd-arch@freebsd.org Received: from earth.backplane.com (placeholder-dcat-1076843399.broadbandoffice.net [64.47.83.135]) by hub.freebsd.org (Postfix) with ESMTP id 699B137B4C5 for ; Thu, 9 Nov 2000 19:26:13 -0800 (PST) Received: (from dillon@localhost) by earth.backplane.com (8.11.1/8.9.3) id eAA3Q6015450; Thu, 9 Nov 2000 19:26:06 -0800 (PST) (envelope-from dillon) Date: Thu, 9 Nov 2000 19:26:06 -0800 (PST) From: Matt Dillon Message-Id: <200011100326.eAA3Q6015450@earth.backplane.com> To: Alfred Perlstein Cc: arch@FreeBSD.ORG Subject: Re: The shared /bin and /sbin bikeshed References: <200011091223.eA9CNQW26294@mobile.wemm.org> <200011091909.eA9J9wM10639@earth.backplane.com> <20001109112328.T5112@fw.wintelcom.net> <200011091944.eA9JiSN30771@vashon.polstra.com> <20001109115022.Y5112@fw.wintelcom.net> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :A lot of things in Linux defy explanation, all I know is what I :saw, which was root being unable to run 'ps' or 'kill' and the :error was that there wasn't enough free memory to map in libc.so. : :The really strange part was that root was able to log in, but :yet unable to do anything else. : :-- :-Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] Linking with a shared library eats memory at run time. It's that simple. Shared libraries make life easier but they do *NOT* generally reduce the run time in-core memory footprint of a machine. Dynamic executables actually increase the number of dirty pages the system has to cope with, at least for discretely-run programs, and they tend to force the entire shared library into core. Its a wash for programs that fork since the library relocations have already been done by the time you get to the fork, thus all the forked copies share the original parent's dirty library relocation pages. Don't forget that even static images can be demand-paged, and for a static image paging equates to simply throwing the page away since it is always clean. Demand-paging a dynamic binary requires writing some of those pages to swap due to the dynamic relocation, and each instance of the binary (when exec'd independantly) have their own private set of dirty pages to page out. So it makes a lot of sense for a dynamic binary to fall over in an extreme memory situation on a linux box when a static binary might not. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message