hi michal: 2016-10-14 23:26 GMT+08:00 Michal Hocko <mhocko@xxxxxxxxxx>: > On Fri 14-10-16 17:29:34, yoma sophian wrote: > [...] >> [ 5515.127555] dialog invoked oom-killer: gfp_mask=0x80d0, order=0, >> oom_score_adj=0 > > This looks like a GFP_KERNEL + something allocation Yes, you are correct. The page is allocated with GFP as (KERNEL + ZERO) flag > >> [ 5515.444859] Normal: 4314*4kB (UEMC) 3586*8kB (UMC) 131*16kB (MC) >> 21*32kB (C) 6*64kB (C) 1*128kB (C) 0*256kB 0*512kB 0*1024kB 0*2048kB >> 0*4096kB = 49224kB > > And it seems like CMA blocks are spread in all orders and no unmovable > allocations can fallback in them. It seems that there should be some > movable blocks but I do not have any idea why those are not used. Anyway > this is where I would start investigating. Per your kind hint, I trace pcp page allocation again.(since the order of allocation is 0 this time) I found when the list of pcp with unmovable type is empty, it will call rmqueue_bulk for trying to get batch, 31 order-0 pages. And rmqueue_bulk will call __rmqueue_smallest and even __rmqueue_fallback once the buddy of unmovable memory is not enough. But from below message: [ 5515.444859] Normal: 4314*4kB (UEMC) 3586*8kB (UMC) the order 0 of U type in buddy is at least has 1 page free. That mean even there is not enough 32 order-0 pages with U in buddy right now, buddy can at least provide 1 page to satisfy this allocation. if my conclusion is correct, there is no need for fallback. Please correct me, if I am wrong. Sincerely appreciate your kind help, -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>