On Thu, Apr 21, 2011 at 9:36 PM, KAMEZAWA Hiroyuki <kamezawa.hiroyu@xxxxxxxxxxxxxx> wrote:
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.
On Thu, 21 Apr 2011 21:24:15 -0700Thank you for merging. This seems ok to me.
Ying Han <yinghan@xxxxxxxxxx> 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@xxxxxxxxxxxxxx>
> Signed-off-by: Ying Han <yinghan@xxxxxxxxxx>
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 :)
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