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

Groups > linux.kernel > #1259316

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

Show all headers | View raw

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 long target;
> > +
> > +		reclaimable = zone_reclaimable_pages(zone) +
> > +			      zone_page_state(zone, NR_ISOLATED_FILE) +
> > +			      zone_page_state(zone, NR_ISOLATED_ANON);
> > +		target = reclaimable;
> > +		target -= stall_backoff * (1 + target/MAX_STALL_BACKOFF);
> 
> 		target = reclaimable - stall_backoff * (1 + target/MAX_STALL_BACKOFF);
> 		             = reclaimable - stall_backoff - stall_backoff  * (target/MAX_STALL_BACKOFF);
> 
> then the first stall_backoff looks unreasonable.

First stall_backoff is off by 1 but that shouldn't make any difference.

> I guess you mean
> 		target	= reclaimable - target * (stall_backoff/MAX_STALL_BACKOFF);
> 			= reclaimable - stall_back * (target/MAX_STALL_BACKOFF);

No the reason I used the bias is to converge for MAX_STALL_BACKOFF. If
you have target which is not divisible by MAX_STALL_BACKOFF then the
rounding would get target > 0 and so we wouldn't converge. With the +1
you underflow which is MAX_STALL_BACKOFF in maximum which should be
fixed up by the free memory. Maybe a check for free < MAX_STALL_BACKOFF
would be good but I didn't get that far with this.

[...]

> /*
> > @@ -2734,10 +2730,6 @@ static unsigned long do_try_to_free_pages(struct zonelist *zonelist,
> >  		goto retry;
> >  	}
> > 
> > -	/* Any of the zones still reclaimable?  Don't OOM. */
> > -	if (zones_reclaimable)
> > -		return 1;
> > -
> 
> Looks cleanup of zones_reclaimable left.

Removed. Thanks!

-- 
Michal Hocko
SUSE Labs
--
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