update docs

author: Denis Vlasenko <vda.linux@googlemail.com> 2007-03-20 11:08:39 +0000
committer: Denis Vlasenko <vda.linux@googlemail.com> 2007-03-20 11:08:39 +0000
commit: e84aeb5bcb1a8398fce53aad9c0072ad73a8b5c9 (patch)
tree: 7681cc079c04adbd75e40183f3b65059413634a9 /docs
parent: 88a2aa98e06cf6b0aa00a3cf88376a1d3497fb2c (diff)
download: busybox-w32-e84aeb5bcb1a8398fce53aad9c0072ad73a8b5c9.tar.gz
busybox-w32-e84aeb5bcb1a8398fce53aad9c0072ad73a8b5c9.tar.bz2
busybox-w32-e84aeb5bcb1a8398fce53aad9c0072ad73a8b5c9.zip
1 files changed, 51 insertions, 31 deletions
diff --git a/docs/keep_data_small.txt b/docs/keep_data_small.txt
index fcd8df4a9..72de2d1ef 100644
--- a/docs/keep_data_small.txt
+++ b/docs/keep_data_small.txt
@@ -2,44 +2,48 @@
 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
+if static busybox is built. When busybox 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
+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?
-In order to keep bbox NOMMU and small-mem systems friendly
+In order to keep busybox NOMMU and small-mem systems friendly
 we should avoid large global data in our applets, and should
 minimize usage of libc functions which implicitly use
-such structures in libc.
+such structures.
-Small experiment measures "parasitic" bbox memory consumption.
+Small experiment to measure "parasitic" bbox memory consumption:
-Here we start 1000 "busybox sleep 10" in parallel.
+here we start 1000 "busybox sleep 10" in parallel.
-bbox binary is practically allyesconfig static one,
+busybox binary is practically allyesconfig static one,
-built against uclibc:
+built against uclibc. Run on x86-64 machine with 64-bit kernel:
-bash-3.2# nmeter '%t %c %b %m %p %[pn]'
+bash-3.2# nmeter '%t %c %m %p %[pn]'
-23:17:28 ..........    0    0 168M    0  147
+23:17:28 .......... 168M    0  147
-23:17:29 ..........    0    0 168M    0  147
+23:17:29 .......... 168M    0  147
-23:17:30 U.........    0    0 168M    1  147
+23:17:30 U......... 168M    1  147
-23:17:31 SU........    0 188k 181M  244  391
+23:17:31 SU........ 181M  244  391
-23:17:32 SSSSUUU...    0    0 223M  757 1147
+23:17:32 SSSSUUU... 223M  757 1147
-23:17:33 UUU.......    0    0 223M    0 1147
+23:17:33 UUU....... 223M    0 1147
-23:17:34 U.........    0    0 223M    1 1147
+23:17:34 U......... 223M    1 1147
-23:17:35 ..........    0    0 223M    0 1147
+23:17:35 .......... 223M    0 1147
-23:17:36 ..........    0    0 223M    0 1147
+23:17:36 .......... 223M    0 1147
-23:17:37 S.........    0    0 223M    0 1147
+23:17:37 S......... 223M    0 1147
-23:17:38 ..........    0    0 223M    1 1147
+23:17:38 .......... 223M    1 1147
-23:17:39 ..........    0    0 223M    0 1147
+23:17:39 .......... 223M    0 1147
-23:17:40 ..........    0    0 223M    0 1147
+23:17:40 .......... 223M    0 1147
-23:17:41 ..........    0    0 210M    0  906
+23:17:41 .......... 210M    0  906
-23:17:42 ..........    0    0 168M    1  147
+23:17:42 .......... 168M    1  147
-23:17:43 ..........    0    0 168M    0  147
+23:17:43 .......... 168M    0  147
 This requires 55M of memory. Thus 1 trivial busybox applet
-takes 55k of memory.
+takes 55k of memory on 64-bit x86 kernel.
+On 32-bit kernel we need ~26k per applet.
+(Data from NOMMU arches are sought. Provide 'size busybox' output too)
                Example 1
@@ -104,8 +108,12 @@ its needs. Library functions are prohibited from using it.
 #define G (*(struct globals*)&bb_common_bufsiz1)
-Be careful, though, and use it only if
+Be careful, though, and use it only if globals fit into bb_common_bufsiz1.
-sizeof(struct globals) <= sizeof(bb_common_bufsiz1).
+Since bb_common_bufsiz1 is BUFSIZ + 1 bytes long and BUFSIZ can change
+from one libc to another, you have to add compile-time check for it:
+if(sizeof(struct globals) > sizeof(bb_common_bufsiz1))
+        BUG_<applet>_globals_too_big();
                Drawbacks
@@ -135,7 +143,7 @@ static int tabstop;
 static struct termios term_orig __attribute__ ((aligned (4)));
 static struct termios term_vi __attribute__ ((aligned (4)));
-reduced bss size by 32 bytes, because gcc sometimes aligns structures to
+reduces bss size by 32 bytes, because gcc sometimes aligns structures to
 ridiculously large values. asm output diff for above example:
 tabstop:
@@ -154,3 +162,15 @@ ridiculously large values. asm output diff for above example:
        .size   term_vi, 60
 gcc doesn't seem to have options for altering this behaviour.
+gcc 3.4.3:
+// gcc aligns to 32 bytes if sizeof(struct) >= 32
+struct st {
+    int c_iflag,c_oflag,c_cflag,c_lflag;
+    int i1,i2,i3;    // struct will be aligned to 4 bytes
+//  int i1,i2,i3,i4; // struct will be aligned to 32 bytes
+};
+struct st t = { 1 };
+// same for arrays
+char vc31[31] = { 1 }; // unaligned
+char vc32[32] = { 1 }; // aligned to 32 bytes
author	Denis Vlasenko <vda.linux@googlemail.com>	2007-03-20 11:08:39 +0000
committer	Denis Vlasenko <vda.linux@googlemail.com>	2007-03-20 11:08:39 +0000
commit	e84aeb5bcb1a8398fce53aad9c0072ad73a8b5c9 (patch)
tree	7681cc079c04adbd75e40183f3b65059413634a9 /docs
parent	88a2aa98e06cf6b0aa00a3cf88376a1d3497fb2c (diff)
download	busybox-w32-e84aeb5bcb1a8398fce53aad9c0072ad73a8b5c9.tar.gz busybox-w32-e84aeb5bcb1a8398fce53aad9c0072ad73a8b5c9.tar.bz2 busybox-w32-e84aeb5bcb1a8398fce53aad9c0072ad73a8b5c9.zip

diff --git a/docs/keep_data_small.txt b/docs/keep_data_small.txt index fcd8df4a9..72de2d1ef 100644 --- a/docs/keep_data_small.txt +++ b/docs/keep_data_small.txt
@@ -2,44 +2,48 @@
2		2
3	When many applets are compiled into busybox, all rw data and	3	When many applets are compiled into busybox, all rw data and
4	bss for each applet are concatenated. Including those from libc,	4	bss for each applet are concatenated. Including those from libc,
5	if static bbox is built. When bbox is started, _all_ this data	5	if static busybox is built. When busybox is started, _all_ this data
6	is allocated, not just that one part for selected applet.	6	is allocated, not just that one part for selected applet.
7		7
8	What "allocated" exactly means, depends on arch.	8	What "allocated" exactly means, depends on arch.
9	On nommu it's probably bites the most, actually using real	9	On NOMMU it's probably bites the most, actually using real
10	RAM for rwdata and bss. On i386, bss is lazily allocated	10	RAM for rwdata and bss. On i386, bss is lazily allocated
11	by COWed zero pages. Not sure about rwdata - also COW?	11	by COWed zero pages. Not sure about rwdata - also COW?
12		12
13	In order to keep bbox NOMMU and small-mem systems friendly	13	In order to keep busybox NOMMU and small-mem systems friendly
14	we should avoid large global data in our applets, and should	14	we should avoid large global data in our applets, and should
15	minimize usage of libc functions which implicitly use	15	minimize usage of libc functions which implicitly use
16	such structures in libc.	16	such structures.
17		17
18	Small experiment measures "parasitic" bbox memory consumption.	18	Small experiment to measure "parasitic" bbox memory consumption:
19	Here we start 1000 "busybox sleep 10" in parallel.	19	here we start 1000 "busybox sleep 10" in parallel.
20	bbox binary is practically allyesconfig static one,	20	busybox binary is practically allyesconfig static one,
21	built against uclibc:	21	built against uclibc. Run on x86-64 machine with 64-bit kernel:
22		22
23	bash-3.2# nmeter '%t %c %b %m %p %[pn]'	23	bash-3.2# nmeter '%t %c %m %p %[pn]'
24	23:17:28 .......... 0 0 168M 0 147	24	23:17:28 .......... 168M 0 147
25	23:17:29 .......... 0 0 168M 0 147	25	23:17:29 .......... 168M 0 147
26	23:17:30 U......... 0 0 168M 1 147	26	23:17:30 U......... 168M 1 147
27	23:17:31 SU........ 0 188k 181M 244 391	27	23:17:31 SU........ 181M 244 391
28	23:17:32 SSSSUUU... 0 0 223M 757 1147	28	23:17:32 SSSSUUU... 223M 757 1147
29	23:17:33 UUU....... 0 0 223M 0 1147	29	23:17:33 UUU....... 223M 0 1147
30	23:17:34 U......... 0 0 223M 1 1147	30	23:17:34 U......... 223M 1 1147
31	23:17:35 .......... 0 0 223M 0 1147	31	23:17:35 .......... 223M 0 1147
32	23:17:36 .......... 0 0 223M 0 1147	32	23:17:36 .......... 223M 0 1147
33	23:17:37 S......... 0 0 223M 0 1147	33	23:17:37 S......... 223M 0 1147
34	23:17:38 .......... 0 0 223M 1 1147	34	23:17:38 .......... 223M 1 1147
35	23:17:39 .......... 0 0 223M 0 1147	35	23:17:39 .......... 223M 0 1147
36	23:17:40 .......... 0 0 223M 0 1147	36	23:17:40 .......... 223M 0 1147
37	23:17:41 .......... 0 0 210M 0 906	37	23:17:41 .......... 210M 0 906
38	23:17:42 .......... 0 0 168M 1 147	38	23:17:42 .......... 168M 1 147
39	23:17:43 .......... 0 0 168M 0 147	39	23:17:43 .......... 168M 0 147
40		40
41	This requires 55M of memory. Thus 1 trivial busybox applet	41	This requires 55M of memory. Thus 1 trivial busybox applet
42	takes 55k of memory.	42	takes 55k of memory on 64-bit x86 kernel.
		43
		44	On 32-bit kernel we need ~26k per applet.
		45
		46	(Data from NOMMU arches are sought. Provide 'size busybox' output too)
43		47
44		48
45	Example 1	49	Example 1
@@ -104,8 +108,12 @@ its needs. Library functions are prohibited from using it.
104		108
105	#define G ((struct globals)&bb_common_bufsiz1)	109	#define G ((struct globals)&bb_common_bufsiz1)
106		110
107	Be careful, though, and use it only if	111	Be careful, though, and use it only if globals fit into bb_common_bufsiz1.
108	sizeof(struct globals) <= sizeof(bb_common_bufsiz1).	112	Since bb_common_bufsiz1 is BUFSIZ + 1 bytes long and BUFSIZ can change
		113	from one libc to another, you have to add compile-time check for it:
		114
		115	if(sizeof(struct globals) > sizeof(bb_common_bufsiz1))
		116	BUG_<applet>_globals_too_big();
109		117
110		118
111	Drawbacks	119	Drawbacks
@@ -135,7 +143,7 @@ static int tabstop;
135	static struct termios term_orig __attribute__ ((aligned (4)));	143	static struct termios term_orig __attribute__ ((aligned (4)));
136	static struct termios term_vi __attribute__ ((aligned (4)));	144	static struct termios term_vi __attribute__ ((aligned (4)));
137		145
138	reduced bss size by 32 bytes, because gcc sometimes aligns structures to	146	reduces bss size by 32 bytes, because gcc sometimes aligns structures to
139	ridiculously large values. asm output diff for above example:	147	ridiculously large values. asm output diff for above example:
140		148
141	tabstop:	149	tabstop:
@@ -154,3 +162,15 @@ ridiculously large values. asm output diff for above example:
154	.size term_vi, 60	162	.size term_vi, 60
155		163
156	gcc doesn't seem to have options for altering this behaviour.	164	gcc doesn't seem to have options for altering this behaviour.
		165
		166	gcc 3.4.3:
		167	// gcc aligns to 32 bytes if sizeof(struct) >= 32
		168	struct st {
		169	int c_iflag,c_oflag,c_cflag,c_lflag;
		170	int i1,i2,i3; // struct will be aligned to 4 bytes
		171	// int i1,i2,i3,i4; // struct will be aligned to 32 bytes
		172	};
		173	struct st t = { 1 };
		174	// same for arrays
		175	char vc31[31] = { 1 }; // unaligned
		176	char vc32[32] = { 1 }; // aligned to 32 bytes