All of lore.kernel.org
 help / color / mirror / Atom feed
From: Johannes Weiner <hannes@cmpxchg.org>
To: Ying Han <yinghan@google.com>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
	Daisuke Nishimura <nishimura@mxp.nes.nec.co.jp>,
	Balbir Singh <balbir@linux.vnet.ibm.com>,
	Michal Hocko <mhocko@suse.cz>,
	Andrew Morton <akpm@linux-foundation.org>,
	Rik van Riel <riel@redhat.com>,
	Minchan Kim <minchan.kim@gmail.com>,
	KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
	Mel Gorman <mgorman@suse.de>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [rfc patch 4/6] memcg: reclaim statistics
Date: Tue, 17 May 2011 09:42:30 +0200	[thread overview]
Message-ID: <20110517074230.GY16531@cmpxchg.org> (raw)
In-Reply-To: <BANLkTimLNZfc-jcA3yBG5D3k2u=0_JnrhQ@mail.gmail.com>

On Mon, May 16, 2011 at 05:20:31PM -0700, Ying Han wrote:
> On Mon, May 16, 2011 at 4:10 PM, Johannes Weiner <hannes@cmpxchg.org> wrote:
> 
> > On Thu, May 12, 2011 at 12:33:50PM -0700, Ying Han wrote:
> > > The stats for soft_limit reclaim from global ttfp have been merged in
> > > mmotm i believe as the following:
> > >
> > > "soft_direct_steal"
> > > "soft_direct_scan"
> > >
> > > I wonder we might want to separate that out from the other case where the
> > > reclaim is from the parent triggers its limit.
> >
> > The way I implemented soft limits in 6/6 is to increase pressure on
> > exceeding children whenever hierarchical reclaim is taking place.
> >
> > This changes soft limit from
> >
> >        Global memory pressure: reclaim from exceeding memcg(s) first
> >
> > to
> >
> >        Memory pressure on a memcg: reclaim from all its children,
> >        with increased pressure on those exceeding their soft limit
> >        (where global memory pressure means root_mem_cgroup and all
> >        existing memcgs are considered its children)
> >
> > which makes the soft limit much more generic and more powerful, as it
> > allows the admin to prioritize reclaim throughout the hierarchy, not
> > only for global memory pressure.  Consider one memcg with two
> > subgroups.  You can now prioritize reclaim to prefer one subgroup over
> > another through soft limiting.
> >
> > This is one reason why I think that the approach of maintaining a
> > global list of memcgs that exceed their soft limits is an inferior
> > approach; it does not take the hierarchy into account at all.
> >
> > This scheme would not provide a natural way of counting pages that
> > were reclaimed because of the soft limit, and thus I still oppose the
> > merging of soft limit counters.
> 
> The proposal we discussed during LSF ( implemented in the patch " memcg:
> revisit soft_limit reclaim on contention") takes consideration
> of hierarchical reclaim. The memcg is linked in the list if it exceeds the
> soft_limit, and the soft_limit reclaim per-memcg is calling
> mem_cgroup_hierarchical_reclaim().

It does hierarchical soft limit reclaim once triggered, but I meant
that soft limits themselves have no hierarchical meaning.  Say you
have the following hierarchy:

                root_mem_cgroup

             aaa               bbb

           a1  a2             b1  b2

        a1-1

Consider aaa and a1 had a soft limit.  If global memory arose, aaa and
all its children would be pushed back with the current scheme, the one
you are proposing, and the one I am proposing.

But now consider aaa hitting its hard limit.  Regular target reclaim
will be triggered, and a1, a2, and a1-1 will be scanned equally from
hierarchical reclaim.  That a1 is in excess of its soft limit is not
considered at all.

With what I am proposing, a1 and a1-1 would be pushed back more
aggressively than a2, because a1 is in excess of its soft limit and
a1-1 is contributing to that.

It would mean that given a group of siblings, you distribute the
pressure weighted by the soft limit configuration, independent of the
kind of hierarchical/external pressure (global memory scarcity or
parent hit the hard limit).

It's much easier to understand if you think of global memory pressure
to mean that root_mem_cgroup hit its hard limit, and that all existing
memcgs are hierarchically below the root_mem_cgroup.  Altough it is
technically not implemented that way, that would be the consistent
model.

My proposal is a generic and native way of enforcing soft limits: a
memcg hit its hard limit, reclaim from the hierarchy below it, prefer
those in excess of their soft limit.

While yours is special-cased to immediate descendants of the
root_mem_cgroup.

> The current "soft_steal" and "soft_scan" is counting pages being steal/scan
>  inside mem_cgroup_hierarchical_reclaim() w check_soft checking, which then
> counts pages being reclaimed because of soft_limit and also counting the
> hierarchical reclaim.

Yeah, I understand that.  What I am saying is that in my code,
everytime a hierarchy of memcgs is scanned (global memory reclaim,
target reclaim, kswapd or direct, it's all the same), a memcg that is
in excess of its soft limit is put more pressure on compared to its
siblings.

There is no stand-alone 'now, go reclaim soft limits' cycle anymore.
As such, it would be impossible to maintain that counter.

WARNING: multiple messages have this Message-ID (diff)
From: Johannes Weiner <hannes@cmpxchg.org>
To: Ying Han <yinghan@google.com>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
	Daisuke Nishimura <nishimura@mxp.nes.nec.co.jp>,
	Balbir Singh <balbir@linux.vnet.ibm.com>,
	Michal Hocko <mhocko@suse.cz>,
	Andrew Morton <akpm@linux-foundation.org>,
	Rik van Riel <riel@redhat.com>,
	Minchan Kim <minchan.kim@gmail.com>,
	KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
	Mel Gorman <mgorman@suse.de>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [rfc patch 4/6] memcg: reclaim statistics
Date: Tue, 17 May 2011 09:42:30 +0200	[thread overview]
Message-ID: <20110517074230.GY16531@cmpxchg.org> (raw)
In-Reply-To: <BANLkTimLNZfc-jcA3yBG5D3k2u=0_JnrhQ@mail.gmail.com>

On Mon, May 16, 2011 at 05:20:31PM -0700, Ying Han wrote:
> On Mon, May 16, 2011 at 4:10 PM, Johannes Weiner <hannes@cmpxchg.org> wrote:
> 
> > On Thu, May 12, 2011 at 12:33:50PM -0700, Ying Han wrote:
> > > The stats for soft_limit reclaim from global ttfp have been merged in
> > > mmotm i believe as the following:
> > >
> > > "soft_direct_steal"
> > > "soft_direct_scan"
> > >
> > > I wonder we might want to separate that out from the other case where the
> > > reclaim is from the parent triggers its limit.
> >
> > The way I implemented soft limits in 6/6 is to increase pressure on
> > exceeding children whenever hierarchical reclaim is taking place.
> >
> > This changes soft limit from
> >
> >        Global memory pressure: reclaim from exceeding memcg(s) first
> >
> > to
> >
> >        Memory pressure on a memcg: reclaim from all its children,
> >        with increased pressure on those exceeding their soft limit
> >        (where global memory pressure means root_mem_cgroup and all
> >        existing memcgs are considered its children)
> >
> > which makes the soft limit much more generic and more powerful, as it
> > allows the admin to prioritize reclaim throughout the hierarchy, not
> > only for global memory pressure.  Consider one memcg with two
> > subgroups.  You can now prioritize reclaim to prefer one subgroup over
> > another through soft limiting.
> >
> > This is one reason why I think that the approach of maintaining a
> > global list of memcgs that exceed their soft limits is an inferior
> > approach; it does not take the hierarchy into account at all.
> >
> > This scheme would not provide a natural way of counting pages that
> > were reclaimed because of the soft limit, and thus I still oppose the
> > merging of soft limit counters.
> 
> The proposal we discussed during LSF ( implemented in the patch " memcg:
> revisit soft_limit reclaim on contention") takes consideration
> of hierarchical reclaim. The memcg is linked in the list if it exceeds the
> soft_limit, and the soft_limit reclaim per-memcg is calling
> mem_cgroup_hierarchical_reclaim().

It does hierarchical soft limit reclaim once triggered, but I meant
that soft limits themselves have no hierarchical meaning.  Say you
have the following hierarchy:

                root_mem_cgroup

             aaa               bbb

           a1  a2             b1  b2

        a1-1

Consider aaa and a1 had a soft limit.  If global memory arose, aaa and
all its children would be pushed back with the current scheme, the one
you are proposing, and the one I am proposing.

But now consider aaa hitting its hard limit.  Regular target reclaim
will be triggered, and a1, a2, and a1-1 will be scanned equally from
hierarchical reclaim.  That a1 is in excess of its soft limit is not
considered at all.

With what I am proposing, a1 and a1-1 would be pushed back more
aggressively than a2, because a1 is in excess of its soft limit and
a1-1 is contributing to that.

It would mean that given a group of siblings, you distribute the
pressure weighted by the soft limit configuration, independent of the
kind of hierarchical/external pressure (global memory scarcity or
parent hit the hard limit).

It's much easier to understand if you think of global memory pressure
to mean that root_mem_cgroup hit its hard limit, and that all existing
memcgs are hierarchically below the root_mem_cgroup.  Altough it is
technically not implemented that way, that would be the consistent
model.

My proposal is a generic and native way of enforcing soft limits: a
memcg hit its hard limit, reclaim from the hierarchy below it, prefer
those in excess of their soft limit.

While yours is special-cased to immediate descendants of the
root_mem_cgroup.

> The current "soft_steal" and "soft_scan" is counting pages being steal/scan
>  inside mem_cgroup_hierarchical_reclaim() w check_soft checking, which then
> counts pages being reclaimed because of soft_limit and also counting the
> hierarchical reclaim.

Yeah, I understand that.  What I am saying is that in my code,
everytime a hierarchy of memcgs is scanned (global memory reclaim,
target reclaim, kswapd or direct, it's all the same), a memcg that is
in excess of its soft limit is put more pressure on compared to its
siblings.

There is no stand-alone 'now, go reclaim soft limits' cycle anymore.
As such, it would be impossible to maintain that counter.

--
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>

  reply	other threads:[~2011-05-17  7:42 UTC|newest]

Thread overview: 83+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-12 14:53 [rfc patch 0/6] mm: memcg naturalization Johannes Weiner
2011-05-12 14:53 ` Johannes Weiner
2011-05-12 14:53 ` [rfc patch 1/6] memcg: remove unused retry signal from reclaim Johannes Weiner
2011-05-12 14:53   ` Johannes Weiner
2011-05-12 15:02   ` Rik van Riel
2011-05-12 15:02     ` Rik van Riel
2011-05-12 17:22     ` Ying Han
2011-05-12 23:44   ` KAMEZAWA Hiroyuki
2011-05-12 23:44     ` KAMEZAWA Hiroyuki
2011-05-13  9:23   ` Michal Hocko
2011-05-13  9:23     ` Michal Hocko
2011-05-12 14:53 ` [rfc patch 2/6] vmscan: make distinction between memcg reclaim and LRU list selection Johannes Weiner
2011-05-12 14:53   ` Johannes Weiner
2011-05-12 15:33   ` Rik van Riel
2011-05-12 15:33     ` Rik van Riel
2011-05-12 16:03     ` Johannes Weiner
2011-05-12 16:03       ` Johannes Weiner
2011-05-17  6:38       ` Ying Han
2011-05-17  6:38         ` Ying Han
2011-05-17  8:25         ` Johannes Weiner
2011-05-17  8:25           ` Johannes Weiner
2011-05-12 23:50   ` KAMEZAWA Hiroyuki
2011-05-12 23:50     ` KAMEZAWA Hiroyuki
2011-05-13  6:58     ` Johannes Weiner
2011-05-13  6:58       ` Johannes Weiner
2011-05-16 22:36       ` Andrew Morton
2011-05-16 22:36         ` Andrew Morton
2011-05-12 14:53 ` [rfc patch 3/6] mm: memcg-aware global reclaim Johannes Weiner
2011-05-12 14:53   ` Johannes Weiner
2011-05-12 16:04   ` Rik van Riel
2011-05-12 16:04     ` Rik van Riel
2011-05-12 19:19   ` Ying Han
2011-05-13  7:08     ` Johannes Weiner
2011-05-13  7:08       ` Johannes Weiner
2011-05-13  0:04   ` KAMEZAWA Hiroyuki
2011-05-13  0:04     ` KAMEZAWA Hiroyuki
2011-05-13  7:18     ` Johannes Weiner
2011-05-13  7:18       ` Johannes Weiner
2011-05-13  0:40   ` KAMEZAWA Hiroyuki
2011-05-13  0:40     ` KAMEZAWA Hiroyuki
2011-05-13  6:54     ` Johannes Weiner
2011-05-13  6:54       ` Johannes Weiner
2011-05-13  9:53   ` Michal Hocko
2011-05-13  9:53     ` Michal Hocko
2011-05-13 10:28     ` Johannes Weiner
2011-05-13 10:28       ` Johannes Weiner
2011-05-13 11:02       ` Michal Hocko
2011-05-13 11:02         ` Michal Hocko
2011-05-12 14:53 ` [rfc patch 4/6] memcg: reclaim statistics Johannes Weiner
2011-05-12 14:53   ` Johannes Weiner
2011-05-12 19:33   ` Ying Han
2011-05-16 23:10     ` Johannes Weiner
2011-05-16 23:10       ` Johannes Weiner
2011-05-17  0:20       ` Ying Han
2011-05-17  7:42         ` Johannes Weiner [this message]
2011-05-17  7:42           ` Johannes Weiner
2011-05-17 13:55           ` Rik van Riel
2011-05-17 13:55             ` Rik van Riel
2011-05-12 14:53 ` [rfc patch 5/6] memcg: remove global LRU list Johannes Weiner
2011-05-12 14:53   ` Johannes Weiner
2011-05-13  9:53   ` Michal Hocko
2011-05-13  9:53     ` Michal Hocko
2011-05-13 10:36     ` Johannes Weiner
2011-05-13 10:36       ` Johannes Weiner
2011-05-13 11:01       ` Michal Hocko
2011-05-13 11:01         ` Michal Hocko
2011-05-12 14:53 ` [rfc patch 6/6] memcg: rework soft limit reclaim Johannes Weiner
2011-05-12 14:53   ` Johannes Weiner
2011-05-12 18:41   ` Ying Han
2011-05-12 18:41     ` Ying Han
2011-05-12 18:53 ` [rfc patch 0/6] mm: memcg naturalization Ying Han
2011-05-13  7:20   ` Johannes Weiner
2011-05-13  7:20     ` Johannes Weiner
2011-05-17  0:53     ` Ying Han
2011-05-17  8:11       ` Johannes Weiner
2011-05-17  8:11         ` Johannes Weiner
2011-05-17 14:45         ` Ying Han
2011-05-16 10:30 ` Balbir Singh
2011-05-16 10:30   ` Balbir Singh
2011-05-16 10:57   ` Johannes Weiner
2011-05-16 10:57     ` Johannes Weiner
2011-05-17  6:32     ` Balbir Singh
2011-05-17  6:32       ` Balbir Singh

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20110517074230.GY16531@cmpxchg.org \
    --to=hannes@cmpxchg.org \
    --cc=akpm@linux-foundation.org \
    --cc=balbir@linux.vnet.ibm.com \
    --cc=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=kosaki.motohiro@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@suse.de \
    --cc=mhocko@suse.cz \
    --cc=minchan.kim@gmail.com \
    --cc=nishimura@mxp.nes.nec.co.jp \
    --cc=riel@redhat.com \
    --cc=yinghan@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.