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

[David Rientjes <rientjes@google.com>]

On Thu, 21 Jun 2012, David Rientjes wrote:

> 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?
> 

The only other alternative that I can think of is to check 
mem_cgroup_margin() in isolate_migratepages_range() and return a NULL 
lruvec that would break that pageblock and return, and then set a bit in 
struct mem_cgroup that labels it as oom so we can check for it on 
subsequent pageblocks without incurring the locking to do 
mem_cgroup_margin() in res_counter, and then clear that bit on every 
uncharge to a memcg, but this still seems like a tremendous waste of cpu 
(especially if /sys/kernel/mm/transparent_hugepage/defrag == always) if 
most pageblocks contain pages from an oom memcg.

--
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>