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@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>