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

On Thu 29-10-15 16:17:13, mho...@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 */ > +

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

On Thu 29-10-15 16:17:13, mho...@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 */ > +

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

> On Fri 30-10-15 09:36:26, Michal Hocko wrote: > > On Fri 30-10-15 12:10:15, Hillf Danton wrote: > > [...] > > > > + for_each_zone_zonelist_nodemask(zone, z, ac->zonelist, > > > > ac->high_zoneidx, ac->nodemask) { > > > > + unsigned long free = zone_page_state(zone, > > > >

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

On Fri 30-10-15 22:32:27, Tetsuo Handa wrote: > Michal Hocko wrote: > > + target -= (stall_backoff * target + MAX_STALL_BACKOFF - 1) / > > MAX_STALL_BACKOFF; > target -= DIV_ROUND_UP(stall_backoff * target, MAX_STALL_BACKOFF); Ohh, we have a macro for that. Good to know. Thanks. It

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

Michal Hocko wrote: > + target -= (stall_backoff * target + MAX_STALL_BACKOFF - 1) / > MAX_STALL_BACKOFF; target -= DIV_ROUND_UP(stall_backoff * target, MAX_STALL_BACKOFF); Michal Hocko wrote: > This alone wouldn't be sufficient, though, because the writeback might > get stuck and

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

On Fri 30-10-15 18:41:30, KAMEZAWA Hiroyuki wrote: [...] > >>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

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

On Fri 30-10-15 09:36:26, Michal Hocko wrote: > On Fri 30-10-15 12:10:15, Hillf Danton wrote: > [...] > > > + for_each_zone_zonelist_nodemask(zone, z, ac->zonelist, > > > ac->high_zoneidx, ac->nodemask) { > > > + unsigned long free = zone_page_state(zone, NR_FREE_PAGES); > > > +

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

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, mho...@kernel.org wrote: [...] @@ -3135,13 +3145,56 @@ __alloc_pages_slowpath(gfp_t gfp_mask, unsigned int order, if (gfp_mask & __GFP_NORETRY) goto

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

On Fri 30-10-15 12:10:15, Hillf Danton wrote: [...] > > + for_each_zone_zonelist_nodemask(zone, z, ac->zonelist, > > ac->high_zoneidx, ac->nodemask) { > > + unsigned long free = zone_page_state(zone, NR_FREE_PAGES); > > + unsigned long reclaimable; > > + unsigned

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

On Fri 30-10-15 14:23:59, KAMEZAWA Hiroyuki wrote: > On 2015/10/30 0:17, mho...@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

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

On Fri 30-10-15 14:23:59, KAMEZAWA Hiroyuki wrote: > On 2015/10/30 0:17, mho...@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

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

On Fri 30-10-15 12:10:15, Hillf Danton wrote: [...] > > + for_each_zone_zonelist_nodemask(zone, z, ac->zonelist, > > ac->high_zoneidx, ac->nodemask) { > > + unsigned long free = zone_page_state(zone, NR_FREE_PAGES); > > + unsigned long reclaimable; > > + unsigned

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

On Fri 30-10-15 09:36:26, Michal Hocko wrote: > On Fri 30-10-15 12:10:15, Hillf Danton wrote: > [...] > > > + for_each_zone_zonelist_nodemask(zone, z, ac->zonelist, > > > ac->high_zoneidx, ac->nodemask) { > > > + unsigned long free = zone_page_state(zone, NR_FREE_PAGES); > > > +

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

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, mho...@kernel.org wrote: [...] @@ -3135,13 +3145,56 @@ __alloc_pages_slowpath(gfp_t gfp_mask, unsigned int order, if (gfp_mask & __GFP_NORETRY) goto

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

> On Fri 30-10-15 09:36:26, Michal Hocko wrote: > > On Fri 30-10-15 12:10:15, Hillf Danton wrote: > > [...] > > > > + for_each_zone_zonelist_nodemask(zone, z, ac->zonelist, > > > > ac->high_zoneidx, ac->nodemask) { > > > > + unsigned long free = zone_page_state(zone, > > > >

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

Michal Hocko wrote: > + target -= (stall_backoff * target + MAX_STALL_BACKOFF - 1) / > MAX_STALL_BACKOFF; target -= DIV_ROUND_UP(stall_backoff * target, MAX_STALL_BACKOFF); Michal Hocko wrote: > This alone wouldn't be sufficient, though, because the writeback might > get stuck and

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

On Fri 30-10-15 22:32:27, Tetsuo Handa wrote: > Michal Hocko wrote: > > + target -= (stall_backoff * target + MAX_STALL_BACKOFF - 1) / > > MAX_STALL_BACKOFF; > target -= DIV_ROUND_UP(stall_backoff * target, MAX_STALL_BACKOFF); Ohh, we have a macro for that. Good to know. Thanks. It

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

On Fri 30-10-15 18:41:30, KAMEZAWA Hiroyuki wrote: [...] > >>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

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

On 2015/10/30 0:17, mho...@kernel.org wrote: > From: Michal Hocko > > __alloc_pages_slowpath has traditionally relied on the direct reclaim > and did_some_progress as an indicator that it makes sense to retry > allocation rather than declaring OOM. shrink_zones had to rely on > zone_reclaimable

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

> +/* > + * Number of backoff steps for potentially reclaimable pages if the direct > reclaim > + * cannot make any progress. Each step will reduce 1/MAX_STALL_BACKOFF of the > + * reclaimable memory. > + */ > +#define MAX_STALL_BACKOFF 16 > + > static inline struct page * >

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

From: Michal Hocko __alloc_pages_slowpath has traditionally relied on the direct reclaim and did_some_progress as an indicator that it makes sense to retry allocation rather than declaring OOM. shrink_zones had to rely on zone_reclaimable if shrink_zone didn't make any progress to prevent from

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

From: Michal Hocko __alloc_pages_slowpath has traditionally relied on the direct reclaim and did_some_progress as an indicator that it makes sense to retry allocation rather than declaring OOM. shrink_zones had to rely on zone_reclaimable if shrink_zone didn't make any progress

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

> +/* > + * Number of backoff steps for potentially reclaimable pages if the direct > reclaim > + * cannot make any progress. Each step will reduce 1/MAX_STALL_BACKOFF of the > + * reclaimable memory. > + */ > +#define MAX_STALL_BACKOFF 16 > + > static inline struct page * >

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

On 2015/10/30 0:17, mho...@kernel.org wrote: > From: Michal Hocko > > __alloc_pages_slowpath has traditionally relied on the direct reclaim > and did_some_progress as an indicator that it makes sense to retry > allocation rather than declaring OOM. shrink_zones had to rely on >