[KLUG Programming] Shared libraries & memory usage.

[Bruce Smith]

> >It's the daemons we are worried about.  We don't want the CD to cycle up
> >during the normal day of being a firewall.  For example, if I'm running
> >a NTP (or snort, or sshd, or dhcpd, or cipe, or syslog-ng, or ..... )
> >daemon on my firewall, I don't want the CDROM to cycle up as part of the
> >normal UNATTENDED operation.  That would slow things down and create a
> >potential point of failure.
> If memory were no object, compiling them all static is an idea. Maybe
> for some of the smaller ones (ntpd may be a good candidate) that may 
> be the solution. Someone might want to see what the impact of this is;
> if it ups your memory requirements a lot, then it's not a complete 
> solution.
> 
> The other problem is that it throws away economy of scale, since when 
> things are compiled static, the libraries are no longer re-entrant.

Ah, but memory is an object.  We're trying to cut the memory
requirements of Devil Linux.  In the last stable release, the minimum
memory required was 64MB.  At one point in the development release we
exceeded that by adding new software to the point it was hard to boot
with less than 96MB.

Since we started moving stuff to run off CD, we can now boot a bare
bones firewall in 40MB.  I'd like to see that go down to at least 32MB.

> >So we are wondering about the binary itself, and the shared libraries
> >the daemon uses.  Will those be loaded into memory, and STAY IN MEMORY,
> >when the daemon is initially started?  Or will it need to go back to CD?
> I can't think of anything that will GUARANTEE that they will stay in 
> memory. Things can always get swapped out if something needs real memory, 

One other point to complicate this.  This is a CD ONLY distribution. 
There is no hard drive required, and there is NO SWAP.  (unless you
count swapping to memory, which seems pointless to me :)

> and the swpper is pretty lazy about bringing stuff back in. I do suggest
> that careful study of swapping, the ld command, and the dynamic loader
> be conducted. There may be a facility or flag that makes the loader 
> VERY aggressive about keeping things in physical memory. Looking at ld
> carefully will give you a little more control over where and how symbols
> get resolved (address computed, not read!!) and where some symbol table 
> info resides. Then there's the swapper and memory manager, which someone
> needs to examine (kernal source) to see how/when it throws stuff out, and
> if it tries to keep re-entrant stuff in memory (especially stuff with 
> high refcounts, which is how I would write it, but what do I know?).
> 
> The goal may be not so much to eliminate CDROM reads, but make them as
> infrequent as possible. If that ain't good enough, maybe put only selected
> libs in the ramdisk?

As part of the day to day, unattended operation of the firewall, the
goal is NOT to fire up the CD at all.  This box needed to be dependable,
and the consensus of the Devil Linux developers is:  CDROM drives are
NOT dependable.

> Have I generated enough ideas (and work) for one message? :)

Getting there ...   :-)

I suspect this going to boil down to actually doing some trial & error
before we're convinced we're not spinning up the CD drive.

--------------------------------------------
Bruce Smith                bruce@armintl.com
System Administrator / Network Administrator
Armstrong International, Inc.
Three Rivers, Michigan  49093  USA
http://www.armstrong-intl.com/
--------------------------------------------