Re: Fw: [PATCH] memcg: add reclaim statistics accounting

[Ying Han <yinghan@google.com>]

On Wed, Apr 27, 2011 at 8:57 PM, KAMEZAWA Hiroyuki
<kamezawa.hiroyu@jp.fujitsu.com> wrote:
> On Wed, 27 Apr 2011 20:43:58 -0700
> Ying Han <yinghan@google.com> wrote:
>
>> On Wed, Apr 27, 2011 at 8:16 PM, KAMEZAWA Hiroyuki
>> <kamezawa.hiroyu@jp.fujitsu.com> wrote:
>> > sorry, I had wrong TO:...
>> >
>> > Begin forwarded message:
>> >
>> > Date: Thu, 28 Apr 2011 12:02:34 +0900
>> > From: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
>> > To: linux-mm@vger.kernel.org
>> > Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "nishimura@mxp.nes.nec.co.jp" <nishimura@mxp.nes.nec.co.jp>, "balbir@linux.vnet.ibm.com" <balbir@linux.vnet.ibm.com>, Ying Han <yinghan@google.com>, "akpm@linux-foundation.org" <akpm@linux-foundation.org>
>> > Subject: [PATCH] memcg: add reclaim statistics accounting
>> >
>> >
>> >
>> > Now, memory cgroup provides poor reclaim statistics per memcg. This
>> > patch adds statistics for direct/soft reclaim as the number of
>> > pages scans, the number of page freed by reclaim, the nanoseconds of
>> > latency at reclaim.
>> >
>> > It's good to add statistics before we modify memcg/global reclaim, largely.
>> > This patch refactors current soft limit status and add an unified update logic.
>> >
>> > For example, After #cat 195Mfile > /dev/null under 100M limit.
>> >        # cat /cgroup/memory/A/memory.stat
>> >        ....
>> >        limit_freed 24592
>>
>> why not "limit_steal" ?
>>
>
> It's not "stealed". Freed by itself.
> pages reclaimed by soft-limit is stealed because of global memory pressure.
> I don't like the name "steal" but I can't change it because of API breakage.
>
>
>> >        soft_steal 0
>> >        limit_scan 43974
>> >        soft_scan 0
>> >        limit_latency 133837417
>> >
>> > nearly 96M caches are freed. scanned twice. used 133ms.
>>
>> Does it make sense to split up the soft_steal/scan for bg reclaim and
>> direct reclaim?
>
> Please clarify what you're talking about before asking. Maybe you want to say
> "I'm now working for supporting softlimit in direct reclaim path. So, does
>  it make sense to account direct/kswapd works in statistics ?"
>
> I think bg/direct reclaim is not required to be splitted.

Ok, thanks for the clarification. The patch i am working now to be
more specific is to add the
soft_limit hierarchical reclaim on the global direct reclaim.

I am adding similar stats to monitor the soft_steal, but i split-off
the soft_steal from global direct reclaim and
global background reclaim. I am wondering isn't that give us more
visibility of the reclaim path?

>
>> The same for the limit_steal/scan.
>
> limit has only direct reclaim, now. And this is independent from any
> soft limit works.

agree.

>
>> I am now testing
>> the patch to add the soft_limit reclaim on global ttfp, and i already
>> have the patch to add the following:
>>
>> kswapd_soft_steal 0
>> kswapd_soft_scan 0
>
> please don't change the name of _used_ statisitcs.

good point. thanks

>
>
>> direct_soft_steal 0
>> direct_soft_scan 0
>
> Maybe these are new ones added by your work. But should be merged to
> soft_steal/soft_scan.
the same question above, why we don't want to have better visibility
of where we triggered
the soft_limit reclaim and how much has been done on behalf of each.

>
>> kswapd_steal 0
>> pg_pgsteal 0
>> kswapd_pgscan 0
>> pg_scan 0
>>
>
> Maybe this indicates reclaimed-by-other-tasks-than-this-memcg. Right ?
> Maybe good for checking isolation of memcg, hmm, can these be accounted
> in scalable way ?

you can ignore those four stats. They are part of the per-memcg-kswapd
patchset, and i guess you might
have similar patch for that purpose.

>
> BTW, my office will be closed for a week because of holidays. So, I'll not make
> responce tomorrow. please CC kamezawa.hiroyuki@gmail.com if you need.
> I may read e-mails.

Thanks for the heads up ~

--Ying

>
> Thanks,
> -Kame
>
>
>
>

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>