arm linux系统加载大尺寸内核模块内存问题，求解！

mingzm123

请教各位
最近碰到一个问题，我使用mini2440(64m内存)开发板，使用uboot引导linux-2.6.32.2启动，rootfs使用内核中的ramfs加载。
启动完毕后，加载一个约17m左右的ko文件，我所使用的ko文件功能相当简单，主要是加载完成后打印“hello world”，但是我加
入了一个巨大的数组，目的是增大ko文件体积，如下：

int arr[] = {
1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,
...............................
...............................
1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1
};

当加载该模块时，内核打印错误如下：

[root@wws /1]# insmod mini2440_hello_module-17m.ko
insmod invoked oom-killer: gfp_mask=0xd2, order=0, oom_adj=0
Backtrace:
[<c03c4020>] (dump_backtrace+0x0/0x110) from [<c03c44ac>] (dump_stack+0x18/0x1c)
r6:00000000 r5:000000d2 r4:c3d28000
[<c03c4494>] (dump_stack+0x0/0x1c) from [<c0409f48>] (oom_kill_process+0x5c/0x1d
[<c0409eec>] (oom_kill_process+0x0/0x1d from [<c040a43c>] (__out_of_memory+0x9c/0xbc)
[<c040a3a0>] (__out_of_memory+0x0/0xbc) from [<c040a4cc>] (out_of_memory+0x70/0xa0)
r7:00000040 r6:00000000 r5:00000000 r4:000000d2
[<c040a45c>] (out_of_memory+0x0/0xa0) from [<c040ce98>] (__alloc_pages_nodemask+0x454/0x54c)
r5:000000d2 r4:00000000
[<c040ca44>] (__alloc_pages_nodemask+0x0/0x54c) from [<c0425634>] (__vmalloc_area_node+0xd0/0x130)
[<c0425564>] (__vmalloc_area_node+0x0/0x130) from [<c0425724>] (__vmalloc_node+0x90/0xa
[<c0425694>] (__vmalloc_node+0x0/0xa from [<c04258c4>] (vmalloc+0x2c/0x3
r7:40000008 r6:00000000 r5:011a67e1 r4:40000008
[<c0425898>] (vmalloc+0x0/0x3 from [<c03fb8ac>] (load_module+0x34/0x147
[<c03fb878>] (load_module+0x0/0x147 from [<c03fcd50>] (sys_init_module+0x60/0x1f
[<c03fccf0>] (sys_init_module+0x0/0x1f from [<c03bfe80>] (ret_fast_syscall+0x0/0x28)
r7:00000080 r6:bed16f57 r5:000da078 r4:011a67e1
Mem-info:
Normal per-cpu:
CPU    0: hi:   18, btch:   3 usd:  17
active_anon:2580 inactive_anon:1970 isolated_anon:0
active_file:0 inactive_file:0 isolated_file:0
unevictable:2490 dirty:0 writeback:0 unstable:0
free:252 slab_reclaimable:108 slab_unreclaimable:856
mapped:122 shmem:0 pagetables:16 bounce:0
Normal free:1008kB min:1016kB low:1268kB high:1524kB active_anon:10320kB inactive_anon:7880kB active_file:0kB inactive_file:0kB unevictable:9960kB isolated(anon):0kB isolated(file):0kB present:65024kB mlocked:0kB dirty:0kB writeback:0kB mapped:488kB shmem:0kB slab_reclaimable:432kB slab_unreclaimable:3424kB kernel_stack:192kB pagetables:64kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 0
Normal: 252*4kB 0*8kB 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 1008kB
2490 total pagecache pages
0 pages in swap cache
Swap cache stats: add 0, delete 0, find 0/0
Free swap  = 0kB
Total swap = 0kB
16384 pages of RAM
302 free pages
5463 reserved pages
859 slab pages
233 pages shared
0 pages swap cached
Out of memory: kill process 728 (insmod) score 314 or a child
Killed process 728 (insmod)
insmod: page allocation failure. order:0, mode:0xd2
Backtrace:
[<c03c4020>] (dump_backtrace+0x0/0x110) from [<c03c44ac>] (dump_stack+0x18/0x1c)
r6:00000000 r5:000000d2 r4:c178f6f0
[<c03c4494>] (dump_stack+0x0/0x1c) from [<c040cf38>] (__alloc_pages_nodemask+0x4f4/0x54c)
[<c040ca44>] (__alloc_pages_nodemask+0x0/0x54c) from [<c0425634>] (__vmalloc_area_node+0xd0/0x130)
[<c0425564>] (__vmalloc_area_node+0x0/0x130) from [<c0425724>] (__vmalloc_node+0x90/0xa8)
[<c0425694>] (__vmalloc_node+0x0/0xa8) from [<c04258c4>] (vmalloc+0x2c/0x38)
r7:40000008 r6:00000000 r5:011a67e1 r4:40000008
[<c0425898>] (vmalloc+0x0/0x38) from [<c03fb8ac>] (load_module+0x34/0x1478)
[<c03fb878>] (load_module+0x0/0x1478) from [<c03fcd50>] (sys_init_module+0x60/0x1f8)
[<c03fccf0>] (sys_init_module+0x0/0x1f8) from [<c03bfe80>] (ret_fast_syscall+0x0/0x28)
r7:00000080 r6:bed16f57 r5:000da078 r4:011a67e1
Mem-info:
Normal per-cpu:
CPU    0: hi:   18, btch:   3 usd:  15
active_anon:2580 inactive_anon:1970 isolated_anon:0
active_file:0 inactive_file:0 isolated_file:0
unevictable:2490 dirty:0 writeback:0 unstable:0
free:0 slab_reclaimable:108 slab_unreclaimable:856
mapped:122 shmem:0 pagetables:16 bounce:0
Normal free:0kB min:1016kB low:1268kB high:1524kB active_anon:10320kB inactive_anon:7880kB active_file:0kB inactive_file:0kB unevictable:9960kB isolated(anon):0kB isolated(file):0kB present:65024kB mlocked:0kB dirty:0kB writeback:0kB mapped:488kB shmem:0kB slab_reclaimable:432kB slab_unreclaimable:3424kB kernel_stack:192kB pagetables:64kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 0
Normal: 0*4kB 0*8kB 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 0kB
2490 total pagecache pages
0 pages in swap cache
Swap cache stats: add 0, delete 0, find 0/0
Free swap  = 0kB
Total swap = 0kB
16384 pages of RAM
48 free pages
5463 reserved pages
859 slab pages
233 pages shared
0 pages swap cached
Killed

我尝试过将该数组缩小，将ko文件减小至6M左右，无问题。
打印如下：
[root@wws /1]# insmod mini2440_hello_module-6m.ko  
Hello, Mini2440 module is installed !

请问有什么方法可以解决大尺寸ko文件加载的问题？

望各位大神赐教，谢谢了！

humjb_1983

Normal free:1008kB min:1016kB
空闲内存已经到了水线了，触发了oom，内存不足~

arm-linux-gcc

次奥，arm里面，module area没有17M那么大

范围是
MODULES_VADDR ～ MODULES_END-1


#ifndef CONFIG_THUMB2_KERNEL
#define MODULES_VADDR                (PAGE_OFFSET - SZ_16M)
#else
/* smaller range for Thumb-2 symbols relocation (2^24)*/
#define MODULES_VADDR                (PAGE_OFFSET - SZ_8M)
#endif

#if TASK_SIZE > MODULES_VADDR
#error Top of user space clashes with start of module space
#endif

/*
* The highmem pkmap virtual space shares the end of the module area.
*/
#ifdef CONFIG_HIGHMEM
#define MODULES_END                (PAGE_OFFSET - PMD_SIZE)
#else
#define MODULES_END                (PAGE_OFFSET)
#endif

也就是说最大只有16M，如果开了high mem就只有14M

mingzm123

谢谢各位的解答。
如果当我需要加载大于16M的内核模块时，是否有解决办法呢？

（我尝试修改TASK_SIZE和MODULES_VADDR值，未达到目的）

humjb_1983

mingzm123 发表于 2014-07-02 20:46
谢谢各位的解答。
如果当我需要加载大于16M的内核模块时，是否有解决办法呢？

排除module加载自身的限制，就要增加物理内存了。。。

arm-linux-gcc

你改了之后，看看启动log，有以下输出
Virtual kernel memory layout:
    vector  : 0xffff0000 - 0xffff1000   (   4 kB)
    fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
    vmalloc : 0xf0000000 - 0xff000000   ( 240 MB)
    lowmem  : 0xc0000000 - 0xef800000   ( 760 MB)
    pkmap   : 0xbfe00000 - 0xc0000000   (   2 MB)
    modules : 0xbf000000 - 0xbfe00000   (  14 MB)
      .text : 0xc0008000 - 0xc06b49e8   (6835 kB)
      .init : 0xc06b5000 - 0xc06f3600   ( 250 kB)
      .data : 0xc06f4000 - 0xc0749e20   ( 344 kB)
       .bss : 0xc0749e20 - 0xc0ca8530   (5498 kB)

看看红色部分变大没

manwenbin520

可以取消最大限制为16M吗，比如我想设置32M怎么设置，由于我弄的bcm sdk 包的ko文件比较大回复 3# arm-linux-gcc


   

manwenbin520

回复 3# arm-linux-gcc

可以取消最大限制为16M吗，比如我想设置32M怎么设置，由于我弄的bcm sdk 包的ko文件比较大
   

arm-linux-gcc

回复 8# manwenbin520


最好不要改这个，因为TASK_SIZE和这个有关
为什么16M都不够你用？你是开了很大的全局数组？