Re: how to make Debian less fragile (long and philosophical)
On Tue, Aug 17, 1999 at 04:54:50PM -0400, Steve Willer was heard to say:
> > No memory cost? Care to rethink that again?
>
> I have been rethinking it, but as far as I can tell from reading the ldso
> source and from knowing a little bit about how linkers work, there is no
> RAM benefit from using shared libraries. The benefit is on the maintenance
> side, having shared code sitting in a single file. If you can point me to
> a page that explains where I'm wrong (if I am), then please do.
*blink*
Now _I'm_ confused. My understanding was that the library is loaded into
memory only once and shared between different processes (possibly with
copy-on-write set for the relevant pages), the same way that (eg)
one copy of bash is shared between every running bash process. Thus the term
'shared library'.
I have a book here on the Linux kernel, "Linux Kernel Internals". It's
somewhat outdated (it's from when 2.0.27 was current), but here on page 81
it describes how program images and shared library images..as far as I can
tell from a quick scan, Linux uses a shared mmap to load programs and
libraries. So shared libraries should really be shared.
A final point -- the top executable is only 34K. When I run it, I get
the following self-referential line:
PID USER PRI NI SIZE RSS SHARE STAT LIB %CPU %MEM TIME COMMAND
4364 daniel 12 0 1052 1052 848 R 0 7.3 2.2 0:00 top
Note that 848K of memory is being shared. This is almost certainly a shared
library (unless top is using shared memory for something else I'm not aware of)
-- it's certainly not the program itself. This also suggests that top might
bloat to around 800k if linked statically...
If I'm completely wrong someone please tell me :)
Daniel
--
The New Testament offers the basis for modern computer coding theory,
in the form of an affirmation of the binary number system.
But let your communication be Yea, yea; nay, nay:
for whatsoever is more than these cometh of evil.
-- Matthew 5:37
Reply to: