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

David Rientjes
2012-06-21T08:30:54Z

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?