linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@kernel.org>
To: Yisheng Xie <xieyisheng1@huawei.com>
Cc: Vlastimil Babka <vbabka@suse.cz>, Xishi Qiu <qiuxishi@huawei.com>,
	minchan@kernel.org, mgorman@suse.de, iamjoonsoo.kim@lge.com,
	mina86@mina86.com, Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>,
	cl@linux.com, David Rientjes <rientjes@google.com>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	Hanjun Guo <guohanjun@huawei.com>
Subject: Re: [Question]page allocation failure: order:2, mode:0x2000d1
Date: Wed, 20 Jul 2016 09:47:23 +0200	[thread overview]
Message-ID: <20160720074723.GA11256@dhcp22.suse.cz> (raw)
In-Reply-To: <7d9da183-38bf-96ef-a30c-db8b7dc9aafb@huawei.com>

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@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>

  reply	other threads:[~2016-07-20  7:47 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-19 12:43 [Question]page allocation failure: order:2, mode:0x2000d1 Yisheng Xie
2016-07-19 13:17 ` Vlastimil Babka
2016-07-19 13:48   ` Xishi Qiu
2016-07-19 14:14     ` Vlastimil Babka
2016-07-20  1:33       ` Yisheng Xie
2016-07-20  7:47         ` Michal Hocko [this message]
2016-07-28  7:50           ` Xishi Qiu
2016-07-28  8:10             ` Michal Hocko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160720074723.GA11256@dhcp22.suse.cz \
    --to=mhocko@kernel.org \
    --cc=cl@linux.com \
    --cc=guohanjun@huawei.com \
    --cc=iamjoonsoo.kim@lge.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@suse.de \
    --cc=mina86@mina86.com \
    --cc=minchan@kernel.org \
    --cc=n-horiguchi@ah.jp.nec.com \
    --cc=qiuxishi@huawei.com \
    --cc=rientjes@google.com \
    --cc=vbabka@suse.cz \
    --cc=xieyisheng1@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).