linux-kernel - Re: [PATCH 0/3] OOM detection rework v4

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 26 Feb 2016 14:49:20 +0100
From:	Michal Hocko <mhocko@...nel.org>
To:	Hillf Danton <hillf.zj@...baba-inc.com>
Cc:	'Hugh Dickins' <hughd@...gle.com>,
	'Andrew Morton' <akpm@...ux-foundation.org>,
	'Linus Torvalds' <torvalds@...ux-foundation.org>,
	'Johannes Weiner' <hannes@...xchg.org>,
	'Mel Gorman' <mgorman@...e.de>,
	'David Rientjes' <rientjes@...gle.com>,
	'Tetsuo Handa' <penguin-kernel@...ove.sakura.ne.jp>,
	'KAMEZAWA Hiroyuki' <kamezawa.hiroyu@...fujitsu.com>,
	linux-mm@...ck.org, 'LKML' <linux-kernel@...r.kernel.org>,
	'Sergey Senozhatsky' <sergey.senozhatsky.work@...il.com>
Subject: Re: [PATCH 0/3] OOM detection rework v4

On Fri 26-02-16 18:27:16, Hillf Danton wrote:
> >> 
> > > --- a/mm/page_alloc.c	Thu Feb 25 15:43:18 2016
> > > +++ b/mm/page_alloc.c	Fri Feb 26 15:18:55 2016
> > > @@ -3113,6 +3113,8 @@ should_reclaim_retry(gfp_t gfp_mask, uns
> > >  	struct zone *zone;
> > >  	struct zoneref *z;
> > >
> > > +	if (order <= PAGE_ALLOC_COSTLY_ORDER)
> > > +		return true;
> > 
> > This is defeating the whole purpose of the rework - to behave
> > deterministically. You have just disabled the oom killer completely.
> > This is not the way to go
> > 
> Then in another direction, below is what I can do.
> 
> thanks
> Hillf
> --- a/mm/page_alloc.c	Thu Feb 25 15:43:18 2016
> +++ b/mm/page_alloc.c	Fri Feb 26 18:14:59 2016
> @@ -3366,8 +3366,11 @@ retry:
>  		no_progress_loops++;
>  
>  	if (should_reclaim_retry(gfp_mask, order, ac, alloc_flags,
> -				 did_some_progress > 0, no_progress_loops))
> +				 did_some_progress > 0, no_progress_loops)) {
> +		/* Burn more cycles if any zone seems to satisfy our request */
> +		no_progress_loops /= 2;

No, I do not think this makes any sense. If we need more retry loops
then we can do it by increasing MAX_RECLAIM_RETRIES.

>  		goto retry;
> +	}
>  
>  	/* Reclaim has failed us, start killing things */
>  	page = __alloc_pages_may_oom(gfp_mask, order, ac, &did_some_progress);

-- 
Michal Hocko
SUSE Labs