Re: [PATCH 0/7] memcg background reclaim , yet another one.

[Ying Han <yinghan@google.com>]

[-- Attachment #1: Type: text/plain, Size: 1766 bytes --]

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 <yinghan@google.com> 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 <yinghan@google.com> wrote:
> > >
> > > > On Mon, Apr 25, 2011 at 6:38 PM, KAMEZAWA Hiroyuki
> > > > <kamezawa.hiroyu@jp.fujitsu.com> wrote:
> > > > > On Mon, 25 Apr 2011 15:21:21 -0700
> > > > > Ying Han <yinghan@google.com> 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
>
>

[-- Attachment #2: Type: text/html, Size: 3010 bytes --]