linux-kernel - Re: [PATCH v2 14/14] Change CPUACCT to default n

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: <4ECE731E.6030508@parallels.com>
Date:	Thu, 24 Nov 2011 14:38:54 -0200
From:	Glauber Costa <glommer@...allels.com>
To:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
CC:	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
	Balbir Singh <bsingharora@...il.com>,
	Paul Turner <pjt@...gle.com>, <linux-kernel@...r.kernel.org>,
	<paul@...lmenage.org>, <lizf@...fujitsu.com>,
	<daniel.lezcano@...e.fr>, <jbottomley@...allels.com>,
	<fweisbec@...il.com>
Subject: Re: [PATCH v2 14/14] Change CPUACCT to default n

On 11/24/2011 02:29 PM, Peter Zijlstra wrote:
> On Thu, 2011-11-24 at 14:07 -0200, Glauber Costa wrote:
>> OTOH, if the use case for it includes separating processes for the cpu
>> and cpuacct cgroups in an independent manner - which apparently it does,
>> I've just learned, there isn't much we can do except try to make it cheaper.
>
> Yeah it allows that, but is that really useful? If we buy that argument
> shouldn't we split up controllers to be as minimal as possible to that
> you get as great a number of independent cgroups as possible?
>
> That way lies madness if you ask me. The two biggest controllers we
> currently have are cpu and memcg, and they aren't as orthogonal as you
> might think, see how cpusets has both a task affinity as well as node
> affinity side.
>
> The more comprehensive these controllers become, the greater also the
> overlap in functionality and thus a reduction in separation.
>
> Really, what is the killer case for separating all this nonsense? And
> no: 'Because $ustomer wants it', doesn't count.

It's hard for me to say that, since I come from a virtualization 
background: for us, a single cgroup would do just fine: even the 
division between mem and cpu is not needed. However, I've been learning 
recently that the use cases for that are quite diverse. So I'll have to 
leave the answer to Balbir, and other interested parties.

Furthermore, what I have to be implemented can be done with either one: 
I am really just bouncing around the two implementations trying to find 
a common ground... (*)

However, now that there are users for it, if this use case is really 
important, it gets harder to change it. That's more like a lesson for 
the future, for the new cgroups being proposed.

But even here, if we start adopting the policy of "cgroups must have 
zero impact for the mounted-but-not-used case, what's so wrong in having 
many small ones if their purpose differ? (more of a rethorical question)

* I wonder if the first part of the patches, that changes kstat to an 
array instead of u64 could be merged in this mean time? I have now a 
both task_group and cpuacct implementation and they both depend on it 
somehow. Peter? Paul ?
--
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/