From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail138.messagelabs.com (mail138.messagelabs.com [216.82.249.35]) by kanga.kvack.org (Postfix) with ESMTP id 7C5068D003B for ; Tue, 17 May 2011 20:56:30 -0400 (EDT) Received: from wpaz13.hot.corp.google.com (wpaz13.hot.corp.google.com [172.24.198.77]) by smtp-out.google.com with ESMTP id p4I0uO6T009338 for ; Tue, 17 May 2011 17:56:24 -0700 Received: from qwe5 (qwe5.prod.google.com [10.241.194.5]) by wpaz13.hot.corp.google.com with ESMTP id p4I0uN6h029612 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 17 May 2011 17:56:23 -0700 Received: by qwe5 with SMTP id 5so652909qwe.37 for ; Tue, 17 May 2011 17:56:23 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20110518090047.0b46a60d.kamezawa.hiroyu@jp.fujitsu.com> References: <1305583230-2111-1-git-send-email-yinghan@google.com> <20110516231512.GW16531@cmpxchg.org> <20110516171820.124a8fbc.akpm@linux-foundation.org> <20110518084919.988d3d41.kamezawa.hiroyu@jp.fujitsu.com> <20110518090047.0b46a60d.kamezawa.hiroyu@jp.fujitsu.com> Date: Tue, 17 May 2011 17:56:23 -0700 Message-ID: Subject: Re: [PATCH] memcg: fix typo in the soft_limit stats. From: Ying Han Content-Type: multipart/alternative; boundary=0016360e3f5c840ebf04a3825bb7 Sender: owner-linux-mm@kvack.org List-ID: To: KAMEZAWA Hiroyuki Cc: Andrew Morton , Johannes Weiner , KOSAKI Motohiro , Minchan Kim , Daisuke Nishimura , Balbir Singh , Tejun Heo , Pavel Emelyanov , Li Zefan , Mel Gorman , Christoph Lameter , Rik van Riel , Hugh Dickins , Michal Hocko , Dave Hansen , Zhu Yanhai , linux-mm@kvack.org --0016360e3f5c840ebf04a3825bb7 Content-Type: text/plain; charset=ISO-8859-1 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 wrote: > > > On Mon, 16 May 2011 17:18:20 -0700 > > Andrew Morton wrote: > > > > > On Mon, 16 May 2011 17:05:02 -0700 > > > Ying Han wrote: > > > > > > > On Mon, May 16, 2011 at 4:15 PM, Johannes Weiner > 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 > > > > > > > > > > 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 > > > > > > > > > > > > > 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 > > > > --0016360e3f5c840ebf04a3825bb7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, May 17, 2011 at 5:00 PM, KAMEZAW= A Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> wrote:
On Wed, 18 May 2011 08:49:19 +0900
KAMEZAWA Hiroyuki <kam= ezawa.hiroyu@jp.fujitsu.com> wrote:

> On Mon, 16 May 2011 17:18:20 -0700
> Andrew Morton <akpm@li= nux-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 wrot= e:
> > > > > This fixes the typo in the memory.stat including t= he 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 m= akes 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 na= tural 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 in= to mmotm. Does
> > > it make sense to fix the
> > > existing stats first while we are discussing other approache= s?
> > >
> >
> > It would be quite bad to add new userspace-visible stats and to t= hen
> > take them away again.
> >
> yes.
>
> > But given that memcg-add-stats-to-monitor-soft_limit-reclaim.patc= h is
> > queued for 2.6.39-rc1, we could proceed with that plan and then m= ake
> > sure that Johannes's changes are merged either prior to 2.6.4= 0 or
> > they are never merged at all.
> >
> > Or we could just leave out the stats until we're sure. =A0Not= having them
> > for a while is not as bad as adding them and then removing them.<= br> > >
>
> I agree. I'm okay with removing them for a while. Johannes and Yin= g, could you
> make a concensus ? IMHO, Johannes' work for making soft-limit co-o= perative with
> hirerachical reclaim makes sense and agree to leave counter name as it= is.
>

After reading threads, an another idea comes. Johannes' sof= t_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 me= mory pressure could happen on the memcg ( global reclaim, =A0parent 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 cou= nt. Now it only count t= he soft_limit reclaim from the global memory pressure.

Hmm, I'm not sure using counter of softlimit or (new) counter of reclai= med-by-parent
for that purpose.

But I think this change of stat name is not necessary, anyway.

=A0I am ok to revert this stat now since we are hav= ing the whole discussion on the soft_limit reclaim implementation.=A0

--Ying

Thanks,
-Kame




--0016360e3f5c840ebf04a3825bb7-- -- 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: email@kvack.org