On Thu, Apr 21, 2011 at 9:36 PM, KAMEZAWA Hiroyuki <
kamezawa.hiroyu@jp.fujitsu.com> wrote:

> On Thu, 21 Apr 2011 21:24:15 -0700
> Ying Han <yinghan@google.com> wrote:
>
> > 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.
> >
> > The concern of using per-memcg-kswapd thread is the system overhead
> including
> > memory and cputime.
> >
> > Signed-off-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
> > Signed-off-by: Ying Han <yinghan@google.com>
>
> Thank you for merging. This seems ok to me.
>
> Further development may make this better or change thread pools (to some
> other),
> but I think this is enough good.
>

Thank you for reviewing and Acking. At the same time, I do have wondering on
the thread-pool modeling which I posted on the cover-letter :)

The per-memcg-per-kswapd model
Pros:
1. memory overhead per thread, and The memory consumption would be 8k*1000 =
8M
with 1k cgroup.
2. we see lots of threads at 'ps -elf'

Cons:
1. the implementation is simply and straigh-forward.
2. we can easily isolate the background reclaim overhead between cgroups.
3. better latency from memory pressure to actual start reclaiming

The thread-pool model
Pros:
1. there is no isolation between memcg background reclaim, since the memcg
threads
are shared.
2. it is hard for visibility and debugability. I have been experienced a lot
when
some kswapds running creazy and we need a stright-forward way to identify
which
cgroup causing the reclaim.
3. potential starvation for some memcgs, if one workitem stucks and the rest
of work
won't proceed.

Cons:
1. save some memory resource.

In general, the per-memcg-per-kswapd implmentation looks sane to me at this
point, esepcially the sharing memcg thread model will make debugging issue
very hard later.

Comments?

--Ying