On Thu 28-07-16 15:50:32, Xishi Qiu wrote:

On 2016/7/20 15:47, Michal Hocko wrote:

quoted

On Wed 20-07-16 09:33:30, Yisheng Xie wrote:

quoted

On 2016/7/19 22:14, Vlastimil Babka wrote:

quoted

On 07/19/2016 03:48 PM, Xishi Qiu wrote:

[...]

quoted

quoted

quoted

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?

quoted

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@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>