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

Groups > linux.kernel > #1259362

Re: [RFC 1/3] mm, oom: refactor oom detection

Show all headers | View raw

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






--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

RFC: OOM detection rework v1 mhocko@kernel.org - 2015-10-29 16:20 +0100
  [RFC 3/3] mm: use watermak checks for __GFP_REPEAT high order allocations mhocko@kernel.org - 2015-10-29 16:20 +0100
  [RFC 1/3] mm, oom: refactor oom detection mhocko@kernel.org - 2015-10-29 16:20 +0100
    Re: [RFC 1/3] mm, oom: refactor oom detection "Hillf Danton" <hillf.zj@alibaba-inc.com> - 2015-10-30 05:20 +0100
      Re: [RFC 1/3] mm, oom: refactor oom detection Michal Hocko <mhocko@kernel.org> - 2015-10-30 09:40 +0100
        Re: [RFC 1/3] mm, oom: refactor oom detection Michal Hocko <mhocko@kernel.org> - 2015-10-30 11:20 +0100
          Re: [RFC 1/3] mm, oom: refactor oom detection Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> - 2015-10-30 14:40 +0100
            Re: [RFC 1/3] mm, oom: refactor oom detection Michal Hocko <mhocko@kernel.org> - 2015-10-30 16:00 +0100
          Re: [RFC 1/3] mm, oom: refactor oom detection "Hillf Danton" <hillf.zj@alibaba-inc.com> - 2015-10-31 05:00 +0100
    Re: [RFC 1/3] mm, oom: refactor oom detection Kamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> - 2015-10-30 06:30 +0100
      Re: [RFC 1/3] mm, oom: refactor oom detection Michal Hocko <mhocko@kernel.org> - 2015-10-30 09:30 +0100
        Re: [RFC 1/3] mm, oom: refactor oom detection Kamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> - 2015-10-30 10:50 +0100
          Re: [RFC 1/3] mm, oom: refactor oom detection Michal Hocko <mhocko@kernel.org> - 2015-10-30 11:20 +0100
  [RFC 2/3] mm: throttle on IO only when there are too many dirty and writeback pages mhocko@kernel.org - 2015-10-29 16:20 +0100
    Re: [RFC 2/3] mm: throttle on IO only when there are too many dirty and writeback pages "Hillf Danton" <hillf.zj@alibaba-inc.com> - 2015-10-30 05:30 +0100
      Re: [RFC 2/3] mm: throttle on IO only when there are too many dirty  and writeback pages Michal Hocko <mhocko@kernel.org> - 2015-10-30 09:40 +0100
    Re: [RFC 2/3] mm: throttle on IO only when there are too many dirty  and writeback pages Kamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> - 2015-10-30 06:50 +0100
      Re: [RFC 2/3] mm: throttle on IO only when there are too many dirty  and writeback pages Michal Hocko <mhocko@kernel.org> - 2015-10-30 09:40 +0100

csiph-web