From 75605788ff6be5a766a7e41da583d5e8f47d9ac4 Mon Sep 17 00:00:00 2001 From: Denis Vlasenko Date: Wed, 14 Mar 2007 00:07:51 +0000 Subject: gzip: use common bbunzip infrastructure - ~700 bytes code less --- docs/keep_data_small.txt | 88 ++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 88 insertions(+) create mode 100644 docs/keep_data_small.txt (limited to 'docs/keep_data_small.txt') diff --git a/docs/keep_data_small.txt b/docs/keep_data_small.txt new file mode 100644 index 000000000..88cc2bc66 --- /dev/null +++ b/docs/keep_data_small.txt @@ -0,0 +1,88 @@ + Keeping data small + +When many applets are compiled into busybox, all rw data and +bss for each applet are concatenated. Including those from libc, +if static bbox is built. When bbox is started, _all_ this data +is allocated, not just that one part for selected applet. + +What "allocated" exactly means, depends on arch. +On nommu it's probably bites the most, actually using real +RAM for rwdata and bss. On i386, bss is lazily allocated +by COWed zero pages. Not sure about rwdata - also COW? + +Small experiment measures "parasitic" bbox memory consumption. +Here we start 1000 "busybox sleep 10" in parallel. +bbox binary is practically allyesconfig static one, +built against uclibc: + +bash-3.2# nmeter '%t %c %b %m %p %[pn]' +23:17:28 .......... 0 0 168M 0 147 +23:17:29 .......... 0 0 168M 0 147 +23:17:30 U......... 0 0 168M 1 147 +23:17:31 SU........ 0 188k 181M 244 391 +23:17:32 SSSSUUU... 0 0 223M 757 1147 +23:17:33 UUU....... 0 0 223M 0 1147 +23:17:34 U......... 0 0 223M 1 1147 +23:17:35 .......... 0 0 223M 0 1147 +23:17:36 .......... 0 0 223M 0 1147 +23:17:37 S......... 0 0 223M 0 1147 +23:17:38 .......... 0 0 223M 1 1147 +23:17:39 .......... 0 0 223M 0 1147 +23:17:40 .......... 0 0 223M 0 1147 +23:17:41 .......... 0 0 210M 0 906 +23:17:42 .......... 0 0 168M 1 147 +23:17:43 .......... 0 0 168M 0 147 + +This requires 55M of memory. Thus 1 trivial busybox applet +takes 55k of userspace memory (nmeter doesn't account for kernel-side +allocations). Definitely can be improved. + +Thus we should avoid large global data in our applets, +and should minimize usage of libc functions which implicitly use +such structures in libc. + + Example 1 + +One example how to reduce global data usage is in +archival/libunarchive/decompress_unzip.c: + +/* This is somewhat complex-looking arrangement, but it allows + * to place decompressor state either in bss or in + * malloc'ed space simply by changing #defines below. + * Sizes on i386: + * text data bss dec hex + * 5256 0 108 5364 14f4 - bss + * 4915 0 0 4915 1333 - malloc + */ +#define STATE_IN_BSS 0 +#define STATE_IN_MALLOC 1 + +This example completely eliminates globals in that module. +Required memory is allocated in inflate_gunzip() [its main module] +and then passed down to all subroutines which need to access globals +as a parameter. + + Example 2 + +In case you don't want to pass this additional parameter everywhere, +take a look at archival/gzip.c. Here all global data is replaced by +singe global pointer (ptr_to_globals) to allocated storage. + +In order to not duplicate ptr_to_globals in every applet, you can +reuse single common one. It is defined in libbb/messages.c +as void *ptr_to_globals, but is NOT declared in libbb.h. +You first define a struct: + +struct my_globals { int a; char buf[1000]; }; + +and then declare that ptr_to_globals is a pointer to it: + +extern struct my_globals *ptr_to_globals; +#define G (*ptr_to_globals) + +Linker magic enures that these two merge into single pointer object. +Now initialize it in _main(): + + ptr_to_globals = xzalloc(sizeof(G)); + +and you can reference "globals" by G.a, G.buf and so on, in any function. -- cgit v1.2.3