BusyBox dynamic linked on uClibc for init? [resources usage] (fwd)

Denys Vlasenko vda.linux at googlemail.com
Fri May 13 01:45:06 UTC 2011

On Thursday 12 May 2011 16:04, Laurent Bercot wrote:
> > The device has MIPS based CPU in mipsel arch and it's running Linux.
> > I use one BusyBox static, stripped binary with most applets compiled in, 
> > and it's size is around 1,4MB.
> > (...)
> > Most of the time there are only few BusyBox processes running but in some 
> > cases (many shell and cgi scripts) there can be a lot more BusyBox 
> > processes running at once and some other than BusyBox processes can take 
> > most CPU and memory usage at times.
> > BusyBox is used quite extensively on this machine.
>  Two busybox processes, even when linked statically, will already share
> all their text. The cost of running N times the same binary is much
> lower than the cost of running N distinct binaries.
>  You could have a thousand busybox processes on your embedded machine without
> needing a gigabyte of RAM... fortunately. :)

in bbox source tree:

$ cd scripts
$ ./memusage
Before we started 4000 copies of '../busybox sleep 10':
03:35:51  190 238m
03:35:52  190 238m
03:35:53  190 238m
03:35:57 4190 423m
03:35:58 4190 423m
03:35:59 4190 423m
$ echo $(( (423-238)/4 ))

IOW: static i686 build, running on 64-bit kernel, consumes 46 mb of RAM
per 1000 busybox sleep processes, or 46 kbytes per process.

If I hack the script to instead run standard coreutils sleep
linked against glibc, memory consumption more than doubles.

>  It seems to me that you are confused.
>  * Binary size is not the same thing as RAM footprint. Usually, people
> mostly want to minimize RAM footprint first, because RAM is the most scarce
> (and expensive) resource.

... and memusage is a simple script to measure exactly that.


More information about the busybox mailing list