Lennart Sorensen wrote: > On Wed, Apr 21, 2010 at 04:57:40PM +0100, Jamie Lokier wrote: > > You don't have to have just one busybox binary containing everything. > > > > On my 32MB ARM7-ish system, I have init, telnetd and udhdpc each in > > separate one-program busybox executables, compiled non-XIP. > > > > Those are individual because they are each long-running programs. > > They are not XIP because there is only one instance, so XIP overhead > > isn't justified. > > > > Then I have a busybox containing exactly these: test, true, false and > > msh. Those are compiled XIP because there are many instances of them > > at once. > > > > Those are the shell, because it is instantiated many times so I want > > it to have as little extra stuff as possible. test, true, false are > > forced on by Busybox when msh is enabled, that's why they are included. > > > > Then I have awk, fdisk and login individually, because those are quite > > large, or in the case of login, a large data segment (due to password > > encryption tables). Those are all non-XIP, because I don't use them > > much. Taking them out of the "big" Busybox makes it quite a lot > > smaller. Reducing data segment size from the big Busybox is more > > valuable than reducing code size. > > > > Then I have all the rest of the enabled Busybox programs in a single > > executable, compiled with XIP so that multiple instances share code. > > > > All of them are linked statically with uClibc. Mainly because shared > > libs are difficult without FD-PIC, but also it probably makes the data > > segment smaller than if there was one large shared uClibc. But on the > > other hand, larger code size and in larger chunks per program, so more > > sensitive to fragmentation. Pros and cons. > > > > The above was done because, despite having 32MB to play with, and > > about 10MB free most of the time, when I had one big Busybox and > > non-XIP, the system could easily get into a state where allocating > > 256kB to launch telnetd or a shell from telnetd wasn't possible, so > > even remote logging in and rebooting my device wasn't possible. > > Wow, and I am running a single busybox with lots of things in it on an > 8MB coldfire. You application is clearly a lot larger than mine.
Probably right :-) Fragmentation is a big problem on mine because it's doing a lot of streaming from disk - it's a video player, and it's also doing a lot of networky things and running various third party scripts every few seconds. Those exercise parts of the kernel which aren't used so much by the no-mmu crowd, and the mmu crowd tend to have much larger memory, and are far less sensitive to fragmentation. Those activities churn the memory somewhat (although I've been finding ways to reduce that), which accelerates fragmentation. It can still take 8 hours before shells stop being able to spawn, using the standard kernel allocator. (With a patched allocator, and the busybox + XIP tricks to reduce memory used, it seems to be sufficiently resistant for my applications.) So you can imagine that a less active system can take days before fragmentation really shows. That is confirmed by another system I've worked on: A router which runs some modular applications, which is fine most of the time, but after 2 weeks of uptime, the fragmentation becomes too much and applications can't spawn. Fragmentation is both tricky and _slow_ to increase to its limit sometimes. > I don't think I have login enabled (no need), and certainly not telnetd. > Perhaps that saves some space. Wasting space on libbb and ulibc for > seperate copies for true, false, and such would take too much ramdisk > space and the overhead for that is just too much. I don't store them in ramdisk, so perhaps that makes a difference. They're stored compressed, using "flthdr -z" for the compressed bFLT format. -- Jamie _______________________________________________ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
