lkml.org 
[lkml]   [2015]   [Oct]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [RFC 1/3] mm, oom: refactor oom detection
From
Date
On 2015/10/30 17:23, Michal Hocko wrote:
> On Fri 30-10-15 14:23:59, KAMEZAWA Hiroyuki wrote:
>> On 2015/10/30 0:17, mhocko@kernel.org wrote:
> [...]
>>> @@ -3135,13 +3145,56 @@ __alloc_pages_slowpath(gfp_t gfp_mask, unsigned int order,
>>> if (gfp_mask & __GFP_NORETRY)
>>> goto noretry;
>>>
>>> - /* Keep reclaiming pages as long as there is reasonable progress */
>>> + /*
>>> + * Do not retry high order allocations unless they are __GFP_REPEAT
>>> + * and even then do not retry endlessly.
>>> + */
>>> pages_reclaimed += did_some_progress;
>>> - if ((did_some_progress && order <= PAGE_ALLOC_COSTLY_ORDER) ||
>>> - ((gfp_mask & __GFP_REPEAT) && pages_reclaimed < (1 << order))) {
>>> - /* Wait for some write requests to complete then retry */
>>> - wait_iff_congested(ac->preferred_zone, BLK_RW_ASYNC, HZ/50);
>>> - goto retry;
>>> + if (order > PAGE_ALLOC_COSTLY_ORDER) {
>>> + if (!(gfp_mask & __GFP_REPEAT) || pages_reclaimed >= (1<<order))
>>> + goto noretry;
>>> +
>>> + if (did_some_progress)
>>> + goto retry;
>>
>> why directly retry here ?
>
> Because I wanted to preserve the previous logic for GFP_REPEAT as much
> as possible here and do an incremental change in the later patch.
>

I see.

> [...]
>
>>> @@ -3150,8 +3203,10 @@ __alloc_pages_slowpath(gfp_t gfp_mask, unsigned int order,
>>> goto got_pg;
>>>
>>> /* Retry as long as the OOM killer is making progress */
>>> - if (did_some_progress)
>>> + if (did_some_progress) {
>>> + stall_backoff = 0;
>>> goto retry;
>>> + }
>>
>> Umm ? I'm sorry that I didn't notice page allocation may fail even
>> if order < PAGE_ALLOC_COSTLY_ORDER. I thought old logic ignores
>> did_some_progress. It seems a big change.
>
> __alloc_pages_may_oom will set did_some_progress
>
>> So, now, 0-order page allocation may fail in a OOM situation ?
>
> No they don't normally and this patch doesn't change the logic here.
>

I understand your patch doesn't change the behavior.
Looking into __alloc_pages_may_oom(), *did_some_progress is finally set by

if (out_of_memory(&oc) || WARN_ON_ONCE(gfp_mask & __GFP_NOFAIL))
*did_some_progress = 1;

...depends on out_of_memory() return value.
Now, allocation may fail if oom-killer is disabled.... Isn't it complicated ?

Shouldn't we have

if (order < PAGE_ALLOC_COSTLY_ORDER)
goto retry;

here ?

Thanks,
-Kame








\
 
 \ /
  Last update: 2015-10-30 11:01    [W:0.050 / U:1.156 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site