Re: [Question]page allocation failure: order:2, mode:0x2000d1

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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?

> Another question is why it will do retry here, for it will goto out
> with did_some_progress=0 ?
> 
>              if (!did_some_progress)
>                  goto nopage;

Do you mean:
                /*
                 * If we fail to make progress by freeing individual
                 * pages, but the allocation wants us to keep going,
                 * start OOM killing tasks.
                 */
                if (!did_some_progress) {
                        page = __alloc_pages_may_oom(gfp_mask, order, ac,
                                                        &did_some_progress);
                        if (page)
                                goto got_pg;
                        if (!did_some_progress)
                                goto nopage;
                }

If yes then this code simply tells that if even oom path didn't make any
progress then we should fail. As DMA request doesn't invoke OOM killer
because it is effectively a lowmem request (see above check pointed
by Vlastimil) then the OOM path couldn't make any progress and we are
failing. If invoked the OOM killer then we would consider this as a
forward progress and retry the allocation request.
-- 
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>



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]