On Thu 28-07-16 15:50:32, Xishi Qiu wrote: > On 2016/7/20 15:47, Michal Hocko wrote: > > > On Wed 20-07-16 09:33:30, Yisheng Xie wrote: > >> > >> > >> On 2016/7/19 22:14, Vlastimil Babka wrote: > >>> On 07/19/2016 03:48 PM, Xishi Qiu wrote: > > [...] > >>>> mode:0x2000d1 means it expects to alloc from zone_dma, (on arm64 zone_dma is 0-4G) > >>> > >>> Yes, but I don't see where the __GFP_DMA comes from. The backtrace > >>> suggests it's alloc_thread_info_node() which uses THREADINFO_GFP > >>> which is GFP_KERNEL | __GFP_NOTRACK. There shouldn't be __GFP_DMA, > >>> even on arm64. Are there some local modifications to the kernel > >>> source? > >>> > >>>> The page cache is very small(active_file:292kB inactive_file:240kB), > >>>> so did_some_progress may be zero, and will not retry, right? > >>> > >>> Could be, and then __alloc_pages_may_oom() has this: > >>> > >>> /* The OOM killer does not needlessly kill tasks for lowmem */ > >>> if (ac->high_zoneidx < ZONE_NORMAL) > >>> goto out; > >>> > >>> So no oom and no faking progress for non-costly order that would > >>> result in retry, because of that mysterious __GFP_DMA... > >> > >> hi Vlastimil, > >> We do make change and add __GFP_DMA flag here for our platform driver's problem. > > > > Why would you want to force thread_info to the DMA zone? > > > > Hi Michal, > > Because of our platform driver's problem, so we change the code(add GFP_DMA) to let > it alloc from zone_dma. (on arm64 zone_dma is 0-4G) Why would any platform driver need to access kernel thread in the DMA zone? -- Michal Hocko SUSE Labs -- 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>