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

[Peter Zijlstra]

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