Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1451777 > unrolled thread

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

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [Question]page allocation failure: order:2, mode:0x2000d1 Xishi Qiu <qiuxishi@huawei.com> - 2016-07-28 10:00 +0200
    Re: [Question]page allocation failure: order:2, mode:0x2000d1 Michal Hocko <mhocko@kernel.org> - 2016-07-28 10:20 +0200

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

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.

[toc] | [next] | [standalone]

#1451787

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

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web