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
