Date: Thu, 9 Nov 2000 19:26:06 -0800 (PST) From: Matt Dillon <dillon@earth.backplane.com> To: Alfred Perlstein <bright@wintelcom.net> Cc: arch@FreeBSD.ORG Subject: Re: The shared /bin and /sbin bikeshed Message-ID: <200011100326.eAA3Q6015450@earth.backplane.com> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
: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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200011100326.eAA3Q6015450>