Re: [patch] Revert "memcg: add memory.vmscan_stat"

KAMEZAWA Hiroyuki
2011-08-31T06:38:11Z

On Wed, 31 Aug 2011 08:23:54 +0200
Johannes Weiner <jweiner@redhat.com> wrote:

> On Wed, Aug 31, 2011 at 08:29:24AM +0900, KAMEZAWA Hiroyuki wrote:
> > On Tue, 30 Aug 2011 13:32:21 +0200
> > Johannes Weiner <jweiner@redhat.com> wrote:
> >
> > > On Tue, Aug 30, 2011 at 07:38:39PM +0900, KAMEZAWA Hiroyuki wrote:
> > > > On Tue, 30 Aug 2011 12:17:26 +0200
> > > > Johannes Weiner <jweiner@redhat.com> wrote:
> > > >
> > > > > On Tue, Aug 30, 2011 at 05:56:09PM +0900, KAMEZAWA Hiroyuki wrote:
> > > > > > On Tue, 30 Aug 2011 10:42:45 +0200
> > > > > > Johannes Weiner <jweiner@redhat.com> wrote:
>
> > I'm confused.
> >
> > If vmscan is scanning in C's LRU,
> > (memcg == root) : C_scan_internal ++
> > (memcg != root) : C_scan_external ++
>
> Yes.
>
> > Why A_scan_external exists ? It's 0 ?
> >
> > I think we can never get numbers.
>
> Kswapd/direct reclaim should probably be accounted as A_external,
> since A has no limit, so reclaim pressure can not be internal.
>

hmm, ok. All memory pressure from memcg/system other than the memcg itsef
is all external.

> On the other hand, one could see the amount of physical memory in the
> machine as A's limit and account global reclaim as A_internal.
>
> I think the former may be more natural.
>
> That aside, all memcgs should have the same statistics, obviously.
> Scripts can easily deal with counters being zero. If items differ
> between cgroups, that would suck a lot.

So, when I improve direct-reclaim path, I need to see score in scan_internal.

How do you think about background-reclaim-per-memcg ?
Should be counted into scan_internal ?

Thanks,
-Kame