[git commit] use_less_ram: add a section about better libc

[Denys Vlasenko]

commit: https://git.busybox.net/busybox-website/commit/?id=90b81f014ab6462512f0027393030916fe8f08d6
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 | 18 ++++++++++++++++--
 1 file changed, 16 insertions(+), 2 deletions(-)

diff --git a/use_less_ram.html b/use_less_ram.html
index a4d9428..5dfe04f 100644
--- a/use_less_ram.html
+++ b/use_less_ram.html
@@ -8,7 +8,7 @@ written in C. Compiler and linker are usually not written with a focus
 to strongly minimize memory usage. This can be helped, though.
 </p>
 
-<h4>Overview of RAM usage in Linux</h4>
+<h4>Overview of RAM usage by Linux binaries</h4>
 <p>
 Executables have the following parts:
 read-only executable code and constants, also known as "text",
@@ -63,7 +63,12 @@ ff82a000     132K rw-p  [stack]       - stack</pre>
 It is important to minimize the number of RW pages your program touches.
 Data, bss and stack pages are never freed, therefore for large,
 and especially for temporary allocations, it's best to use malloc()
-or mmap().
+or mmap(). One way to use fewer RW pages is to _have_ fewer RW pages
+in your binary. There are several scenarios when a binary may end up having
+more data+bss pages than necessary.
+</p><p>
+It is possible to have a Busybox binary with almost all apllets and only
+8 kilobytes of data+bss.
 </p>
 <h4>Optimizing start of data</h4>
 <p>
@@ -124,6 +129,15 @@ to add ALIGNn on them. You can run "grep -F -B3 '*fill*' busybox_unstripped.map"
 to find all linker-added padding in your binary, and add forgotten ALIGNn's.
 Please send a patch if you do.
 <p>
+<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).
+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.
+</p><p>
+</p>
 <h4>Converting bss to data</h4>
 <p>
 Busybox's data and bss sections are small already, some 4-12 kilobytes.