[BusyBox] choice for reserving buffers

[Manuel Novoa III]

On Fri, 26 Jan 2001, Vladimir N. Oleynik wrote:
> > Aaaah, but in a multi-call binary, _all_ utilities (as configured
> > at compile-time) are loaded (by execve, not fork) into RAM whenever
> > _any_ of those utilities will be run.
> 
> If it is necessary for user to work at once with all utilities simultaneously
> all this memory especially is necessary for utilities. 
> 
> Please run test in attach. 
> The test have 50M BSS buffer, and usage only 2M, and viewing this.

Vladimir, you are assuming that the system does lazy BSS memory allocation.

The way I see it, you have 2 cases:

1) the kernel does lazy allocation of memory (MMU)
   a) stack mem (coded or alloca)-- limited space, but is this really a problem?
         Each instance gets a new stack and, since we have an MMU, that stack
         is probably more than large enough for our needs.  In this case,
         do we really have a risk of exhausting stack mem in busybox?
   b) BSS mem -- Not actually allocated until needed.  Depending on mapping
         of variables in mem, max possible wastage is 2*(page size)-2 for each
         data structure.
   c) malloc'd mem -- Not actually allocated until needed.  Some overhead
         for malloc data structures and for each allocation.  Could be more
         or less wastage then BSS.  The app has a chance to deal with the
         situation if malloc fails.

   Now, the only time malloc should fail is if the kernel can't supply any
   more memory.  But, if the kernel can't supply any more memory, it wouldn't
   be able to allocate any previously unallocated BSS memory pages either.
   How different kernels deal with this, I don't know.  The kernel could panic,
   it could start randomly killing apps, etc.

2) the kernel does not do lazy allocation (no MMU)
    (NOTE!  The following is speculation, since I don't have a machine without
     an MMU.  If I'm mistaken, someone please correct me.)
   a) stack mem (coded or alloca) -- limited space -- Smaller stack than
         the MMU case since (I would think) it has to be actually reserved
         for each instance at startup.  In that case, exhaustion of the stack
         is a greater possibility.
   b) BSS mem -- ALL is allocated for EVERY instance of the running app.
         In you test case Vladimir, that would mean all 50M for each instance.
   c) malloc'd mem -- Same as case 1c above.

Note that above I didn't mention sbrk'd mem.  This might be an option in some
situations with similar properties to malloc'd mem and less overhead, but
possible interactions with libc routines using malloc.  Example:  Routine calls
libc to open a file -- libc mallocs file structure and frees when done, but
the malloc package may keep that mem around in a pool for a while.

Manuel