On Tue, May 17, 2011 at 5:00 PM, KAMEZAWA Hiroyuki <
kamezawa.hiroyu@jp.fujitsu.com> wrote:

> On Wed, 18 May 2011 08:49:19 +0900
> KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> wrote:
>
> > On Mon, 16 May 2011 17:18:20 -0700
> > Andrew Morton <akpm@linux-foundation.org> wrote:
> >
> > > On Mon, 16 May 2011 17:05:02 -0700
> > > Ying Han <yinghan@google.com> wrote:
> > >
> > > > On Mon, May 16, 2011 at 4:15 PM, Johannes Weiner <hannes@cmpxchg.org>
> wrote:
> > > >
> > > > > On Mon, May 16, 2011 at 03:00:30PM -0700, Ying Han wrote:
> > > > > > This fixes the typo in the memory.stat including the following
> two
> > > > > > stats:
> > > > > >
> > > > > > $ cat /dev/cgroup/memory/A/memory.stat
> > > > > > total_soft_steal 0
> > > > > > total_soft_scan 0
> > > > > >
> > > > > > And change it to:
> > > > > >
> > > > > > $ cat /dev/cgroup/memory/A/memory.stat
> > > > > > total_soft_kswapd_steal 0
> > > > > > total_soft_kswapd_scan 0
> > > > > >
> > > > > > Signed-off-by: Ying Han <yinghan@google.com>
> > > > >
> > > > > I am currently proposing and working on a scheme that makes the
> soft
> > > > > limit not only a factor for global memory pressure, but for
> > > > > hierarchical reclaim in general, to prefer child memcgs during
> reclaim
> > > > > that are in excess of their soft limit.
> > > > >
> > > > > Because this means prioritizing memcgs over one another, rather
> than
> > > > > having explicit soft limit reclaim runs, there is no natural
> counter
> > > > > for pages reclaimed due to the soft limit anymore.
> > > > >
> > > > > Thus, for the patch that introduces this counter:
> > > > >
> > > > > Nacked-by: Johannes Weiner <hannes@cmpxchg.org>
> > > > >
> > > >
> > > > This patch is fixing a typo of the stats being integrated into mmotm.
> Does
> > > > it make sense to fix the
> > > > existing stats first while we are discussing other approaches?
> > > >
> > >
> > > It would be quite bad to add new userspace-visible stats and to then
> > > take them away again.
> > >
> > yes.
> >
> > > But given that memcg-add-stats-to-monitor-soft_limit-reclaim.patch is
> > > queued for 2.6.39-rc1, we could proceed with that plan and then make
> > > sure that Johannes's changes are merged either prior to 2.6.40 or
> > > they are never merged at all.
> > >
> > > Or we could just leave out the stats until we're sure.  Not having them
> > > for a while is not as bad as adding them and then removing them.
> > >
> >
> > I agree. I'm okay with removing them for a while. Johannes and Ying,
> could you
> > make a concensus ? IMHO, Johannes' work for making soft-limit
> co-operative with
> > hirerachical reclaim makes sense and agree to leave counter name as it
> is.
> >
>
> After reading threads, an another idea comes. Johannes' soft_limit just
> works
> when the hierarchy hit limit. I think pages are not reclaimed by
> soft_limit...
> it just reclaimed by the limit because of hierarchy. Right ?
>

My understanding of Johannes's proposal is to do soft_limit reclaim from any
memory pressure could happen on the memcg ( global reclaim,  parent hit the
hard_limit, per-memcg bg reclaim ).

If that is something we agree to proceed, the existing stats only covers
partially what we would like to count. Now it only count the soft_limit
reclaim from the global memory pressure.

Hmm, I'm not sure using counter of softlimit or (new) counter of
> reclaimed-by-parent
> for that purpose.
>
> But I think this change of stat name is not necessary, anyway.
>

 I am ok to revert this stat now since we are having the whole discussion on
the soft_limit reclaim implementation.

--Ying

>
> Thanks,
> -Kame
>
>
>
>