Date: Fri, 10 Nov 2000 08:43:36 -0800 (PST) From: Matt Dillon <dillon@earth.backplane.com> To: Peter Wemm <peter@netplex.com.au> Cc: Mike Smith <msmith@FreeBSD.ORG>, Alfred Perlstein <bright@wintelcom.net>, Warner Losh <imp@village.org>, arch@FreeBSD.ORG Subject: Re: The shared /bin and /sbin bikeshed Message-ID: <200011101643.eAAGhaf18348@earth.backplane.com> References: <200011101340.eAADeEW34342@mobile.wemm.org>
next in thread | previous in thread | raw e-mail | index | archive | help
:Text in a shared binary (and library) is clean too. All references go
:via the PLT and GOT.. and *they* are what get relocated and backed by swap.
:The more relocations, the larger this will be.
:
:> So in a low memory situation the static binary will win, because clean
:> pages use the already-existing binary file image as backing store and
:> do not have to go to swap. They can simply be discarded.
:
:*A* static binary, yes. If you are only using the one binary for all
:processes. I doubt many real-world out-of-memory situations are all due
:to a a single static vs. dynamic 'ps' binary shared 300+ times....
:More likely it'd be a runaway httpd or something, which are almost always
:shared anyway. Trying to run a static ps is going to need ~330K of ram.
:Trying to run a dyanmic ps is going to need ~25K of ram for the text+data
:and ~60K or so for the PLT/GOT glue, plus it will hook onto the already-present
:libc.so pages for text and COW any libc.so data pages...
:
:Cheers,
:-Peter
:--
:Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au
Lets test this:
stty tostop
0 3 0 27880 11328 6 0 0 0 35 0 0 0 631 648 217 2 2 97
0 3 0 26064 11328 3 0 0 0 0 0 2 0 614 317 129 1 2 98
ps &
0 3 0 31912 11188 3 0 0 0 0 0 0 0 609 364 147 0 2 98
1 3 0 29848 11188 7 0 0 0 0 0 0 0 617 448 140 1 2 97
static ps binary takes 11328 - 11188 = 140KB of ram
--
(cd into /usr/obj/..., relink ps without the -static)
procs memory page disks faults cpu
r b w avm fre flt re pi po fr sr ad0 ac0 in sy cs us sy id
0 3 0 28840 9444 9 0 0 0 6 0 0 0 608 325 131 2 2 97
0 3 0 28840 9444 14 0 0 0 6 0 0 0 623 410 153 0 2 98
ps &
0 3 0 25896 9232 176 0 0 0 81 0 0 0 613 541 155 1 3 96
1 3 0 25896 9232 10 0 0 0 6 0 0 0 620 460 174 1 2 98
kill %1
0 3 0 25580 9440 21 0 0 0 64 0 0 0 623 518 178 2 2 96
dynamic ps binary takes 9444-9232 = 212KB of ram.
This is on a normal system, running normal processes. I have a
vmstat running in one window, I run 'ps' in the other and then kill it.
I do this a couple of times to be sure it's only the ps that is showing up
in the vmstat memory utilization. Despite the fact that the dynamic 'ps'
has access to the shared libc library which is already mostly in core,
the dynamic 'ps' still eats an extra 72KB of memory. Now, I realize
that this isn't a perfect test -- but it does demonstrate my point
quite well I think.
You are welcome to run your own tests, Peter. People seems to have
gotten into their heads that dynamic binaries take up less memory
because they 'appear' to be smaller, but that simply is not the case
in most situations. Dynamic binaries save disk space. They generally
do not save ram.
-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?200011101643.eAAGhaf18348>