FAQ: 2010 Kernel memory fragmentation(2011-03-09)

Document created by Aaronwu Employee on Aug 28, 2013Last modified by sonic on Sep 8, 2013
Version 2Show Document
  • View in full screen mode

2011-03-09 07:32:52     2010 Kernel memory fragmentation

Yathindran P (INDIA)

Message: 98768   

 

Hi,

 

After booting 2010 Kernel in our custom blackfin BF527 board , we found out the memory was quite fragmented when compared to 2009 Kernel. We were able to successfully start our application in in 2009 Kernel with similar config.

 

On analysis we found out that  both 2009 Kernel and 2010 Kernel had approximately same free memory but in 2009 Kernel we were able to get two 16 MB memory chunks but in 2010 we got only one and hence the issue.

 

We adapted our 2009 Kernel config files to 2010 kernel config . Is there anything we should take special care in 2010 Kernel to avoid fragmentation ?

 

Any pointers towards solving this issue would be great

 

 

 

Board- bf527

 

Kernel Version - 2.6.34.7-ADI-2010R1

 

 

 

Regards,

 

Yathi

QuoteReplyEditDelete

 

 

2011-03-09 09:05:40     Re: 2010 Kernel memory fragmentation

Yathindran P (INDIA)

Message: 98770   

 

More Info:

 

 

 

2009 Kernel

 

root:/> cat /proc/buddyinfo

 

Node 0, zone      DMA      0      0      1      0      1      0      0      0      1      2      1      1      2      0

 

root:/> free

 

              total         used         free       shared      buffers

 

  Mem:        59440         9184        50256            0            0

 

 

 

2010 Kernel

 

root:/> free

 

              total         used         free       shared      buffers

 

  Mem:        59416         8400        51016            0            0

 

root:/> cat /proc/buddyinfo

 

Node 0, zone      DMA      2      1      3      2      3      0      2      2      4      4      3      1      1      0

 

root:/>

QuoteReplyEditDelete

 

 

2011-03-09 22:29:34     Re: 2010 Kernel memory fragmentation

Sonic Zhang (CHINA)

Message: 98808   

 

Please always avoid allocate large continuous memory block in your application on NOMMU architecture. If you successfully allocatedsuch a big block before, you are lucky. But, you won't be lucky for ever. Break it down in your application.

QuoteReplyEditDelete

 

 

2011-03-10 01:06:51     Re: 2010 Kernel memory fragmentation

Yathindran P (INDIA)

Message: 98814   

 

Ours is an embedded product solution whose data+bss comes around 13M and also it involves 3rd party libraries etc. We dont have huge data+bss member in our application but we do have lot of small members which is contributing to this size.

 

We require a 16M block to load our application. Since we had the same in 2009 Kernel, We are exploring to bring back the memory as in 2009 kernel.

 

Moreover a 16M in kernel is fragmented.. what module in 2010 kernel might require more than 8M for loading ?

 

Also could this be because of a kernel setting.  We are compared the kernel settings and could not find out any

 

 

...

QuoteReplyEditDelete

 

 

2011-03-10 01:29:20     Re: 2010 Kernel memory fragmentation

Bob Liu (CHINA)

Message: 98817   

 

> Any pointers towards solving this issue would be great

 

What about the results using other slab allocator?

 

eg.You can try using slob or slub, change the kernel config:

 

===========================

 

General setup  --->       

 

        Choose SLAB allocator (SLAB)  ---> 

 

===========================

 

 

 

And you'd better to change you application and libs following Sonic's suggestion.

QuoteReplyEditDelete

 

 

2011-03-15 00:33:51     Re: 2010 Kernel memory fragmentation

Yathindran P (INDIA)

Message: 98934   

 

Hi Bob,

 

I tried changing SLAB allocators but had problems while compilation itself, however i observed this

 

=> When i start my application , The application fails to load because of fragmented memory but immidiately after that somehow defragmentation happens and i am getting the contiguous memory i require to run the application(Wierd huh). In order for this to happen the application has to fail once atleast. Is there anything i can do in my code to make this happen

 

 

 

 

 

Test_App: page allocation failure. order:12, mode:0xd0

 

Hardware Trace:

 

   0 Target : <0x002a5d5c> { _dump_stack + 0x0 }

 

     Source : <0x001b0402> { ___alloc_pages_nodemask + 0x3ba } JUMP.L

 

   1 Target : <0x001b0402> { ___alloc_pages_nodemask + 0x3ba }

 

     Source : <0x002a5e50> { _printk + 0x14 } RTS

 

   2 Target : <0x002a5e4c> { _printk + 0x10 }

 

     Source : <0x0018f3c2> { _vprintk + 0x2da } RTS

 

   3 Target : <0x0018f3b6> { _vprintk + 0x2ce }

 

     Source : <0xffa00ca4> { __common_int_entry + 0xcc } RTI

 

   4 Target : <0xffa00c42> { __common_int_entry + 0x6a }

 

     Source : <0xffa00a8c> { _return_from_int + 0x58 } RTS

 

   5 Target : <0xffa00a8c> { _return_from_int + 0x58 }

 

     Source : <0xffa00a62> { _return_from_int + 0x2e } IF !CC JUMP pcrel

 

   6 Target : <0xffa00a34> { _return_from_int + 0x0 }

 

     Source : <0xffa00c3e> { __common_int_entry + 0x66 } JUMP.L

 

   7 Target : <0xffa00c3c> { __common_int_entry + 0x64 }

 

     Source : <0xffa0034e> { _asm_do_IRQ + 0x76 } RTS

 

   8 Target : <0xffa0033e> { _asm_do_IRQ + 0x66 }

 

     Source : <0x001922c2> { __local_bh_enable + 0x72 } RTS

 

   9 Target : <0x001922b0> { __local_bh_enable + 0x60 }

 

     Source : <0x00192292> { __local_bh_enable + 0x42 } IF CC JUMP pcrel (BP)

 

  10 Target : <0x00192282> { __local_bh_enable + 0x32 }

 

     Source : <0x00192264> { __local_bh_enable + 0x14 } IF CC JUMP pcrel (BP)

 

  11 Target : <0x00192250> { __local_bh_enable + 0x0 }

 

     Source : <0x001928d2> { ___do_softirq + 0xc2 } JUMP.L

 

  12 Target : <0x001928ca> { ___do_softirq + 0xba }

 

     Source : <0x001928be> { ___do_softirq + 0xae } IF CC JUMP pcrel

 

  13 Target : <0x001928b8> { ___do_softirq + 0xa8 }

 

     Source : <0x001928b2> { ___do_softirq + 0xa2 } IF CC JUMP pcrel

 

  14 Target : <0x001928ac> { ___do_softirq + 0x9c }

 

     Source : <0x001ab3f6> { _rcu_bh_qs + 0x22 } RTS

 

  15 Target : <0x001ab3f2> { _rcu_bh_qs + 0x1e }

 

     Source : <0x001ab3e6> { _rcu_bh_qs + 0x12 } IF CC JUMP pcrel (BP)

 

Stack info:

 

SP: [0x02759c3c] <0x02759c3c> /* kernel dynamic memory */

 

Memory from 0x02759c30 to 0275a000

 

02759c30: 000000d0  02759c3c  00000040 [00000000] 001b0406  02048080  00000000  000200d0

 

02759c50: 02048260  0000000c  000000d0  00000001  00000042  0046e5e8  00000000  02758008

 

02759c70: 00000010  00000050  00000040  02758000  02758000  00000010  000200d0  00000000

 

02759c90: 0046f018  02048080  00000000  0046e5e8  00000000  00000000  00000000  0046e5e8

 

02759cb0: 023120e0  001b7e80  003a57c8  0242f964  0242eb0c  0000000c  00000004  00001873

 

02759cd0: 00000000  04000000  00001802  0046f014  00000000  00000000  00000000  01758000

 

02759cf0: 00850000  00000850  00850887  0242cc8c  0000ffff  0242cc60  001dc20a  023cbc00

 

02759d10: 02424a70  02759e10  00000003  00001802  00000000  00000003  001c0c72  00472058

 

02759d30: 0084f888  00000003  00001802  000001ae  0018d2c8  02424a60  02759d60  00000000

 

02759d50: 00000000  0242cc8c  00000940  00000080  00000000  02759db4  001dc73e  02758000

 

02759d70: 023120e0  00000000  00000002  00020000  00000088  02759f24  00000000  023120e0

 

02759d90: 00000000  0036ac94  00000080  00000001  023123e0  02424f00  02759e30  001b0114

 

02759db0: 024aaafc  464c457f  00010101  00000000  00000000  006a0003  00000001  00001160

 

02759dd0: 00000034  00007440  10000002  00200034  00280004  000e000f  0241f5e0  00000000

 

02759df0: 00000000  00000000  00000000  00000000  00020000  00000000  00000000  80000010

 

02759e10: 464c457f  00010101  00000000  00000000  006a0002  00000001  000442a8  00000034

 

02759e30: 002035d4  00000002  00200034  00280007  001b001c  023cbba0  02424a60  01200000

 

02759e50: 00000000  00000000  00000000  00020000  00000000  00000000  80000050  0045c3c0

 

02759e70:<001bed2e> 0045c6b0  024aaa00  024aaa02  fffffff8  00000000  00000000  02759f24

 

02759e90: 024aaa00  02759f24  0100032c  0277f8d8  001bf824  024aaa00  01000330  027499e0

 

02759eb0: 00000000  02758000  00000001  01000344  00180868  001c20a8  024aaa00  00000000

 

02759ed0: 00180896  00180868  0000000b  0207c000  01000330  01000344  010002fc  027499e0

 

02759ef0: 00000020  00000000  02759f24 <ffa008ee> 00000000  ffffe000  0274c174  02744776

 

02759f10: 00000010  010002fc  00000003  010002fc  0274c174  027a0d6e  00008000  00000000

 

02759f30: 00000000  0275a000  027a0d6e  027a0d6e  02787952  ffa00ffc  02003025  027b197f

 

02759f50: 027aae33  027b1978  027aae32  00000000  00000000  00000000  00000000  00000000

 

02759f70: 00000000  00000000  00000000  00000000  00000000  00000000  00000000  00000000

 

02759f90: 00000000  00000000  00000000  00000000  00000000  00000000  00000000  027499e0

 

02759fb0: 010002c0  0277f8cc  0277f8d8  027499e0  027c4bb0  027499e0  02744782  01000309

 

02759fd0: 0000000b  00000000  01000330  0274c174  010002fc  00000003  01000344  01000330

 

02759ff0: 02744776  02744776  0000000b  00000006

 

Return addresses in stack:

 

    address : <0x001bed2e> { _search_binary_handler + 0x52 }

 

    address : <0xffa008ee> { _system_call + 0x6a }

 

Mem-Info:

 

DMA per-cpu:

 

CPU    0: hi:    0, btch:   1 usd:   0

 

active_anon:0 inactive_anon:0 isolated_anon:0

 

active_file:0 inactive_file:1166 isolated_file:0

 

unevictable:1587 dirty:0 writeback:0 unstable:0

 

free:10070 slab_reclaimable:319 slab_unreclaimable:643

 

mapped:0 shmem:0 pagetables:0 bounce:0

 

DMA free:40280kB min:1024kB low:1280kB high:1536kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:4664kB unevictable:6348kB isolated(anon):0kB isolated(file):0kB present:64008kB mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:1276kB slab_unreclaimable:2572kB kernel_stack:160kB pagetables:0kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no

 

lowmem_reserve[]: 0 0 0

 

DMA: 72*4kB 23*8kB 8*16kB 8*32kB 4*64kB 6*128kB 2*256kB 2*512kB 2*1024kB 3*2048kB 3*4096kB 2*8192kB 0*16384kB 0*32768kB = 40280kB

 

1587 total pagecache pages

 

16128 pages RAM

 

1280 pages reserved

 

1525 pages shared

 

3233 pages non-shared

 

Allocation of length 8714376 from process 358 (Test_App) failed

 

DMA per-cpu:

 

CPU    0: hi:    0, btch:   1 usd:   0

 

active_anon:0 inactive_anon:0 isolated_anon:0

 

active_file:0 inactive_file:1166 isolated_file:0

 

unevictable:1587 dirty:0 writeback:0 unstable:0

 

free:10070 slab_reclaimable:319 slab_unreclaimable:643

 

mapped:0 shmem:0 pagetables:0 bounce:0

 

DMA free:40280kB min:1024kB low:1280kB high:1536kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:4664kB unevictable:6348kB isolated(anon):0kB isolated(file):0kB present:64008kB mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:1276kB slab_unreclaimable:2572kB kernel_stack:160kB pagetables:0kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no

 

lowmem_reserve[]: 0 0 0

 

DMA: 72*4kB 23*8kB 8*16kB 8*32kB 4*64kB 6*128kB 2*256kB 2*512kB 2*1024kB 3*2048kB 3*4096kB 2*8192kB 0*16384kB 0*32768kB = 40280kB

 

1587 total pagecache pages

 

 

 

root:/> cat /proc/buddyinfo

 

Node 0, zone      DMA      1      0      0      2      0      3      2      2      2      3      2      1      1 * 16MB      0

 

root:/>

 

Regards,

 

yathi

QuoteReplyEditDelete

 

 

2011-03-15 07:28:26     Re: 2010 Kernel memory fragmentation

Appalayagari Sreedhar (INDIA)

Message: 98944   

 

Hi,

 

I am Sreedhar, Yathindran and me working for the same project.

 

I have run the pre compiled uImages (2009R1 and 2010R1) for BF527 Ezkitt in Ezkit hw.

 

I could see the difference that  two - 16MB memory chunks are available in 2009R1  but only 1 16MB chink available in 2010R1.

 

Please find the log details.

 

                        4k    8k    16k     32k    64k   128k   256k   512k    1M     2M     4M    8M     16M   32M  

 

2009kernel    0      0      2      0      0      0      0      1      0      2      1      1      2     0

 

2010kernel    6      1      1      1      1      2      2      0      3      4      3      1      1     0

 

We are facing the problem of loading the application and running it. our application size as yathindran mentioned it is around 16 MB.

 

We can not reduce the application size because we are working for the product development and all was well till 2009.

 

Now we are facing the problem with 2010 kenel.

 

Can you please help us to resolve this problem as soon as possible.

 

Thank you.

QuoteReplyEditDelete

 

 

2011-03-16 02:14:30     Re: 2010 Kernel memory fragmentation

Sonic Zhang (CHINA)

Message: 98956   

 

Compile your application into FDPIC binary and break down into shared libraries.

Attachments

    Outcomes