On Tue, May 17, 2011 at 5:00 PM, KAMEZAWA Hiroyuki <kamezawa.hiroyu@xxxxxxxxxxxxxx> wrote:
After reading threads, an another idea comes. Johannes' soft_limit just worksOn Wed, 18 May 2011 08:49:19 +0900
KAMEZAWA Hiroyuki <kamezawa.hiroyu@xxxxxxxxxxxxxx> wrote:
> On Mon, 16 May 2011 17:18:20 -0700
> Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote:
>
> > On Mon, 16 May 2011 17:05:02 -0700
> > Ying Han <yinghan@xxxxxxxxxx> wrote:
> >
> > > On Mon, May 16, 2011 at 4:15 PM, Johannes Weiner <hannes@xxxxxxxxxxx> 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@xxxxxxxxxx>
> > > >
> > > > 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@xxxxxxxxxxx>
> > > >
> > >
> > > 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.
>
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