On Tue 26-06-12 22:22:04, Glauber Costa wrote: > On 06/26/2012 10:12 PM, Tejun Heo wrote: > >On Tue, Jun 26, 2012 at 05:30:28PM +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@xxxxxxxxxxxxx> > >>CC: Michal Hocko <mhocko@xxxxxxx> > >>CC: Kamezawa Hiroyuki <kamezawa.hiroyu@xxxxxxxxxxxxxx> > >>CC: Johannes Weiner <hannes@xxxxxxxxxxx> > >>CC: Tejun Heo <tj@xxxxxxxxxx> > > > >Just in case it wasn't clear in the other posting. > > > > Nacked-by: Tejun Heo <tj@xxxxxxxxxx> > > > >You can't change the default behavior silently. Not in this scale. > > > >Thanks. > > > I certainly don't share your views of the matter here. > > I would agree with you if we were changing a fundamental algorithm, > with no way to resort back to a default setup. We are not removing any > functionality whatsoever here. > > I would agree with you if we were actually documenting explicitly > that this is an expected default behavior. Actually we did: Documentation/cgroups/memory.txt " 6.1 Enabling hierarchical accounting and reclaim A memory cgroup by default disables the hierarchy feature. Support can be enabled by writing 1 to memory.use_hierarchy file of the root cgroup " But I do not think this is really that important. We are still interested in making the thing sane. Flat_hierarchical trees just don't seem right... Generic? Sure. Sane? Really? -- Michal Hocko SUSE Labs SUSE LINUX s.r.o. Lihovarska 1060/12 190 00 Praha 9 Czech Republic -- To unsubscribe from this list: send the line "unsubscribe cgroups" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html