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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]