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:	Thu, 25 Feb 2016 10:27:40 +0100
From:	Michal Hocko <mhocko@...nel.org>
To:	Hillf Danton <hillf.zj@...baba-inc.com>
Cc:	'Sergey Senozhatsky' <sergey.senozhatsky.work@...il.com>,
	'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@...il.com>
Subject: Re: [PATCH 0/3] OOM detection rework v4

On Thu 25-02-16 17:17:45, Hillf Danton wrote:
[...]
> > OOM example:
> > 
> > [ 2392.663170] zram-test.sh invoked oom-killer: gfp_mask=0x27000c0(GFP_KERNEL_ACCOUNT|__GFP_NOTRACK), order=2,  oom_score_adj=0
[...]
> > [ 2392.663260] DMA: 4*4kB (M) 1*8kB (M) 4*16kB (ME) 1*32kB (M) 2*64kB (UE) 2*128kB (UE) 3*256kB (UME) 3*512kB (UME) 2*1024kB (ME) 1*2048kB (E) 2*4096kB (M) = 15096kB
> > [ 2392.663284] DMA32: 5809*4kB (UME) 3*8kB (M) 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 23260kB
> > [ 2392.663293] Normal: 1515*4kB (UME) 0*8kB 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 6060kB

[...]
> > [ 2400.152464] zram-test.sh invoked oom-killer: gfp_mask=0x27000c0(GFP_KERNEL_ACCOUNT|__GFP_NOTRACK), order=2, oom_score_adj=0
[...]
> > [ 2400.152558] DMA: 4*4kB (M) 1*8kB (M) 4*16kB (ME) 1*32kB (M) 2*64kB (UE) 2*128kB (UE) 3*256kB (UME) 3*512kB (UME)  2*1024kB (ME) 1*2048kB (E) 2*4096kB (M) = 15096kB
> > [ 2400.152573] DMA32: 7835*4kB (UME) 55*8kB (M) 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 31780kB
> > [ 2400.152582] Normal: 1383*4kB (UM) 22*8kB (UM) 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB =  5708kB
[...]
> Thanks for your info.
> 
> Can you please schedule a run for the diff attached, in which 
> non-expensive allocators are allowed to burn more CPU cycles.

I do not think your patch will help. As you can see, both OOMs were for
order-2 and there simply are no order-2+ free blocks usable for the
allocation request so the watermark check will fail for all eligible
zones and no_progress_loops is simply ignored. This is what I've tried
to address by patch I have just posted as a reply to Hugh's email
http://lkml.kernel.org/r/20160225092315.GD17573@dhcp22.suse.cz

> --- a/mm/page_alloc.c	Thu Feb 25 15:43:18 2016
> +++ b/mm/page_alloc.c	Thu Feb 25 16:46:05 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)
> +		no_progress_loops /= 2;
>  	/*
>  	 * Make sure we converge to OOM if we cannot make any progress
>  	 * several times in the row.
-- 
Michal Hocko
SUSE Labs