Hi Kame, On Thu, Apr 21, 2011 at 12:43 PM, KAMEZAWA Hiroyuki <kamezawa.hiroyu@xxxxxxxxxxxxxx> wrote: > Ying, please take this just a hint, you don't need to implement this as is. > == > Now, memcg-kswapd is created per a cgroup. Considering there are users > who creates hundreds on cgroup on a system, it consumes too much > resources, memory, cputime. > > This patch creates a thread pool for memcg-kswapd. All memcg which > needs background recalim are linked to a list and memcg-kswapd > picks up a memcg from the list and run reclaim. This reclaimes > SWAP_CLUSTER_MAX of pages and putback the memcg to the lail of > list. memcg-kswapd will visit memcgs in round-robin manner and > reduce usages. > I didn't look at code yet but as I just look over the description, I have a concern. We have discussed LRU separation between global and memcg. The clear goal is that how to keep _fairness_. For example, memcg-1 : # pages of LRU : 64 memcg-2 : # pages of LRU : 128 memcg-3 : # pages of LRU : 256 If we have to reclaim 96 pages, memcg-1 would be lost half of pages. It's much greater than others so memcg 1's page LRU rotation cycle would be very fast, then working set pages in memcg-1 don't have a chance to promote. Is it fair? I think we should consider memcg-LRU size as doing round-robin. Thanks. -- Kind regards, Minchan Kim -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxxx For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>