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

[Balbir Singh <balbir@linux.vnet.ibm.com>]

Paul Menage wrote:
> On Sun, Nov 2, 2008 at 7:52 AM, Balbir Singh <balbir@linux.vnet.ibm.com> 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, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>