linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Xishi Qiu <qiuxishi@huawei.com>
To: Michal Hocko <mhocko@kernel.org>
Cc: Yisheng Xie <xieyisheng1@huawei.com>,
	Vlastimil Babka <vbabka@suse.cz>,
	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: Thu, 28 Jul 2016 15:50:32 +0800	[thread overview]
Message-ID: <5799B948.6080308@huawei.com> (raw)
In-Reply-To: <20160720074723.GA11256@dhcp22.suse.cz>

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)

Thanks,
Xishi Qiu

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



--
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-28  8:01 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
2016-07-28  7:50           ` Xishi Qiu [this message]
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=5799B948.6080308@huawei.com \
    --to=qiuxishi@huawei.com \
    --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=mhocko@kernel.org \
    --cc=mina86@mina86.com \
    --cc=minchan@kernel.org \
    --cc=n-horiguchi@ah.jp.nec.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).