LINUX.ORG.RU
Форум — Development  

OOM когда в системе полно свободной памяти

 , ,


0

5

вобщем есть embedded система с 32Mb рамы. cat /proc/buddyinfo говорит то у нас свободно более 12 Mb. но при этом я не могу стартануть шелл из busybox которому требуется всего 130k памяти. Система валится про срабатыванию OOM киллера. Фрагментация в пределах нормы. что еще может быть?

★★★★★
← Таймер на libGDX
Оптимизация кода смешея цветов →
 ← 1 2
Ответ на: комментарий от cvv

Печально. Возможно заменить что-то на лёгкий аналог? Ядро освободить от лишних модулей. А хотя это эмбед...

a1batross ★★★★★
()
Ответ на: комментарий от cvv

Если не жалко процессорного времени, возможно compcache поможет.

a1batross ★★★★★
()

Есть такая штука, как zram

Xenius ★★★★★
()
Ответ на: комментарий от Harald

из rss по предыдущим экземплярам шела

cvv ★★★★★
() автор топика

Какую-то часть рамы ядро могло зарезервировать. К сожалению, не помню что надо крутить. Посмотри, например, vm.admin_reserve_kbytes

true_admin ★★★★★
()

Экономия на спичках, гиговый чип памяти дешевле стакана семок, не понимаю я этого жесткого эмбедерства...

anonymous
()
Ответ на: комментарий от anonymous

Осталось всего-ничего - придумать как влепить левую память в готовый девайс.

Pavval ★★★★★
()
Ответ на: комментарий от one_more_hokum

у меня киллер настроен на панику . в моем случае не много смысла продолжать работу потому что все процессы критические

cvv ★★★★★
() автор топика
Последнее исправление: cvv (всего исправлений: 1)
Ответ на: комментарий от one_more_hokum

в смысле MMU ? Да - есть

cvv ★★★★★
() автор топика
Ответ на: комментарий от cvv

Эта самая железка у тебя в работе, или пока в разработке/отладке? Если OOM-killer отключить, и посмотреть, что происходит при попытке создания процесса? Аллокатор памяти ошибётся, или что другое случится? Если запустить не шелл, а что-нить более другое, да хоть HelloWorld самописный — как отреагирует система?

one_more_hokum ★★★
()

И, кстати:

Доступные пользователю настройки:
vm.panic_on_oom — считать запуск OOM критической ошибкой.

one_more_hokum ★★★
()
Ответ на: комментарий от one_more_hokum

Эта самая железка у тебя в работе, или пока в разработке/отладке?

считаем что уже в работе. ну как минимум нет возможности увеличить память.

Если OOM-killer отключить, и посмотреть, что происходит при попытке создания процесса? Аллокатор памяти ошибётся, или что другое случится? Если запустить не шелл, а что-нить более другое, да хоть HelloWorld самописный — как отреагирует система?

тут есть некоторые проблемы с воспроизводимостью. но обычно проблема гдето такая: fork() не может выделить память для каталога страниц потомка.

cvv ★★★★★
() автор топика
Ответ на: комментарий от cvv

Ну, непосредственно перед выделением памяти кто-то эту самую память подъедает map-ом файла (например). Ты говорил, что свопа в системе нет, вот и получается, что в случайные (относительно) моменты времени количество доступной оперативки сокращается, а спихнуть старые/малоиспользуемые данные из неё некуда.

Но это так, гадания по юзерпику...

one_more_hokum ★★★
()

попытался занизить порядки для slub. фрагментация упала гдето пополам. надеюсь полегчает.

cvv ★★★★★
() автор топика

Если бы overcommit был отключен, можно было бы сказать, что busybox пытается форкнуться, и на это у системы не хватает памяти (=> используй vfork). Но с включенным overcommit и фрагментацией в пределах нормы ситуация странная. Что конкретно говорит OOM killer?

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

Но с включенным overcommit и фрагментацией в пределах нормы ситуация странная.

та не говори :)

ну вот типичный пример. хотя обычно свободных страниц необходимого порядка больше.

<4>[ 5945.316680] hotplug invoked oom-killer: gfp_mask=0xd0, order=2, oom_adj=0                   
<5>[ 5945.316741] [<c1b06035>] (unwind_backtrace+0x1/0x98) from [<c1d340d7>] (dump_stack+0xb/0xc) 
<5>[ 5945.316802] [<c1d340d7>] (dump_stack+0xb/0xc) from [<c1b52b97>] (dump_header.clone.1+0x43/0xf8)                                                                                               
<5>[ 5945.316833] [<c1b52b97>] (dump_header.clone.1+0x43/0xf8) from [<c1b52ea9>] (out_of_memory+0x7d/0x94)                                                                                          
<5>[ 5945.316864] [<c1b52ea9>] (out_of_memory+0x7d/0x94) from [<c1b551fd>] (__alloc_pages_nodemask
+0x37d/0x398)                                                                                     
<5>[ 5945.316894] [<c1b551fd>] (__alloc_pages_nodemask+0x37d/0x398) from [<c1b55223>] (__get_free_pages+0xb/0x24)                                                                                   
<5>[ 5945.316925] [<c1b55223>] (__get_free_pages+0xb/0x24) from [<c1b08ff3>] (get_pgd_slow+0xf/0x9c)                                                                                                
<5>[ 5945.317016] [<c1b08ff3>] (get_pgd_slow+0xf/0x9c) from [<c1b24a2f>] (mm_init+0x67/0x94)      
<5>[ 5945.317047] [<c1b24a2f>] (mm_init+0x67/0x94) from [<c1b24dd1>] (dup_mm+0x59/0x39c)          
<5>[ 5945.317077] [<c1b24dd1>] (dup_mm+0x59/0x39c) from [<c1b259f3>] (copy_process+0x837/0x9b4)   
<5>[ 5945.317108] [<c1b259f3>] (copy_process+0x837/0x9b4) from [<c1b25baf>] (do_fork+0x3f/0x224)  
<5>[ 5945.317138] [<c1b25baf>] (do_fork+0x3f/0x224) from [<c1b03881>] (sys_fork+0x15/0x18)        
<5>[ 5945.317169] [<c1b03881>] (sys_fork+0x15/0x18) from [<c1b00d01>] (ret_fast_syscall+0x1/0x46) 
<5>[ 5945.317199] Mem-info:                                                                       
<5>[ 5945.317199] Normal per-cpu:                                                                 
<5>[ 5945.317230] CPU    0: hi:   18, btch:   3 usd:  14                                          
<5>[ 5945.317230] active_anon:1576 inactive_anon:1601 isolated_anon:5                             
<5>[ 5945.317260]  active_file:4 inactive_file:4 isolated_file:59                                 
<5>[ 5945.317260]  unevictable:0 dirty:0 writeback:0 unstable:0                                   
<5>[ 5945.317260]  free:1879 slab_reclaimable:163 slab_unreclaimable:836                          
<5>[ 5945.317260]  mapped:28 shmem:104 pagetables:595 bounce:0                                    
<5>[ 5945.317321] Normal free:7516kB min:1016kB low:1268kB high:1524kB active_anon:6304kB inactive
_anon:6404kB active_file:16kB inactive_file:16kB unevictable:0kB isolated(anon):20kB isolated(file
):236kB present:65024kB mlocked:0kB dirty:0kB writeback:0kB mapped:112kB shmem:416kB slab_reclaima
ble:652kB slab_unreclaimable:3344kB kernel_stack:1528kB pagetables:2380kB unstable:0kB bounce:0kB 
writeback_tmp:0kB pages_scanned:64 all_unreclaimable? no                                          
<5>[ 5945.317352] lowmem_reserve[]: 0 0                                                           
<5>[ 5945.317382] Normal: 563*4kB 656*8kB 1*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*
2048kB 0*4096kB = 7516kB                                                                          
<5>[ 5945.317443] 155 total pagecache pages                                                       
<5>[ 5945.319702] 16384 pages of RAM                                                              
<5>[ 5945.319702] 2298 free pages                                                                 
<5>[ 5945.319702] 7956 reserved pages                                                             
<5>[ 5945.319732] 687 slab pages                                                                  
<5>[ 5945.319732] 240 pages shared                                                                
<5>[ 5945.319732] 0 pages swap cached                                                             
<6>[ 5945.319732] [ pid ]   uid  tgid total_vm      rss cpu oom_adj name                          
<6>[ 5945.319763] [    1]     0     1       78       18   0       0 init                          
<6>[ 5945.319793] [   57]     0    57       74       14   0       0 ueventd                       
<6>[ 5945.319824] [   62]     0    62      858       17   0       0 adbd
cvv ★★★★★
() автор топика
Последнее исправление: cvv (всего исправлений: 2)
Ответ на: комментарий от tailgunner

больше всего похоже на фрагментацию.

у тебя есть идеи почему в конкрентной ситуации небыл возвращен тот единственный элемент?

а еще у меня еще гдето валяются аналогичные трассы где при этом более 5 элементов второго порядка и по одному 3, 4 и пятого ...

содержимое консоли при этом тоже самое

cvv ★★★★★
() автор топика
Ответ на: комментарий от cvv

Ну, если теоретизировать - что-то успело освободить этот элемент между моментом, когда ядро поняло, что нужно запустить киллера, и моментом, когда киллер дошел до дампа спсков свободных страниц. Но ситуацию с наличием элементов более высокого порядка это не объясняет. Надо смотреть текст get_pgd_slow.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

Объясни дураку, почему несколько физических страниц по 4кб не могут быть замаплены в виде одного большого логического куска?

true_admin ★★★★★
()
Ответ на: комментарий от true_admin

почему несколько физических страниц по 4кб не могут быть замаплены в виде одного большого логического куска?

Могут. Но иногда нужен физически протяженный кусок памяти. Видимо, таблицы страниц - это как раз один из этих редких случаев, что выглядит вполне логично.

tailgunner ★★★★★
()
Ответ на: комментарий от true_admin

Без проблем. man vmalloc().

cvv ★★★★★
() автор топика
Ответ на: комментарий от tailgunner

а вот еще краш

<4>[ 2726.354339] check_xxx_xxxxx invoked oom-killer: gfp_mask=0xd0, order=2, oom_adj=0           
<5>[ 2726.354400] [<c1b06035>] (unwind_backtrace+0x1/0x98) from [<c1d3526f>] (dump_stack+0xb/0xc) 
<5>[ 2726.354431] [<c1d3526f>] (dump_stack+0xb/0xc) from [<c1b52c07>] (dump_header.clone.1+0x43/0x
<5>[ 2726.354461] [<c1b52c07>] (dump_header.clone.1+0x43/0xf8) from [<c1b52f19>] (out_of_memory+0x
<5>[ 2726.354522] [<c1b52f19>] (out_of_memory+0x7d/0x94) from [<c1b5526d>] (__alloc_pages_nodemask
<5>[ 2726.354553] [<c1b5526d>] (__alloc_pages_nodemask+0x37d/0x398) from [<c1b55293>] (__get_free_
<5>[ 2726.354583] [<c1b55293>] (__get_free_pages+0xb/0x24) from [<c1b08ff3>] (get_pgd_slow+0xf/0x9
<5>[ 2726.354614] [<c1b08ff3>] (get_pgd_slow+0xf/0x9c) from [<c1b24a9f>] (mm_init+0x67/0x94)      
<5>[ 2726.354644] [<c1b24a9f>] (mm_init+0x67/0x94) from [<c1b24e41>] (dup_mm+0x59/0x39c)          
<5>[ 2726.354675] [<c1b24e41>] (dup_mm+0x59/0x39c) from [<c1b25a63>] (copy_process+0x837/0x9b4)   
<5>[ 2726.354705] [<c1b25a63>] (copy_process+0x837/0x9b4) from [<c1b25c1f>] (do_fork+0x3f/0x224)  
<5>[ 2726.354736] [<c1b25c1f>] (do_fork+0x3f/0x224) from [<c1b03881>] (sys_fork+0x15/0x18)        
<5>[ 2726.354766] [<c1b03881>] (sys_fork+0x15/0x18) from [<c1b00d01>] (ret_fast_syscall+0x1/0x46) 
<5>[ 2726.354797] Mem-info:                                                                       
<5>[ 2726.354797] Normal per-cpu:                                                                 
<5>[ 2726.354797] CPU    0: hi:   18, btch:   3 usd:   7                                          
<5>[ 2726.354827] active_anon:1370 inactive_anon:1423 isolated_anon:5                             
<5>[ 2726.354858]  active_file:0 inactive_file:0 isolated_file:12                                 
<5>[ 2726.354858]  unevictable:0 dirty:0 writeback:0 unstable:0                                   
<5>[ 2726.354858]  free:3051 slab_reclaimable:175 slab_unreclaimable:900                          
<5>[ 2726.354858]  mapped:29 shmem:109 pagetables:2.99 bounce:0                                   
<5>[ 2726.354919] Normal free:12204kB min:1016kB low:1268kB high:1524kB active_anon:5480kB inactiv
<5>[ 2726.354949] lowmem_reserve[]: 0 0                                                           
<5>[ 2726.354980] Normal: 895*4kB 1050*8kB 14*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 
<5>[ 2726.355041] 110 total pagecache pages                                                       
<5>[ 2726.362426] 16384 pages of RAM                                                              
<5>[ 2726.362426] 3362 free pages                                                                 
<5>[ 2726.362457] 7956 reserved pages                                                             
<5>[ 2726.362457] 726 slab pages                                                                  
<5>[ 2726.362457] 116 pages shared                                                                
<5>[ 2726.362457] 0 pages swap cached                                                             
<6>[ 2726.362487] [ pid ]   uid  tgid total_vm      rss cpu oom_adj name                          
<6>[ 2726.362518] [    1]     0     1       78       18   0       0 init                          
<6>[ 2726.362548] [   57]     0    57       74       14   0       0 ueventd                       
<6>[ 2726.362579] [   62]     0    62      342       11   0       0 adbd

здесь страниц второго порядка больше чем достаточно но тем не менее ...

cvv ★★★★★
() автор топика
Последнее исправление: cvv (всего исправлений: 1)
Ответ на: комментарий от tailgunner

Ух ты, какая у тебя экзотика. На этой архитектуре хоть MMU есть?

почему экзотика? в моих логах есть чтото необычное?

у меня:

<4>[    0.000000] CPU: ARMv7 Processor [560f5815] revision 5 (ARMv7), cr=50c53c7f                 
<4>[    0.000000] CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache

MMU естественно есть

cvv ★★★★★
() автор топика
Ответ на: комментарий от cvv

почему экзотика? в моих логах есть чтото необычное?

В твоих логах есть get_pgd_slow - если верить LXR, то она присуствует только на некой архитектуре unicore32. У тебя старое или патченое ядро?

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

у меня

<5>[    0.000000] Linux version 2.6.3
5.7 (xxx@yyyyy) (gcc version 4.4.3 (GCC) ) #5 PREEMPT Mon Oct 14 16:17:32 IST 2013

да - ядро патченное производителем конкретного чипа. ну как обычно.

cvv ★★★★★
() автор топика
Ответ на: комментарий от cvv

Linux version 2.6.3

Ы. Епт. Ахаха.

да - ядро патченное производителем конкретного чипа. ну как обычно

Ядро, патченное малограмотными индусами, которых производитель нанял на неделю, ну как обычно %)

Если у тебя есть доступ к техподдержке «производителя чипа», попробуй поговорить с ней насчет патчей. Если нет... судя по логу, там в get_pgd_slow в get_free_page передается маска GFP_IOFS. Это несколько странно - на мой взгляд, там должно быть GFP_KERNEL (правда, я не кернел хакер, а рядовой драйверописатель). Если есть желание поэкспериментировать, попробуй заменить маску.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

извиняюсь но в предыдущем фрагменте случайно затесался лишний перевод строки.

<5>[    0.000000] Linux version 2.6.35.7 (xxx@yyyyy) (gcc version 4.4.3 (GCC) ) #5 PREEMPT Mon Oct 14 16:17:32 IST 2013

Ядро, патченное малограмотными индусами, которых производитель нанял на неделю, ну как обычно %)

Этот производитель обходится без индусов ...

судя по логу, там в get_pgd_slow в get_free_page передается маска GFP_IOFS. Это несколько странно - на мой взгляд, там должно быть GFP_KERNEL

Хм. Обращу внимание.

cvv ★★★★★
() автор топика
Ответ на: комментарий от tailgunner

в моем кернеле get_pgd_slow() обьявлена в include/asm-arm/pgalloc.h

git blame говорит что это сделал торвальдс лично в ревизии ^1da177e

а реалшизация этой ф-и находится в файле arch/arm/mm/mm-armv.c в тойже ревизии имени Торвальдса

cvv ★★★★★
() автор топика
Последнее исправление: cvv (всего исправлений: 1)
Ответ на: комментарий от cvv

Ну Торвальдс тот еще быдлокодер и комиттер чужого быдлокода. В тех экземплярах get_pgd_slow, которые я вижу в LXR, GFP_IOFS нет, а в гугле пишут, что GFP_IOFS вообще нужно только для suspend.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

у меня в include/linux/gfp.h GFP_KERNEL обьявлен как (__GFP_WAIT | __GFP_IO | __GFP_FS) в том же патче имени торвальдса.

тоесть мои gfp_mask=0xd0 вполне соответствуют GFP_KERNEL

cvv ★★★★★
() автор топика
Последнее исправление: cvv (всего исправлений: 2)
Ответ на: комментарий от cvv

Тогда одно из двух: либо OOM - это штатное поведение в данной ситуации, либо исчезновение get_pgd_slow имеет какой-то смысл и нужно пробовать более новые ядра.

tailgunner ★★★★★
()
Ответ на: комментарий от cvv

Я не большой спец по ядру, но, насколько мне известно, ООМ может быть не только при нехватке памяти. Тоже самое можно получить, если нет места в таблице процессов. Может стоит посмотреть в эту сторону?

anonymous
()
Ответ на: комментарий от tailgunner

Хотя, судя по

#define __pgd_alloc()   (pgd_t *)__get_free_pages(GFP_KERNEL, 2)

в новых ядрах может быть то же самое.

tailgunner ★★★★★
()
Ответ на: комментарий от anonymous

я всегда считал что таблица процессов - это двухсвязный список. я неправ?

cvv ★★★★★
() автор топика
Ответ на: комментарий от anonymous

ООМ может быть не только при нехватке памяти. Тоже самое можно получить, если нет места в таблице процессов

Трейс это исключает. Да и нехватка места в таблице просто вызвала бы завершение fork с ошибкой.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

вобщем я обнаружил что ситуация класно воспроизводится форк-бомбой из шела. просьба попробовать у себя и поделится соображениями.

cvv ★★★★★
() автор топика
Ответ на: комментарий от tailgunner

нет.

только что попробовал заминимизировать порядки в SLUB. система продержалась существенно дольше.

cvv ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
 ← 1 2
← Таймер на libGDX
Development
Оптимизация кода смешея цветов →