Hi, Frederic, Back in 2.4 time there seems to be a different kernel memory allocator which does not use buddy system. That one probably gives less fragmentation. I have been thinking of porting that to 2.6. Maybe you can try.
Or perhaps someone else already has tried and has the patch? In any case we also noticed that busybox does a lot of malloc's which worsen the memory fragmentation. We have got XIP working, but that does not help on the heavy malloc and heavy fragmentation issue much. Cheers. Jun On Thu, Oct 09, 2008 at 12:41:31PM +0200, Frédéric DUBOIS wrote: > > Hello, > > I'm in the process of upgrading our 5272-based custom board to > uClinux-20080808, using kernel 2.6. It boots fine, then it loads and launches > our main application from the JFFS2. > Our app under certain conditions may itself run external shell scripts. They > are sometimes quite complex, we use bysybox' msh for this purpose. > When doing this, we face memory allocation failures. Either when the app > tries to run msh, or when a utility called by the script executed by msh > tries to allocate some buffer (in which case the whole system crashes because > that utility probably doesn't check the result of malloc I guess). > > the thing that puzzles me is that often the kernel trace for the allocation > failure lets me think that the allocation shouldn't have failed: > > >mv: page allocation failure. order:7, mode:0x40d0 > >Stack from 00760dcc: > > 00760000 000492ee 001819e5 0030eb56 00000007 000040d0 00000002 > > 00002004 > > 00000010 000040d0 00000010 00000000 002d28a0 002d15e0 002d2890 > > 002a9ae0 > > 000000d0 000240d0 00000000 00760008 00000000 00051d34 000040d0 > > 00000007 > > 001aadb0 00000002 00002004 000040d0 00000000 00000007 0004e187 > > 002a9ae0 > > 00e34540 00f2acc0 00000004 00760ed0 00052056 002a9ae0 000040d0 > > 00000002 > > 00000000 0004d188 00000000 000502fc 0004d188 000040d0 000029d0 > > 00000001 > >Call Trace with CONFIG_FRAME_POINTER disabled: > > > > [000492ee] [001819e5] [000240d0] [00051d34] [0004e187] > > [00052056] [0004d188] [000502fc] [0004d188] [0004d188] > > [0003bd40] [0007b41a] [0004d188] [00057c50] [000579e6] > > [00058f56] [00020806] [00020838] [00020806] [00023180] > > > >Mem-info: > >Normal per-cpu: > >CPU 0: hi: 0, btch: 1 usd: 0 > >Active:5 inactive:374 dirty:2 writeback:0 unstable:0 > > free:565 slab:1850 mapped:0 pagetables:0 bounce:0 > >Normal free:2260kB min:508kB low:632kB high:760kB active:20kB > >inactive:1496kB present:16256kB pages_scanned:0 all_unreclaimable? no > >lowmem_reserve[]: 0 0 0 > >Normal: 59*4kB 49*8kB 32*16kB 11*32kB 4*64kB 0*128kB 0*256kB 1*512kB > >0*1024kB 0*2048kB 0*4096kB = 2260kB > >411 total pagecache pages > >4096 pages of RAM > >565 free pages > >707 reserved pages > >161 pages shared > >0 pages swap cached > >Allocation of Length 315784 from process 365 failed > >Normal per-cpu: > >CPU 0: hi: 0, btch: 1 usd: 0 > >Active:5 inactive:374 dirty:2 writeback:0 unstable:0 > > free:565 slab:1850 mapped:0 pagetables:0 bounce:0 > >Normal free:2260kB min:508kB low:632kB high:760kB active:20kB > >inactive:1496kB present:16256kB pages_scanned:0 all_unreclaimable? no > >lowmem_reserve[]: 0 0 0 > >Normal: 59*4kB 49*8kB 32*16kB 11*32kB 4*64kB 0*128kB 0*256kB 1*512kB > >0*1024kB 0*2048kB 0*4096kB = 2260kB > >411 total pagecache pages > >Unable to allocate RAM for process text/data, errno 12 > >Illegal instruction > > There's a 512Kb block available, where our request of 309Kb should fit. The > "mv" command that failed is part of the busybox, and our busybox is quite > crowded, hence the 309Kb figure. > > I notice that the memory is awfully fragmented. I blame our heavy use of > shell scripts of this. > > > So, I'm seeking for advice on what to do. > > I tried to use the SLUB or SLOB allocator in the hope they would use a > different allocation strategy, but when enabled, the system simply doesn't > boot. I don't even see the version string that is usually display on startup > just after the PPCBoot bootloader decompress the kernel image. > I tried to reduce the workload in scripts, in particular where scripts call > other scripts. I can't go further into this without more heavy work. > I tried to change the buffer allocation policy for busybox. I think that > default "malloc" policy is no good for me. > > Enabling some kind of code sharing (XIP, shared library?) for busybox would > at least free some memory. I read the recent thread here on that topic, but > it isn't clear for me whether it is possible for my arch (coldfire) and from > romfs (or from ramfs - I consider copying it there if it has to work that > way). > > I think I can downsize busybox; I think my big busybox (no porn joke > intended) is part of the problem, but I don't believe I can cut it down below > 256K, because some utilities I need don't exist in standalone version (or > they don't work fine). But my main problem is a fragmentation problem anyway. > > Regards. > > _______________________________________________ > 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 _______________________________________________ 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
