On Tue, Apr 26, 2011 at 1:47 AM, KAMEZAWA Hiroyuki < kamezawa.hiroyu@jp.fujitsu.com> wrote: > On Tue, 26 Apr 2011 01:43:17 -0700 > Ying Han wrote: > > > On Tue, Apr 26, 2011 at 12:43 AM, KAMEZAWA Hiroyuki < > > kamezawa.hiroyu@jp.fujitsu.com> wrote: > > > > > On Tue, 26 Apr 2011 00:19:46 -0700 > > > Ying Han wrote: > > > > > > > On Mon, Apr 25, 2011 at 6:38 PM, KAMEZAWA Hiroyuki > > > > wrote: > > > > > On Mon, 25 Apr 2011 15:21:21 -0700 > > > > > Ying Han wrote: > > > > > > To clarify a bit, my question was meant to account it but not necessary > to > > > limit it. We can use existing cpu cgroup to do the cpu limiting, and I > am > > > > > just wondering how to configure it for the memcg kswapd thread. > > > > Let's say in the per-memcg-kswapd model, i can echo the kswapd thread > pid > > into the cpu cgroup ( the same set of process of memcg, but in a cpu > > limiting cgroup instead). If the kswapd is shared, we might need extra > work > > to account the cpu cycles correspondingly. > > > > Hm ? statistics of elapsed_time isn't enough ? > I think the stats works for cpu-charging, although we might need to do extra work to account them for each work item and also charge them to the cpu cgroup. But it should work for now. > > Now, I think limiting scan/sec interface is more promissing rather than > time > or thread controls. It's easier to understand. Adding monitoring stats is good to start with, like what you have on the last patch. > BTW, I think it's better to avoid the watermark reclaim work as kswapd. > It's confusing because we've talked about global reclaim at LSF. > Can you clarify that? --Ying > > > Thanks, > -Kame > >