[git commit] use_less_ram.html: expand libc section

[Denys Vlasenko]

commit: https://git.busybox.net/busybox-website/commit/?id=22487d0d743c803cfc8ea353210c9e773e174dcf
branch: https://git.busybox.net/busybox-website/commit/?id=refs/heads/master

Signed-off-by: Denys Vlasenko <vda.linux at googlemail.com>
---
 use_less_ram.html | 58 +++++++++++++++++++++++++++++++++++++++++++++++++++----
 1 file changed, 54 insertions(+), 4 deletions(-)

diff --git a/use_less_ram.html b/use_less_ram.html
index 247c3a4..5231926 100644
--- a/use_less_ram.html
+++ b/use_less_ram.html
@@ -73,12 +73,62 @@ It is possible to have a Busybox binary with almost all applets and only
 
 <h4>Using libc which is better at using RAM sparingly</h4>
 <p>
-[TODO:] Static builds are better than dynamic ones. Glibc is horrible for static builds,
-though. Ideally, libs should not initialize "[heap]" before user program calls malloc().
-Libc should aggressively prune (return to OS) freed malloc space (glibc defaults are bad).
+Static builds use RAM significantly more economically than dynamic ones.
+Here is a comparison of uclibc-based builds, the only difference
+between them is CONFIG_STATIC=y:
+</p><p>
+<pre>$ busybox pmap $$'
+08048000     792K r-xp  /bin/busybox
+0810e000       4K rw-p  /bin/busybox
+0810f000       8K rw-p  [heap]
+f7f9e000     260K r-xp  /lib/libuClibc-0.9.30.3.so
+f7fdf000       4K r--p  /lib/libuClibc-0.9.30.3.so
+f7fe0000       4K rw-p  /lib/libuClibc-0.9.30.3.so
+f7fe1000      16K rw-p    [ anon ]
+f7fe5000      44K r-xp  /lib/libm-0.9.30.3.so
+f7ff0000       4K r--p  /lib/libm-0.9.30.3.so
+f7ff1000       4K rw-p  /lib/libm-0.9.30.3.so
+f7ff3000       4K rw-p    [ anon ]
+f7ff8000      16K r-xp  /lib/ld-uClibc-0.9.30.3.so
+f7ffc000       4K r--p  /lib/ld-uClibc-0.9.30.3.so
+f7ffd000       4K rw-p  /lib/ld-uClibc-0.9.30.3.so
+fffdd000     132K rw-p  [stack]
+mapped: 1316K
+$ busybox.static pmap $$
+08048000     900K r-xp  /home/srcdevel/bbox/fix/busybox.t4/busybox.static
+08129000       4K rw-p  /home/srcdevel/bbox/fix/busybox.t4/busybox.static
+0812a000      20K rw-p  [heap]
+fffdd000     132K rw-p  [stack]
+mapped: 1072K</pre>
+</p><p>
+Static build has only 24K mapped RW (excluding stack). Dynamic build has
+4K+8K+4K+16K+4K+4K+4K = 44K, almost twice as much.
+</p><p>
+Dynamic builds have benefits that they allow different binaries to reuse library's
+text, but in the case of Busybox, you <b>already</b> reuse text - because all
+running applets are the same binary.
+</p><p>
+Does it mean "always build static"? Unfortunately, not. Glibc is horrible
+for static builds, their developers declared that static builds will be supported,
+but will not be optimized for. As a result, binaries statically built against
+glibc are some 400K larger than dynamic ones - and they still may need some
+libraries for e.g. DNS name resolution to work. [TODO: how much data + bss glibc adds?]
+</p><p>
+As you see above, uclibc is much better in this regard. Static build has only
+~100K larger text section. Musl also shows promise, although I did not switch
+to it yet.
+</p><p>
+Things to look for when you evaluate some libc for static building:
+it should have modest data and bss.
+Ideally, libs should not initialize "[heap]" before
+user program calls malloc(). Libc should be able to aggressively prune (return to OS)
+freed malloc space (glibc defaults are bad).
 Even though we don't need that in Busybox, there should be a method to prune
-used (dirtied) stack space after the use of deep recursion or large on-stack objects.
+used (dirtied) stack space after the use of deep recursion or large on-stack
+objects.
 </p><p>
+If you build your libc yourself, look into ways to tweak the build to be more
+space-efficient.
 </p>
 
 <h4>Optimizing start of data</h4>