aboutsummaryrefslogtreecommitdiff
path: root/docs/busybox.net
diff options
context:
space:
mode:
Diffstat (limited to 'docs/busybox.net')
-rw-r--r--docs/busybox.net/programming.html32
1 files changed, 31 insertions, 1 deletions
diff --git a/docs/busybox.net/programming.html b/docs/busybox.net/programming.html
index 7afa53e27..1214e70f7 100644
--- a/docs/busybox.net/programming.html
+++ b/docs/busybox.net/programming.html
@@ -17,6 +17,7 @@
<li><a href="#tips_encrypted_passwords">Encrypted Passwords</a></li>
<li><a href="#tips_vfork">Fork and vfork</a></li>
<li><a href="#tips_short_read">Short reads and writes</a></li>
+ <li><a href="#tips_memory">Memory used by relocatable code, PIC, and static linking.</a></li>
</ul>
<li><a href="#who">Who are the BusyBox developers?</a></li>
</ul>
@@ -346,6 +347,35 @@ data comes in that can be merged into the same packet. (In case you were
wondering why action games that use TCP/IP set TCP_NODELAY to lower the latency
on their their sockets, now you know.)</p>
+<h2><a name="tips_memory">Memory used by relocatable code, PIC, and static linking.</a></h2>
+
+<p>The downside of standard dynamic linking is that it results in self-modifying
+code. Although each executable's pages are mmaped() into a process's address
+space from the executable file and are thus naturally shared between processes
+out of the page cache, the library loader (ld-linux.so.2 or ld-uClibc.so.0)
+writes to these pages to supply addresses for relocatable symbols. This
+dirties the pages, triggering copy-on-write allocation of new memory for each
+processes's dirtied pages.</p>
+
+<p>One solution to this is Position Independent Code (PIC), a way of linking
+a file so all the relocations are grouped together. This dirties fewer
+pages (often just a single page) for each process's relocations. The down
+side is this results in larger executables, which take up more space on disk
+(and a correspondingly larger space in memory). But when many copies of the
+same program are running, PIC dynamic linking trades a larger disk footprint
+for a smaller memory footprint, by sharing more pages.</p>
+
+<p>A third solution is static linking. A statically linked program has no
+relocations, and thus the entire executable is shared between all running
+instances. This tends to have a significantly larger disk footprint, but
+on a system with only one or two executables, shared libraries aren't much
+of a win anyway.</p>
+
+<p>You can tell the glibc linker to display debugging information about its
+relocations with the environment variable "LD_DEBUG". Try
+"LD_DEBUG=help /bin/true" for a list of commands. Learning to interperet
+"LD_DEBUG=statistics cat /proc/self/statm" could be interesting.</p>
+
<h2><a name="who">Who are the BusyBox developers?</a></h2>
<p>The following login accounts currently exist on busybox.net. (I.E. these
@@ -375,7 +405,6 @@ solar :Ned Ludd
timr :Tim Riker
tobiasa :Tobias Anderberg
vapier :Mike Frysinger
-vodz :Vladimir N. Oleynik
</pre>
<p>The following accounts used to exist on busybox.net, but don't anymore so
@@ -395,6 +424,7 @@ miles
proski
rjune
tausq
+vodz :Vladimir N. Oleynik
</pre>