On Tue, Apr 26, 2011 at 1:47 AM, KAMEZAWA Hiroyuki <kamezawa.hiroyu@xxxxxxxxxxxxxx> wrote:
On Tue, 26 Apr 2011 01:43:17 -0700
Ying Han <yinghan@xxxxxxxxxx> wrote:
> On Tue, Apr 26, 2011 at 12:43 AM, KAMEZAWA Hiroyuki <
> kamezawa.hiroyu@xxxxxxxxxxxxxx> wrote:
>
> > On Tue, 26 Apr 2011 00:19:46 -0700
> > Ying Han <yinghan@xxxxxxxxxx> wrote:
> >
> > > On Mon, Apr 25, 2011 at 6:38 PM, KAMEZAWA Hiroyuki
> > > <kamezawa.hiroyu@xxxxxxxxxxxxxx> wrote:
> > > > On Mon, 25 Apr 2011 15:21:21 -0700
> > > > Ying Han <yinghan@xxxxxxxxxx> wrote:
>
> > To clarify a bit, my question was meant to account it but not necessary toHm ? statistics of elapsed_time isn't enough ?
> > 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.
>
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