[Devel] Re: [PATCH 6/7] [RFC] Support multiply-bindable cgroup subsystems

[Balbir Singh]

* Li Zefan <lizf at cn.fujitsu.com> [2009-03-18 11:09:27]:

> CC: Balbir Singh
> 
> Paul Menage wrote:
> > On Tue, Mar 17, 2009 at 7:39 PM, Li Zefan <lizf at cn.fujitsu.com> wrote:
> >>> - always display one line for each subsystem; if a subsystem is
> >>> multiply-bindable then the "hierarchy id" and "num cgroups" columns
> >>> may be empty or have multiple (comma or slash-separated?) values
> >>>
> >> Then "hierarchy id" is no long a single number..
> > 
> > Correct.
> > 
> >>> - for a multiply-bindable subsystem, have a header line to indicate
> >>> that the subsystem exists, and then a separate line for each bound
> >>> instance of the subsystem.
> >>>
> >> I think it's better to show every subsystems including debug_subsys in
> >> /proc/cgroups, and show exactly n lines of debug_susys if we have n
> >> hierarcies with debug_subsys binded, but no header line.
> > 
> > But that gives a contradiction when n == 0 - we can't show exactly 0
> > lines for an unbound multi subsys, and still show every subsystem.
> > 
> 
> I don't see what's wrong with this behavior:
> 
> multi subsys sits in rootnode if it's unbound, and is removed from
> rootnode if it's binded at least in one hierarchy.
> 
> > Does libcgroup actually parse /proc/cgroup? If not, maybe we should
> 
> Balbir may answer this. :)

We do parse /proc/cgroups to see what controllers/subsystems we have
and if they are enabled.

> 
> > just break the format now and replace it with something more
> > extensible for future changes.
> > 
> 
> Even /proc/cgroup is ok, I don't think we can break this based on assumption
> that on one is making use of /proc/cgroups. :(
>

If fields are not removed I don't see an issue. I would however
recommend version of /proc/cgroups, like we do for /proc/slabinfo in
the future. Versioning does not allow us to remove fields, but
addition can be handled in that manner. 

-- 
	Balbir
_______________________________________________
Containers mailing list
Containers at lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers