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]
Message-ID: <20160510094448.GI23576@dhcp22.suse.cz>
Date:	Tue, 10 May 2016 11:44:48 +0200
From:	Michal Hocko <mhocko@...nel.org>
To:	Joonsoo Kim <js1304@...il.com>
Cc:	Vlastimil Babka <vbabka@...e.cz>,
	Joonsoo Kim <iamjoonsoo.kim@....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>,
	Hillf Danton <hillf.zj@...baba-inc.com>,
	Linux Memory Management List <linux-mm@...ck.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 0.14] oom detection rework v6

On Tue 10-05-16 17:00:08, Joonsoo Kim wrote:
> 2016-05-10 16:09 GMT+09:00 Vlastimil Babka <vbabka@...e.cz>:
> > On 05/10/2016 08:41 AM, Joonsoo Kim wrote:
> >>
> >> You applied band-aid for CONFIG_COMPACTION and fixed some reported
> >> problem but it is also fragile. Assume almost pageblock's skipbit are
> >> set. In this case, compaction easily returns COMPACT_COMPLETE and your
> >> logic will stop retry. Compaction isn't designed to report accurate
> >> fragmentation state of the system so depending on it's return value
> >> for OOM is fragile.
> >
> >
> > Guess I'll just post a RFC now, even though it's not much tested...
> 
> I will look at it later. But, I'd like to say something first.
> Even if compaction returns more accurate fragmentation states, it's not a good
> idea to depend on compaction's result to decide OOM. We have reclaimable but
> not migratable pages. Depending on compaction's result cannot deal
> with this case.
> 
> For example, please assume that all of the system memory are filled
> with THP pages
> or reclaimable slab pages. They cannot be migrated but we can reclaim them.

Direct reclaim should break those THP pages or shrink those slabs. And
we make sure to reclaim before we consider final call for fail from
compaction feedback. If this is a vast majority of memory we should hit
it pretty reliably AFAICS.
-- 
Michal Hocko
SUSE Labs

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ