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

[David Rientjes <rientjes@google.com>]

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, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>