BusyBox dynamic linked on uClibc for init? [resources usage] (fwd)
ska-dietlibc at skarnet.org
Thu May 12 14:04:28 UTC 2011
> 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. :)
What you should profile is how many distinct processes *other than Busybox*
your machine is likely to be running most of the time. If you only have
two or three daemons, even if they're eating most of your RAM, then dynamic
linking is useless. Stick with linking everything statically, and save
yourself the headache of .so management.
If you have a dozen or so distinct daemons, dynamic linking will start
saving you some RAM (and definitely some storage space).
> Dynamic linking (without PIC) gives me 1MB binary.
> Should I compile BusyBox with Position Independent Code for smaller memory
> usage or not?
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. Binary size is also a concern, second to the RAM
footprint concern, but it's a different one. Dynamic linking helps a lot
with binary size if you have several distinct binaries using the same
libraries; this is not the case with Busybox.
* Static/dynamic and PIC/non-PIC are almost independent things. Usually,
_not_ using PIC will yield you smaller binaries. The only code that really
_needs_ to be PIC is code that goes into dynamic libraries. You should not
have to compile busybox as PIC, unless you're using libbb.so, but there's
no real benefit in doing this.
> So, dynamic linking could make more CPU and memory usage or simmilar in
> this case?
Dynamic linking will make you use more CPU at run-time, always, so you
can't expect to gain CPU usage by using dynamic linking. (Most of the
time, though, the difference is negligible.) As for the RAM footprint,
that question can only be seriously answered by profiling, but from what
you said, it doesn't sound like dynamic linking is going to do much
Stick with what works until you have more expertise and feel more
comfortable tweaking your system.
More information about the busybox