Messages in this thread | | | Subject | Re: [RFC 1/3] mm, oom: refactor oom detection | From | Kamezawa Hiroyuki <> | Date | Fri, 30 Oct 2015 18:41:30 +0900 |
| |
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
| |