Um assassino oom isso está me desconcertando

Question

Eu não sou capaz de entender por que o kernel enviaria este oom killer quando eu vejo memória suficiente disponível:

Além disso, por que há tantas páginas de cache do kernel alocadas? Eu digo que memória suficiente está disponível depois de olhar para

Normal

DMA

Linhas livres normais

Este é um dispositivo baseado em flash nand com 256 MB de RAM

Kernel: 2.6.31

 myshellscript invoked oom-killer: gfp_mask=0xd0, order=2, oomkilladj=0 
 Backtrace: 
 [<c0106494>] (dump_backtrace+0x0/0x110) from [<c03641a0>] (dump_stack+0x18/0x1c) 
 r6:000000d0 r5:c9040c60 r4:00000002 r3:c0448690 
 [<c0364188>] (dump_stack+0x0/0x1c) from [<c015a314>] (oom_kill_process.clone.11+0x60/0x1b4) 
 [<c015a2b4>] (oom_kill_process.clone.11+0x0/0x1b4) from [<c015a738>] (__out_of_memory+0x154/0x178) 
 r8:c21e86e0 r7:001fb000 r6:00000002 r5:000000d0 r4:c9b6e000 
 [<c015a5e4>] (__out_of_memory+0x0/0x178) from [<c015a980>] (out_of_memory+0x68/0xa0) 
 [<c015a918>] (out_of_memory+0x0/0xa0) from [<c015d230>] (__alloc_pages_nodemask+0x42c/0x520) 
 r5:00000002 r4:000000d0 
 [<c015ce04>] (__alloc_pages_nodemask+0x0/0x520) from [<c015d388>] (__get_free_pages+0x18/0x44) 
 [<c015d370>] (__get_free_pages+0x0/0x44) from [<c0109418>] (get_pgd_slow+0x1c/0xe0) 
 [<c01093fc>] (get_pgd_slow+0x0/0xe0) from [<c0129ab0>] (mm_init.clone.43+0xb0/0xf0) 
 r7:c90858c0 r6:00000000 r5:c90858c0 r4:ce1a6680 
 [<c0129a00>] (mm_init.clone.43+0x0/0xf0) from [<c0129c40>] (mm_alloc+0x34/0x44) 
 r6:0009230c r5:c90858c0 r4:ce1a6680 r3:00000000 
 [<c0129c0c>] (mm_alloc+0x0/0x44) from [<c0180f70>] (bprm_mm_init+0x14/0x148) 
 r4:c5154000 r3:cd472564 
 [<c0180f5c>] (bprm_mm_init+0x0/0x148) from [<c01812d0>] (do_execve+0xa8/0x254) 
 [<c0181228>] (do_execve+0x0/0x254) from [<c0106000>] (sys_execve+0x3c/0x5c) 
 [<c0105fc4>] (sys_execve+0x0/0x5c) from [<c0102e80>] (ret_fast_syscall+0x0/0x2c) 
 r7:0000000b r6:0009230c r5:0009237c r4:000922fc 
 Mem-info: 
 DMA per-cpu: 
 CPU 0: hi: 18, btch: 3 usd: 0 
 Normal per-cpu: 
 CPU 0: hi: 42, btch: 7 usd: 0 
 Active_anon:28162 active_file:16 inactive_anon:18037 
 inactive_file:13 unevictable:0 dirty:0 writeback:0 unstable:0 
 free:9998 slab:2447 mapped:164 pagetables:701 bounce:0 
 DMA free:17128kB min:1560kB low:1948kB high:2340kB active_anon:51068kB inactive_anon:10320kB active_file:24kB inactive_file:0kB unevictable:0kB present:97536kB pages_scanned:0 all_unreclaimable? no 
 lowmem_reserve[]: 0 158 158 
 Normal free:22864kB min:2600kB low:3248kB high:3900kB active_anon:61580kB inactive_anon:61828kB active_file:40kB inactive_file:52kB unevictable:0kB present:162560kB pages_scanned:0 all_unreclaimable? no 
 lowmem_reserve[]: 0 0 0 
 DMA: 2358*4kB 912*8kB 25*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB 0*8192kB 0*16384kB = 17128kB 
 Normal: 4266*4kB 657*8kB 32*16kB 1*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB 0*8192kB 0*16384kB = 22864kB 
 26591 total pagecache pages 
 0 pages in swap cache 
 Swap cache stats: add 0, delete 0, find 0/0 
 Free swap = 0kB 
 Total swap = 0kB 
 65536 pages of RAM 
 10471 free pages 
 3967 reserved pages 
 2447 slab pages 
 892 shared page count 
 389 shared pages
 620 mapped shared page count
 177 mapped shared pages
 0 pages swap cached
 2481 dma reserved pages
 19892 total user pages
 20512 RSS sum by tasks
 20512 RSS sum by page stats
 164 user cache pages
 26427 kernel cache pages

    

Answer 1

Editar: esta resposta está incorreta. Apesar de ainda ser uma possível causa para o oom-killer ser invocada, não é a causa neste caso específico.

Parece que isso ocorre devido à fragmentação da memória.

Da saída que você forneceu, o bloco de memória contígua de maior ordem que você tem é um bloco de 32kb na normal zone. Isso significa que, se algo tentar alocar um pedaço de memória maior que 32kb, ele falhará. Normalmente, isso não significa necessariamente que o oom-killer será invocado (caso contrário, um aplicativo pode solicitar um grande pedaço de memória e, assim, disparar o OOM), no entanto, esse é o kernel que está tentando alocar memória e, portanto, é um pouco mais sério. Neste caso exato, parece que a alocação foi acionada iniciando um novo processo, e o kernel estava tentando alocar memória para esse processo.

O kernel automaticamente tenta compactar (desfragmentar) a memória e obter pedaços maiores de memória contígua disponível, mas algumas páginas não podem ser movidas. E quanto mais tempo o sistema estiver em execução, mais dispersas serão as páginas "inamovíveis".

Então, basicamente, não há muito que você possa fazer. Realmente, a única opção é eliminar processos para liberar as páginas que não podem ser movidas.

Quanto ao que na saída acima indica a fragmentação de memória, são as seguintes linhas

 DMA: 2358*4kB 912*8kB 25*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB 0*8192kB 0*16384kB = 17128kB 
 Normal: 4266*4kB 657*8kB 32*16kB 1*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB 0*8192kB 0*16384kB = 22864kB

Uma entrada como 32*16kb significa que há 32 blocos contíguos de 16kb livres de memória.

    

Answer 2

Estamos lidando com um aplicativo desconhecido em uma plataforma incorporada desconhecida. Obviamente, se tivéssemos mais informações sobre esses dois pontos, poderíamos ter uma chance melhor de responder à pergunta do abc. Também seria útil saber exatamente quanta memória o script está tentando adquirir.

Eu acho que Patrick está correto - não há DMA contíguo suficiente para permitir que o processo seja executado. Isso pode ser pelas seguintes possíveis razões:

1. O sistema incorporado pode ter uma implementação personalizada de paginação
2. O sistema incorporado pode não ter uma MMU
3. O script pode estar invocando um driver de E / S que acessa o DMA exatamente
4. O script pode conter programas de terceiros que exigem memória contígua

etc ...

Acredito que, se você reduzisse a fragmentação da memória DMA, o killer da OOM não estaria pulando. A maneira mais fácil de testar rapidamente é reiniciar o dispositivo incorporado e verificar se o OOM-killer ainda está sendo chamado.

Continuarei a dar voltas pela Internet à procura de uma forma leve e incorporada de fragmentar a memória sem reiniciar o dispositivo.

Este link pode ser de interesse: link