Re: [PATCH 1/3] memcg kswapd thread pool (Was Re: [PATCH V6 00/10] memcg: per cgroup background reclaim

[KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>]

On Thu, 21 Apr 2011 00:09:13 -0700
Ying Han <yinghan@google.com> wrote:

> On Wed, Apr 20, 2011 at 8:43 PM, KAMEZAWA Hiroyuki <
> kamezawa.hiroyu@jp.fujitsu.com> wrote:
> 
> > Ying, please take this just a hint, you don't need to implement this as is.
> >
> 
> Thank you for the patch.
> 
> 
> > ==
> > 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.
> >
> > This patch does
> >
> >  - adds memcg-kswapd thread pool, the number of threads is now
> >   sqrt(num_of_cpus) + 1.
> >  - use unified kswapd_waitq for all memcgs.
> >
> 
> So I looked through the patch, it implements an alternative threading model
> using thread-pool. Also it includes some changes on calculating how much
> pages to reclaim per memcg. Other than that, all the existing implementation
> of per-memcg-kswapd seems not being impacted.
> 
> I tried to apply the patch but get some conflicts on vmscan.c/ I will try
> some manual work tomorrow. Meantime, after applying the patch, I will try to
> test it w/ the same test suite i used on original patch. AFAIK, the only
> difference of the two threading model is the amount of resources we consume
> on the kswapd kernel thread, which shouldn't have run-time performance
> differences.
> 

I hope so. 
To be honest, I don't like one-thread-per-one-job model because it's wastes
resouce and cache foot print and what we can do is just hoping schedulre
schedules tasks well. I like one-thread-per-mulutiple job and switching in
finer grain with knowledge of memory cgroup.

Thanks,
-Kame

--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>