linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Tejun Heo <tj@kernel.org>
To: Michal Hocko <mhocko@suse.cz>
Cc: Johannes Weiner <hannes@cmpxchg.org>,
	Balbir Singh <bsingharora@gmail.com>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
	cgroups@vger.kernel.org, linux-mm@kvack.org,
	Hugh Dickins <hughd@google.com>, Ying Han <yinghan@google.com>,
	Glauber Costa <glommer@parallels.com>,
	Michel Lespinasse <walken@google.com>,
	Greg Thelen <gthelen@google.com>
Subject: Re: memcg: softlimit on internal nodes
Date: Sun, 21 Apr 2013 21:39:39 -0700	[thread overview]
Message-ID: <20130422043939.GB25089@mtj.dyndns.org> (raw)
In-Reply-To: <20130421124554.GA8473@dhcp22.suse.cz>

Hey, Michal.

On Sun, Apr 21, 2013 at 02:46:06PM +0200, Michal Hocko wrote:
> [I am terribly jet lagged so I should probably postpone any serious
> thinking for few days but let me try]

Sorry about raising a flame war so soon after the conference week.
None of these is really urgent, so please take your time.

> The current implementation stores all subtrees that are over the soft
> limit in a tree sorted by how much they are excessing the limit. Have
> a look at mem_cgroup_update_tree and its callers (namely down from
> __mem_cgroup_commit_charge). My patch _preserves_ this behavior it just
> makes the code much saner and as a bonus it doesn't touch groups (not
> hierarchies) under the limit unless necessary which wasn't the case
> previously.

What you describe is already confused.  What does that knob mean then?
Google folks seem to think it's an allocation guarantee but global
reclaim is broken and breaches the configuration (which I suppose is
arising from their usage of memcg) and I don't understand what your
definition of the knob is apart from the description of what's
implemented now, which apparently is causing horrible confusion on all
the involved parties.

> So yes, I can understand why this is confusing for you. The soft limit
> semantic is different because the limit is/was considered only if it
> is/was in excess.
> 
> Maybe I was using word _guarantee_ too often to confuse you, I am sorry
> if this is the case. The guarantee part comes from the group point of
> view. So the original semantic of the hierarchical behavior is
> unchanged.

I don't care what word you use.  There are two choices.  Pick one and
stick with it.  Don't make it something which inhibits reclaim if
under limit for leaf nodes but behaves somewhat differently if an
ancestor is under pressure or whatever.  Just pick one.  It is either
an reclaim inhibitor or actual soft limit.

> What to does it mean that an inter node is under the soft limit
> for the subhierarchy is questionable and there are usecases where

It's not frigging questionable.  You're just horribly confused.

Thanks.

-- 
tejun

--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2013-04-22  4:39 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-20  0:26 memcg: softlimit on internal nodes Tejun Heo
2013-04-20  0:42 ` Tejun Heo
2013-04-20  3:35   ` Greg Thelen
2013-04-21  1:53     ` Tejun Heo
2013-04-20  3:16 ` Michal Hocko
2013-04-21  2:23   ` Tejun Heo
2013-04-21  8:55     ` Michel Lespinasse
2013-04-22  4:24       ` Tejun Heo
2013-04-22  7:14         ` Michel Lespinasse
2013-04-22 14:48           ` Tejun Heo
2013-04-22 15:37         ` Michal Hocko
2013-04-22 15:46           ` Tejun Heo
2013-04-22 15:54             ` Michal Hocko
2013-04-22 16:01               ` Tejun Heo
2013-04-23  9:58               ` Michel Lespinasse
2013-04-23 10:17                 ` Glauber Costa
2013-04-23 11:40                   ` Michal Hocko
2013-04-23 11:54                     ` Glauber Costa
2013-04-23 12:51                     ` Michel Lespinasse
2013-04-23 13:06                       ` Michal Hocko
2013-04-23 13:13                         ` Glauber Costa
2013-04-23 13:28                           ` Michal Hocko
2013-04-23 11:32                 ` Michal Hocko
2013-04-23 12:45                   ` Michel Lespinasse
2013-04-23 12:59                     ` Michal Hocko
2013-04-23 12:51                 ` Michal Hocko
2013-04-21 12:46     ` Michal Hocko
2013-04-22  4:39       ` Tejun Heo [this message]
2013-04-22 15:19         ` Michal Hocko
2013-04-22 15:57           ` Tejun Heo
2013-04-22 15:57             ` Tejun Heo
2013-04-22 16:20             ` Michal Hocko
2013-04-22 18:30               ` Tejun Heo
2013-04-23  9:29                 ` Michal Hocko
2013-04-23 17:09                   ` Tejun Heo
2013-04-26 11:51                     ` Michal Hocko
2013-04-26 18:37                       ` Tejun Heo
2013-04-29 15:27                         ` Michal Hocko
2013-04-23  9:33                 ` [RFC v2 0/4] soft limit rework Michal Hocko
2013-04-23  9:33                   ` [RFC v2 1/4] memcg: integrate soft reclaim tighter with zone shrinking code Michal Hocko
2013-04-23  9:33                   ` [RFC v2 2/4] memcg: Get rid of soft-limit tree infrastructure Michal Hocko
2013-04-23  9:33                   ` [RFC v2 3/4] vmscan, memcg: Do softlimit reclaim also for targeted reclaim Michal Hocko
2013-04-23  9:33                   ` [RFC v2 4/4] memcg: Ignore soft limit until it is explicitly specified Michal Hocko
2013-04-24 21:45                 ` memcg: softlimit on internal nodes Johannes Weiner
2013-04-25  0:33                   ` Tejun Heo
2013-04-29 18:39                     ` Johannes Weiner

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=20130422043939.GB25089@mtj.dyndns.org \
    --to=tj@kernel.org \
    --cc=bsingharora@gmail.com \
    --cc=cgroups@vger.kernel.org \
    --cc=glommer@parallels.com \
    --cc=gthelen@google.com \
    --cc=hannes@cmpxchg.org \
    --cc=hughd@google.com \
    --cc=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@suse.cz \
    --cc=walken@google.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).