From: Tejun Heo <tj@kernel.org>
To: Glauber Costa <glommer@parallels.com>
Cc: cgroups@vger.kernel.org, linux-mm@kvack.org,
kamezawa.hiroyu@jp.fujitsu.com, Michal Hocko <mhocko@suse.cz>,
Johannes Weiner <hannes@cmpxchg.org>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH 2/2] memcg: first step towards hierarchical controller
Date: Tue, 26 Jun 2012 11:04:51 -0700 [thread overview]
Message-ID: <20120626180451.GP3869@google.com> (raw)
In-Reply-To: <1340725634-9017-3-git-send-email-glommer@parallels.com>
On Tue, Jun 26, 2012 at 07:47:14PM +0400, Glauber Costa wrote:
> Okay, so after recent discussions, I am proposing the following
> patch. It won't remove hierarchy, or anything like that. Just default
> to true in the root cgroup, and print a warning once if you try
> to set it back to 0.
>
> I am not adding it to feature-removal-schedule.txt because I don't
> view it as a consensus. Rather, changing the default would allow us
> to give it a time around in the open, and see if people complain
> and what we can learn about that.
>
> Signed-off-by: Glauber Costa <glommer@parallels.com>
> Acked-by: Johannes Weiner <hannes@cmpxchg.org>
> CC: Michal Hocko <mhocko@suse.cz>
> CC: Kamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
> CC: Tejun Heo <tj@kernel.org>
> ---
> mm/memcontrol.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index 85f7790..c37e4c1 100644
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -3993,6 +3993,10 @@ static int mem_cgroup_hierarchy_write(struct cgroup *cont, struct cftype *cft,
> if (memcg->use_hierarchy == val)
> goto out;
>
> + WARN_ONCE(!parent_memcg && memcg->use_hierarchy,
> + "Non-hierarchical memcg is considered for deprecation\n"
> + "Please consider reorganizing your tree to work with hierarchical accounting\n"
> + "If you have any reason not to, let us know at cgroups@vger.kernel.org\n");
> /*
> * If parent's use_hierarchy is set, we can't make any modifications
> * in the child subtrees. If it is unset, then the change can
> @@ -5221,6 +5225,7 @@ mem_cgroup_create(struct cgroup *cont)
> INIT_WORK(&stock->work, drain_local_stock);
> }
> hotcpu_notifier(memcg_cpu_hotplug_callback, 0);
> + memcg->use_hierarchy = true;
> } else {
> parent = mem_cgroup_from_cont(cont->parent);
> memcg->use_hierarchy = parent->use_hierarchy;
So, ummm, I don't think we can do this. We CAN NOT silently flip the
default behavior like this. Hell, no. What we can do is something
like the following.
1. Make .use_hierarchy a global property and convert .use_hierarchy
file to reject writes to the setting which is different from the
global one. Rip out partial hierarchy related code (how little
they may be). Note that the default should still be flat
hierarchy.
2. Mark flat hierarchy deprecated and produce a warning message if
memcg is mounted w/o hierarchy option for a year or two.
3. After the existing users had enough chance to move away from flat
hierarchy, rip out flat hierarchy code and error if hierarchy
option is not specified.
Later on, we may decide to get rid of the hierarchy mount option but I
don't think that matters all that much.
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>
next prev parent reply other threads:[~2012-06-26 18:04 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-26 15:47 [PATCH 0/2] fix and deprecate use_hierarchy file Glauber Costa
2012-06-26 15:47 ` [PATCH 1/2] fix bad behavior in " Glauber Costa
2012-06-26 15:52 ` Michal Hocko
2012-06-26 15:54 ` Johannes Weiner
2012-06-26 22:25 ` Andrew Morton
2012-06-26 22:30 ` Tejun Heo
2012-06-26 15:47 ` [PATCH 2/2] memcg: first step towards hierarchical controller Glauber Costa
2012-06-26 16:15 ` Michal Hocko
2012-06-26 16:37 ` Glauber Costa
2012-06-26 17:54 ` Michal Hocko
2012-06-26 18:04 ` Tejun Heo [this message]
2012-06-26 18:55 ` Johannes Weiner
2012-06-26 19:14 ` Tejun Heo
2012-06-26 20:59 ` Johannes Weiner
2012-06-26 21:19 ` Tejun Heo
2012-06-27 8:57 ` Glauber Costa
2012-06-27 17:07 ` Tejun Heo
2012-06-26 22:08 ` Michal Hocko
2012-06-26 22:14 ` Tejun Heo
2012-06-26 22:17 ` Tejun Heo
2012-06-27 8:52 ` Glauber Costa
2012-06-27 16:58 ` Tejun Heo
2012-06-27 12:51 ` Michal Hocko
2012-06-27 12:49 ` Glauber Costa
2012-06-27 17:33 ` Tejun Heo
2012-06-28 8:46 ` Kamezawa Hiroyuki
2012-06-28 9:12 ` Glauber Costa
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=20120626180451.GP3869@google.com \
--to=tj@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=cgroups@vger.kernel.org \
--cc=glommer@parallels.com \
--cc=hannes@cmpxchg.org \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.cz \
/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).