android lmk,AndroidLMKandOOM

最新推荐文章于 2024-05-29 09:40:59 发布

转载最新推荐文章于 2024-05-29 09:40:59 发布

· 476 阅读

文章标签：

#android lmk

1 背景：

最近在项目中遇到一个奇怪问题，android中做monkey测试时跳过LMK直接发生OOM，由于新接触android，按照网上资料和个人理解，应该先发生LMK然后才是OOM呀。于是花了点时间研究了下，mark下。

2 分析：

2.1 发生问题时LOG

DMA free:110724kB

min:3100kB low:9668kB high:10444kB active_anon:199844kB

inactive_anon:3564kB active_file:164kB inactive_file:68kB

unevictable:0kB isolated(anon):0kB isolated(file):0kB

present:892928kB managed:865200kB mlocked:0kB dirty:4kB

writeback:0kB mapped:305472kB shmem:3564kB slab_reclaimable:5716kB

slab_unreclaimable:23428kB kernel_stack:8336kB pagetables:4092kB

unstable:0kB bounce:0kB free_pcp:1044kB local_pcp:352kB

free_cma:107744kB writeback_tmp:0kB pages_scanned:1952

all_unreclaimable? yes

lowmem_reserve[]: 0

0 1496 1496

HighMem free:77480kB

min:512kB low:12148kB high:13520kB active_anon:585924kB

inactive_anon:8164kB active_file:173092kB inactive_file:666684kB

unevictable:0kB isolated(anon):0kB isolated(file):0kB

present:1531904kB managed:1531904kB mlocked:0kB dirty:8kB

writeback:0kB mapped:491188kB shmem:9340kB slab_reclaimable:0kB

slab_unreclaimable:0kB kernel_stack:0kB pagetables:18836kB

unstable:0kB bounce:0kB free_pcp:864kB local_pcp:216kB free_cma:0kB

writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no

lowmem_reserve[]: 0

0 0 0

DMA: 443*4kB (UMEC)

206*8kB (MC) 12*16kB (C) 41*32kB (C) 34*64kB (C) 34*128kB (C)

18*256kB (C) 27*512kB (C) 5*1024kB (C) 3*2048kB (C) 17*4096kB (C) =

110780kB

HighMem: 985*4kB

(UM) 40*8kB (UM) 18*16kB (UM) 10*32kB (UM) 3*64kB (UM) 2*128kB (UM)

2*256kB (UM) 0*512kB 0*1024kB 1*2048kB (M) 17*4096kB (M) =

77508kB

2.2 Android

LMK配置

adj

117

176

529

1000

minfree

18432

23040

27648

32256

36864

46080

72MB

90MB

108MB

126MB

144MB

180MB

为了确认LMK机制是否工作，我们做了如下实验：

-〉在应用层不断的分配内存

-〉调整adj参数，echo 81920, 122880, 204800, 286720, 368640, 409600

/sys/module/lowmemorykiller/parameters/minfree

这2种情况下都可以顺利触发LMK，说明LMK机制是工作的。

发生问题时DMA zone free 110724KB，HIGH zone 77480KB，系统的free

memory是有的，应该不会触发LMK，更不用说OOM了，查看mm/page_alloc.c

中__alloc_pages_nodemask函数，发生问题时调用关系如下：

__alloc_pages_nodemask -〉__alloc_pages_slowpath

-〉get_page_from_freelist -〉__alloc_pages_may_oom

原因在于函数get_page_from_freelist 会调用zone_watermark_ok() check

wmark是不是OK，结果返回false；从LOG上也可以看出，虽然DMA zone free

有110724KB，但是cma内存107744KB，因此DMA

zone的剩余内存大部分是CMA内存，扣除CMA内存只剩下2980KB <

DMA ZONE min wmark 3100KB，因此发生OOM。

总结：

-->在check

zone的wmark时，是需要扣除CMA内存的：

#ifdef CONFIG_CMA

if (!(alloc_flags & ALLOC_CMA))

free_pages -= zone_page_state(z, NR_FREE_CMA_PAGES);

#endif

-->

LMK机制中只是把所有的可用的系统内存减掉系统预留的内存，在我们这种情况下应该是110724KB+77480KB

-10444KB-13520KB。

int other_free = global_page_state(NR_FREE_PAGES) -

totalreserve_pages;

int other_file = global_page_state(NR_FILE_PAGES) -

global_page_state(NR_SHMEM) -

total_swapcache_pages();

所以并不是一定先发生LMK然后才会发生OOM。

4 解决：

solution 1: reduce CMA reserved memory:

由于分辨率比较高(1920x720)，因此我们给CMA内存256M，较小的内存会引起GraphicBufferAllocator

fail，256M内存只是基于我们的估算:

framebuffer need by

surfacefliger --> 4

each APK use triple buffer

to draw, max of 3 apk at the same time -> 3*3 = 9

other non-HMI case: 2~3,

so total fb maybe 16, each buffer about 8M for aligment, so we

allocate 256M CMA, and we confirmed that 192M CMA memory still

would fail.

solution

2: 待续