From: Tejun Heo <tj@kernel.org>
To: Glauber Costa <glommer@parallels.com>
Cc: linux-kernel@vger.kernel.org, Michal Hocko <mhocko@suse.cz>,
Li Zefan <lizf@cn.fujitsu.com>,
Peter Zijlstra <peterz@infradead.org>,
Paul Turner <pjt@google.com>,
Johannes Weiner <hannes@cmpxchg.org>, Thomas Graf <tgraf@suug.ch>,
"Serge E. Hallyn" <serue@us.ibm.com>,
Vivek Goyal <vgoyal@redhat.com>,
Paul Mackerras <paulus@samba.org>, Ingo Molnar <mingo@redhat.com>,
Arnaldo Carvalho de Melo <acme@ghostprotocols.net>,
Neil Horman <nhorman@tuxdriver.com>,
"Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
Subject: Re: [PATCH RFC cgroup/for-3.7] cgroup: mark subsystems with broken hierarchy support and whine if cgroups are nested for them
Date: Wed, 12 Sep 2012 10:03:57 -0700 [thread overview]
Message-ID: <20120912170357.GN7677@google.com> (raw)
In-Reply-To: <505055E5.90903@parallels.com>
Hello, Glauber.
On Wed, Sep 12, 2012 at 01:29:09PM +0400, Glauber Costa wrote:
> Haven't gone through the whole patch yet, and not sure how you actually
> touch memcg in here. And I absolutely know we have discussed this
> before, but I still stand that for the memcg case, in which hierarchy
> can be enabled by a crazy boolean, we should be enabling it somehow. It
> is fine if we don't want to change the default without warning first,
> but a Kconfig option to make this default would really help. We should
> tell everybody with a well defined lifecycle to just enable it.
I'm not really sure how useful the Kconfig would be. I'm not gonna
nack it but am not sure it's useful either. Michal seems to be in the
same boat, so I suppose there's no strong opposition.
I don't think it would make life easier for distros. It could differ
depending on distros but in my experience with SUSE trivial patches
flipping the default aren't big deals especially if upstream has
transition plan in place. The difficulty here is that somebody needs
to assess the situation and preferably make that decision conciously -
the mechanism to do so be it a one liner patch or Kconfig option
doesn't really matter and across the transition period we would want
to keep the memcg behavior consistent regardless which kernel is in
use.
The problem with Kconfig is that we shouldn't enable the new behavior
by default as that would change the behavior silently and if we can't
do that it's just something which is buried under the sea of config
options. Kconfig or no, we need to coordinate with the distros.
>From upstream, my current plan for .use_hierarchy is
* Warn about broken hierarchy usage in increasing verbosity.
* After a couple releases, warn about creating any mem cgroup if
.use_hierarchy == 0 at root.
* After a couple releases, switch .use_hierarchy to 1 by default and
loudly warn on any attempts to set it to zero.
* Rip out flat hierarchy support and fail any attempt to set
.use_hierarchy to 0.
It'll take some months but I don't think it's too crazy and I think
the whole process should take longer than eight months to ensure any
active distro notices it.
Distros should set .use_hierarchy to 1 on mounting memcg. This
probably should happen on a new release w/ accompanying release note.
I'll try to coordinate it at least for the popular ones.
> > + * It's now diallowed to create nested cgroups if the subsystem is
> typo, disallowed.
Ooh, will fix.
> > + * broken and cgroup core will emit a warning message on such
> > + * cases. Eventually, all subsystems will be made properly
> > + * hierarchical and this will go away.
> > + */
> > + bool broken_hierarchy;
> > + bool warned_broken_hierarchy;
> > +
>
> why do we need the extra bool? Isn't WARN_ON_ONCE() suitable here?
We want to warn once per subsys instead of once for the whole system.
> > + /*
> > + * net_prio has artificial limit on the number of cgroups and
> > + * disallows nesting making it impossible to co-mount it with other
> > + * hierarchical subsystems. Remove the artificially low PRIOIDX_SZ
> > + * limit and properly nest configuration such that children follow
> > + * their parents' configurations by default and are allowed to
> > + * override and remove the following.
> > + */
> > + .broken_hierarchy = trye,
> > };
>
> "trye" doesn't seem to be a recognized word.
Yeah, fixed.
> > static int netprio_device_event(struct notifier_block *unused,
> > --- a/net/sched/cls_cgroup.c
> > +++ b/net/sched/cls_cgroup.c
> > @@ -82,6 +82,15 @@ struct cgroup_subsys net_cls_subsys = {
> > #endif
> > .base_cftypes = ss_files,
> > .module = THIS_MODULE,
> > +
> > + /*
> > + * While net_cls cgroup has the rudimentary hierarchy support of
> > + * inheriting the parent's classid on cgroup creation, it doesn't
> > + * properly propagates config changes in ancestors to their
> > + * descendents. A child should follow the parent's configuration
> > + * but be allowed to override it. Fix it and remove the following.
> > + */
> > + .broken_hierarchy = true,
> > };
> >
>
> Since all this cgroup provides is a marking, it is not terribly obvious
> to me what "proper hierarchy" would mean. Input from the authors would
> be strongly advisable here.
Setting mark on a parent should be reflected on all its children w/o
their own explicit settings.
Thanks.
--
tejun
next prev parent reply other threads:[~2012-09-12 17:04 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-10 22:31 [PATCH RFC cgroup/for-3.7] cgroup: mark subsystems with broken hierarchy support and whine if cgroups are nested for them Tejun Heo
2012-09-10 22:33 ` [PATCH REPOST " Tejun Heo
2012-09-11 10:04 ` Michal Hocko
2012-09-11 17:07 ` Tejun Heo
2012-09-12 15:47 ` Michal Hocko
2012-09-12 16:41 ` Tejun Heo
[not found] ` <5050568B.9090601@parallels.com>
2012-09-12 15:49 ` Michal Hocko
2012-09-12 17:11 ` Tejun Heo
2012-09-13 12:14 ` Michal Hocko
2012-09-13 17:18 ` Tejun Heo
2012-09-13 17:39 ` Michal Hocko
[not found] ` <5052E87A.1050405@parallels.com>
2012-09-14 19:15 ` Tejun Heo
[not found] ` <5051CB24.4010801@parallels.com>
2012-09-13 17:21 ` Tejun Heo
2012-09-11 12:38 ` Li Zefan
2012-09-11 17:08 ` Tejun Heo
2012-09-11 17:43 ` Tejun Heo
[not found] ` <505057D8.4010908@parallels.com>
2012-09-12 16:34 ` Tejun Heo
2012-09-13 6:48 ` Li Zefan
2012-09-11 18:23 ` [PATCH UPDATED " Tejun Heo
2012-09-11 20:50 ` Aristeu Rozanski
2012-09-11 20:51 ` Tejun Heo
2012-09-13 12:16 ` [PATCH REPOST " Daniel P. Berrange
2012-09-13 17:52 ` Tejun Heo
2012-09-11 14:51 ` [PATCH " Vivek Goyal
2012-09-11 14:54 ` Vivek Goyal
2012-09-11 17:16 ` Tejun Heo
2012-09-11 17:35 ` Vivek Goyal
2012-09-11 17:55 ` Tejun Heo
2012-09-11 18:16 ` Vivek Goyal
2012-09-11 18:22 ` Tejun Heo
2012-09-11 18:38 ` Vivek Goyal
[not found] ` <50505C39.1050600@parallels.com>
2012-09-12 17:09 ` Tejun Heo
2012-09-13 14:53 ` Block IO controller hierarchy suppport (Was: Re: [PATCH RFC cgroup/for-3.7] cgroup: mark subsystems with broken hierarchy support and whine if cgroups are nested for them) Vivek Goyal
2012-09-13 22:06 ` Tejun Heo
2012-09-14 2:53 ` Vivek Goyal
[not found] ` <5052E8DA.1000106@parallels.com>
2012-09-14 13:22 ` Vivek Goyal
[not found] ` <5051CBAA.5040308@parallels.com>
2012-09-13 17:54 ` [PATCH RFC cgroup/for-3.7] cgroup: mark subsystems with broken hierarchy support and whine if cgroups are nested for them Tejun Heo
[not found] ` <5052E931.8000007@parallels.com>
2012-09-14 18:56 ` Tejun Heo
[not found] ` <505055E5.90903@parallels.com>
2012-09-12 17:03 ` Tejun Heo [this message]
[not found] ` <5051C954.2080600@parallels.com>
2012-09-13 17:48 ` Tejun Heo
[not found] ` <5052E9BC.2020908@parallels.com>
2012-09-17 7:59 ` Daniel Wagner
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=20120912170357.GN7677@google.com \
--to=tj@kernel.org \
--cc=acme@ghostprotocols.net \
--cc=aneesh.kumar@linux.vnet.ibm.com \
--cc=glommer@parallels.com \
--cc=hannes@cmpxchg.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lizf@cn.fujitsu.com \
--cc=mhocko@suse.cz \
--cc=mingo@redhat.com \
--cc=nhorman@tuxdriver.com \
--cc=paulus@samba.org \
--cc=peterz@infradead.org \
--cc=pjt@google.com \
--cc=serue@us.ibm.com \
--cc=tgraf@suug.ch \
--cc=vgoyal@redhat.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).