linux-kernel - Re: [PATCH v2] memcg: first step towards hierarchical controller

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <5045BD25.10301@parallels.com>
Date:	Tue, 4 Sep 2012 12:34:45 +0400
From:	Glauber Costa <glommer@...allels.com>
To:	Michal Hocko <mhocko@...e.cz>
CC:	<linux-kernel@...r.kernel.org>, <cgroups@...r.kernel.org>,
	<linux-mm@...ck.org>, Dave Jones <davej@...hat.com>,
	Ben Hutchings <ben@...adent.org.uk>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Paul Turner <pjt@...gle.com>,
	Lennart Poettering <lennart@...ttering.net>,
	Kay Sievers <kay.sievers@...y.org>,
	Kamezawa Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
	Johannes Weiner <hannes@...xchg.org>, Tejun Heo <tj@...nel.org>
Subject: Re: [PATCH v2] memcg: first step towards hierarchical controller

On 09/03/2012 09:08 PM, Michal Hocko wrote:
> On Mon 03-09-12 19:46:51, Glauber Costa wrote:
>> Here is a new attempt to lay down a path that will allow us to deprecate
>> the non-hierarchical mode of operation from memcg.  Unlike what I posted
>> before, I am making this behavior conditional on a Kconfig option.
>> Vanilla users will see no change in behavior unless they don't
>> explicitly set this option to on.
> 
> Which is the reason why I don't like this approach. Why would you enable
> the option in the first place? If you know the default should be 1 then
> you would already do that via cgconfig or directly, right?
> I think we should either change the default (which I am planning to do
> for the next OpenSUSE) or do it slow way suggested by Tejun.
> We really want to have as big testing coverage as possible for the
> default change and config option is IMHO not a way to accomplish this.
> 

Not sure you realize, Michal, but you actually agree with me and my
patch, given your reasoning.

If you plan to change it in OpenSUSE, you have two ways of doing so:
You either carry a patch, which as simple as this is, is always
undesirable, or you add one line to your distro config. Pick my patch,
and do the later.

This patch does exactly the "do it slowly" thing, but without
introducing more churn, like mount options. Keep in mind that since
there is the concern that direct upstream users won't see a sudden
change in behavior, *every* way we choose to do it will raise the same
question you posed: "Why would you enable this in the first place?" Be
it a Kconfig, mount option, etc. The solution here is: Direct users of
upstream kernels won't see a behavior change - as requested - but
distributors will have a way to flip it without carrying a non-upstream
patch.

>> Distributions, however, are encouraged to set it.  
> 
> As I said, I plan to change the default with WARN_ONCE for both first
> cgroup created and default changed. It would be nice if other
> distributions could do the same but this might be tricky as nobody wants
> to regress and there are certain usecases which could really suffer
> (most of them fixable easily but there still might be some where
> use_hierarchy=0 is valid).
> 

tip: They can do the same without applying a non-upstream patch by using
this patch and just changing their default config.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/