Re: [mm] [PATCH 4/4] Memory cgroup hierarchy feature selector

[Balbir Singh]

Paul Menage wrote:
> On Sun, Nov 2, 2008 at 7:52 AM, Balbir Singh <balbir@xxxxxxxxxxxxxxxxxx> wrote:
>> That should not be hard, but having it per-subtree sounds a little complex in
>> terms of exploiting from the end-user perspective and from symmetry perspective
>> (the CPU cgroup controller provides hierarchy control for the full hierarchy).
>>
> 
> The difference is that the CPU controller works in terms of shares,
> whereas memory works in terms of absolute memory size. So it pretty
> much has to limit the hierarchy to a single tree. Also, I didn't think
> that you could modify the shares for the root cgroup - what would that
> mean if so?
> 

The shares are proportional for the CPU controller. I am confused as to which
shares (CPU you are talking about?

> With this patch set as it is now, the root cgroup's lock becomes a
> global memory allocation/deallocation lock, which seems a bit painful.

Yes, true, but then that is the cost associated with using a hierarchy.

> Having a bunch of top-level cgroups each with their own independent
> memory limits, and allowing sub cgroups of them to be constrained by
> the parent's memory limit, seems more useful than a single hierarchy
> connected at the root.

That is certainly do-able, but can be confusing to users, given how other
controllers work. We can document that

> 
> In what realistic circumstances do you actually want to limit the root
> cgroup's memory usage?
> 

Good point, I would expect that people would mostly use the hierarchy with
soft-limits or shares. I am now beginning to like Kamezawa and your suggestion
of limiting usage to subtrees.


-- 
	Balbir
--
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/