mkfs_minix: stop using lots of bss/data.

data -3500 bytes, code -300 bytes keep_data_small: expand/fix git-svn-id: svn://busybox.net/trunk/busybox@18123 69ca8d6d-28ef-0310-b511-8ec308f3f277
author: vda <vda@69ca8d6d-28ef-0310-b511-8ec308f3f277> 2007-03-15 19:52:42 +0000
committer: vda <vda@69ca8d6d-28ef-0310-b511-8ec308f3f277> 2007-03-15 19:52:42 +0000
commit: 53a0cadbe1f0a2bde37ca86e1185d286424181f0 (patch)
tree: 306d8ad4c9a20e971356afc3b3a76abc15263458 /docs
parent: ca274d1bbe798fbf3950c31e92c9f33d29cef48c (diff)
download: busybox-w32-53a0cadbe1f0a2bde37ca86e1185d286424181f0.tar.gz
busybox-w32-53a0cadbe1f0a2bde37ca86e1185d286424181f0.tar.bz2
busybox-w32-53a0cadbe1f0a2bde37ca86e1185d286424181f0.zip
1 files changed, 52 insertions, 16 deletions
diff --git a/docs/keep_data_small.txt b/docs/keep_data_small.txt
index ec13b4d3f..5137dffc6 100644
--- a/docs/keep_data_small.txt
+++ b/docs/keep_data_small.txt
@@ -1,4 +1,4 @@
-        Keeping data small
+                Keeping data small
 When many applets are compiled into busybox, all rw data and
 bss for each applet are concatenated. Including those from libc,
@@ -10,6 +10,11 @@ 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
+we should avoid large global data in our applets, and should
+minimize usage of libc functions which implicitly use
+such structures in libc.
 Small experiment measures "parasitic" bbox memory consumption.
 Here we start 1000 "busybox sleep 10" in parallel.
 bbox binary is practically allyesconfig static one,
@@ -34,14 +39,10 @@ bash-3.2# nmeter '%t %c %b %m %p %[pn]'
 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
+takes 55k of memory.
-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
+                Example 1
 One example how to reduce global data usage is in
 archival/libunarchive/decompress_unzip.c:
@@ -57,12 +58,15 @@ archival/libunarchive/decompress_unzip.c:
 #define STATE_IN_BSS 0
 #define STATE_IN_MALLOC 1
+(see the rest of the file to get the idea)
 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
+                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
@@ -70,7 +74,7 @@ single 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 struct globals *ptr_to_globals, but the struct globals is
+as struct globals *const ptr_to_globals, but the struct globals is
 NOT defined in libbb.h. You first define your own struct:
 struct globals { int a; char buf[1000]; };
@@ -79,13 +83,45 @@ and then declare that ptr_to_globals is a pointer to it:
 #define G (*ptr_to_globals)
-Linker magic ensures that these two merge into single pointer object.
+ptr_to_globals is declared as constant pointer.
-Now initialize it in <applet>_main():
+This helps gcc understand that it won't change, resulting in noticeably
+smaller code. In order to assign it, use PTR_TO_GLOBALS macro:
+        PTR_TO_GLOBALS = xzalloc(sizeof(G));
+Typically it is done in <applet>_main().
+Now you can reference "globals" by G.a, G.buf and so on, in any function.
+                bb_common_bufsiz1
+There is one big common buffer in bss - bb_common_bufsiz1. It is a much
+earlier mechanism to reduce bss usage. Each applet can use it for
+its needs. Library functions are prohibited from using it.
+'G.' trick can be done using bb_common_bufsiz1 instead of malloced buffer:
+#define G (*(struct globals*)&bb_common_bufsiz1)
+Be careful, though, and use it only if
+sizeof(struct globals) <= sizeof(bb_common_bufsiz1).
+                Drawbacks
+You have to initialize it by hand. xzalloc() can be helpful in clearing
+allocated storage to 0, but anything more must be done by hand.
+All global variables are prefixed by 'G.' now. If this makes code
+less readable, use #defines:
+#define dev_fd (G.dev_fd)
+#define sector (G.sector)
-        ptr_to_globals = xzalloc(sizeof(G));
-and you can reference "globals" by G.a, G.buf and so on, in any function.
+                Word of caution
-The drawback is that now you have to initialize it by hand. xzalloc()
+If applet doesn't use much of global data, converting it to using
-can be helpful in clearing allocated storage to 0, but anything more
+one of above methods is not worth resulting code obfuscation.
-must be done by hand.
+If you have less that ~300 bytes of global data - don't bother.
author	vda <vda@69ca8d6d-28ef-0310-b511-8ec308f3f277>	2007-03-15 19:52:42 +0000
committer	vda <vda@69ca8d6d-28ef-0310-b511-8ec308f3f277>	2007-03-15 19:52:42 +0000
commit	53a0cadbe1f0a2bde37ca86e1185d286424181f0 (patch)
tree	306d8ad4c9a20e971356afc3b3a76abc15263458 /docs
parent	ca274d1bbe798fbf3950c31e92c9f33d29cef48c (diff)
download	busybox-w32-53a0cadbe1f0a2bde37ca86e1185d286424181f0.tar.gz busybox-w32-53a0cadbe1f0a2bde37ca86e1185d286424181f0.tar.bz2 busybox-w32-53a0cadbe1f0a2bde37ca86e1185d286424181f0.zip

diff --git a/docs/keep_data_small.txt b/docs/keep_data_small.txt index ec13b4d3f..5137dffc6 100644 --- a/docs/keep_data_small.txt +++ b/docs/keep_data_small.txt
@@ -1,4 +1,4 @@
1	Keeping data small	1	Keeping data small
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,
@@ -10,6 +10,11 @@ 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
		14	we should avoid large global data in our applets, and should
		15	minimize usage of libc functions which implicitly use
		16	such structures in libc.
		17
13	Small experiment measures "parasitic" bbox memory consumption.	18	Small experiment measures "parasitic" bbox memory consumption.
14	Here we start 1000 "busybox sleep 10" in parallel.	19	Here we start 1000 "busybox sleep 10" in parallel.
15	bbox binary is practically allyesconfig static one,	20	bbox binary is practically allyesconfig static one,
@@ -34,14 +39,10 @@ bash-3.2# nmeter '%t %c %b %m %p %[pn]'
34	23:17:43 .......... 0 0 168M 0 147	39	23:17:43 .......... 0 0 168M 0 147
35		40
36	This requires 55M of memory. Thus 1 trivial busybox applet	41	This requires 55M of memory. Thus 1 trivial busybox applet
37	takes 55k of userspace memory (nmeter doesn't account for kernel-side	42	takes 55k of memory.
38	allocations). Definitely can be improved.
39		43
40	Thus we should avoid large global data in our applets,
41	and should minimize usage of libc functions which implicitly use
42	such structures in libc.
43		44
44	Example 1	45	Example 1
45		46
46	One example how to reduce global data usage is in	47	One example how to reduce global data usage is in
47	archival/libunarchive/decompress_unzip.c:	48	archival/libunarchive/decompress_unzip.c:
@@ -57,12 +58,15 @@ archival/libunarchive/decompress_unzip.c:
57	#define STATE_IN_BSS 0	58	#define STATE_IN_BSS 0
58	#define STATE_IN_MALLOC 1	59	#define STATE_IN_MALLOC 1
59		60
		61	(see the rest of the file to get the idea)
		62
60	This example completely eliminates globals in that module.	63	This example completely eliminates globals in that module.
61	Required memory is allocated in inflate_gunzip() [its main module]	64	Required memory is allocated in inflate_gunzip() [its main module]
62	and then passed down to all subroutines which need to access 'globals'	65	and then passed down to all subroutines which need to access 'globals'
63	as a parameter.	66	as a parameter.
64		67
65	Example 2	68
		69	Example 2
66		70
67	In case you don't want to pass this additional parameter everywhere,	71	In case you don't want to pass this additional parameter everywhere,
68	take a look at archival/gzip.c. Here all global data is replaced by	72	take a look at archival/gzip.c. Here all global data is replaced by
@@ -70,7 +74,7 @@ single global pointer (ptr_to_globals) to allocated storage.
70		74
71	In order to not duplicate ptr_to_globals in every applet, you can	75	In order to not duplicate ptr_to_globals in every applet, you can
72	reuse single common one. It is defined in libbb/messages.c	76	reuse single common one. It is defined in libbb/messages.c
73	as struct globals *ptr_to_globals, but the struct globals is	77	as struct globals *const ptr_to_globals, but the struct globals is
74	NOT defined in libbb.h. You first define your own struct:	78	NOT defined in libbb.h. You first define your own struct:
75		79
76	struct globals { int a; char buf[1000]; };	80	struct globals { int a; char buf[1000]; };
@@ -79,13 +83,45 @@ and then declare that ptr_to_globals is a pointer to it:
79		83
80	#define G (*ptr_to_globals)	84	#define G (*ptr_to_globals)
81		85
82	Linker magic ensures that these two merge into single pointer object.	86	ptr_to_globals is declared as constant pointer.
83	Now initialize it in <applet>_main():	87	This helps gcc understand that it won't change, resulting in noticeably
		88	smaller code. In order to assign it, use PTR_TO_GLOBALS macro:
		89
		90	PTR_TO_GLOBALS = xzalloc(sizeof(G));
		91
		92	Typically it is done in <applet>_main().
		93
		94	Now you can reference "globals" by G.a, G.buf and so on, in any function.
		95
		96
		97	bb_common_bufsiz1
		98
		99	There is one big common buffer in bss - bb_common_bufsiz1. It is a much
		100	earlier mechanism to reduce bss usage. Each applet can use it for
		101	its needs. Library functions are prohibited from using it.
		102
		103	'G.' trick can be done using bb_common_bufsiz1 instead of malloced buffer:
		104
		105	#define G ((struct globals)&bb_common_bufsiz1)
		106
		107	Be careful, though, and use it only if
		108	sizeof(struct globals) <= sizeof(bb_common_bufsiz1).
		109
		110
		111	Drawbacks
		112
		113	You have to initialize it by hand. xzalloc() can be helpful in clearing
		114	allocated storage to 0, but anything more must be done by hand.
		115
		116	All global variables are prefixed by 'G.' now. If this makes code
		117	less readable, use #defines:
		118
		119	#define dev_fd (G.dev_fd)
		120	#define sector (G.sector)
84		121
85	ptr_to_globals = xzalloc(sizeof(G));
86		122
87	and you can reference "globals" by G.a, G.buf and so on, in any function.	123	Word of caution
88		124
89	The drawback is that now you have to initialize it by hand. xzalloc()	125	If applet doesn't use much of global data, converting it to using
90	can be helpful in clearing allocated storage to 0, but anything more	126	one of above methods is not worth resulting code obfuscation.
91	must be done by hand.	127	If you have less that ~300 bytes of global data - don't bother.