linux-kernel - Re: [patch] mm, thp: abort compaction if migration page cannot be charged to memcg

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, 21 Jun 2012 01:30:47 -0700 (PDT)
From:	David Rientjes <rientjes@...gle.com>
To:	Minchan Kim <minchan@...nel.org>
cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Mel Gorman <mgorman@...e.de>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
	Rik van Riel <riel@...hat.com>, linux-kernel@...r.kernel.org,
	linux-mm@...ck.org
Subject: Re: [patch] mm, thp: abort compaction if migration page cannot be
 charged to memcg

On Thu, 21 Jun 2012, Minchan Kim wrote:

> > If page migration cannot charge the new page to the memcg,
> > migrate_pages() will return -ENOMEM.  This isn't considered in memory
> > compaction however, and the loop continues to iterate over all pageblocks
> > trying in a futile attempt to continue migrations which are only bound to
> > fail.
> 
> 
> Hmm, it might be dumb question.
> I imagine that pages in next pageblock could be in another memcg so it could be successful.
> Why should we stop compaction once it fails to migrate pages in current pageblock/memcg?
> 

 [ You included the gmane.linux.kernel and gmane.linux.kernel.mm
   newsgroups in your reply, not sure why, so I removed them. ]

This was inspired by a system running with a single oom memcg running with 
thp that continuously tried migrating pages resulting in vmstats such as 
this:

compact_blocks_moved 59473599
compact_pages_moved 50041548
compact_pagemigrate_failed 1494277831
compact_stall 1013
compact_fail 573

Obviously not a good result.

We could certainly continue the iteration in cases like this, but I 
thought it would be better to fail and rely on direct reclaim to actually 
try to free some memory, especially if that oom memcg happens to include 
current.

It's possible that subsequent pageblocks would contain memory allocated 
from solely non-oom memcgs, but it's certainly not a guarantee and results 
in terrible performance as exhibited above.  Is there another good 
criteria to use when deciding when to stop isolating and attempting to 
migrate all of these pageblocks?

Other ideas?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/