OpenVZ Forum - RDF feed
type: channel
items: [RFC] Control Groups Roadmap ideas
items: Re: [RFC] Control Groups Roadmap ideas

[RFC] Control Groups Roadmap ideas
type: item
description: This is a list of some of the sub-projects that I'm planning for Control Groups, or that I know others are planning on or working on. Any comments or suggestions are welcome. 1) Stateless subsystems ----- This was motivated by the recent "freezer" subsystem proposal, which included a facility for sending signals to all members of a cgroup. This wasn't specifically freezer-related, and wasn't even something that needed particular per-cgroup state - its only state is that set of processes, which is already tracked by crgoups. So it could theoretically be mounted on multiple hierarchies at once, and wouldn't need an entry in the css_set array. This would require a few internal plumbing changes in cgroups, in particular: - hashing css_set objects based on their cgroups rather than their css pointers - allowing stateless subsystems to be in multiple hierarchies - changing the way hierarchy ids are calculated - simply ORing together the subsystem would no longer work since that could result in duplicates 2) More flexible binding/unbinding/rebinding ----- Currently you can only add/remove subsystems to a hierarchy when it has just a single (root) cgroup. This is a bit inflexible, so I'm planning to support: - adding a subsystem to an existing hierarchy by automatically creating a subsys state object for the new subsystem for each existing cgroup in the hierarchy and doing the appropriate can_attach()/attach_tasks() callbacks for all tasks in the system - removing a subsystem from an existing hierarchy by moving all tasks to that subsystem's root cgroup and destroying the child subsystem state objects - merging two existing hierarchies that have identical cgroup trees - (maybe) splitting one hierarchy into two separate hierarchies Whether all these operations should be forced through the mount() system call, or whether they should be done via operations on cgroup control files, is something I've not figured out yet. 3) Subsystem dependencies ----- This would be a fairly sim…
creator: Paul Menage
date: 2008-04-08T21:14:08-00:00

Re: [RFC] Control Groups Roadmap ideas
type: item
description: Paul Menage wrote: > 3) Subsystem dependencies > ----- > > This would be a fairly simple change, essentially allowing one > subsystem to require that it only be mounted on a hierarchy when some > other subsystem was also present. The implementation would probably be > a callback that allows a subsystem to confirm whether it's prepared to > be included in a proposed hierarchy containing a specified subsystem > bitmask; it would be able to prevent the hierarchy from being created > by giving an error return. An example of a use for this would be a > swap subsystem that is mostly independent of the memory controller, > but uses the page-ownership tracking of the memory controller to > determine which cgroup to charge swap pages to. Hence it would require > that it only be mounted on a hierarchy that also included a memory > controller. The memory controller would make no such requirement by > itself, so could be used on its own without the swap controller. > Sounds good, and I wrote a prototype in a quick: diff --git a/include/linux/cgroup.h b/include/linux/cgroup.h index a6a6035..091bc21 100644 --- a/include/linux/cgroup.h +++ b/include/linux/cgroup.h @@ -254,6 +254,7 @@ struct cgroup_subsys { struct cgroup *cgrp); void (*post_clone)(struct cgroup_subsys *ss, struct cgroup *cgrp); void (*bind)(struct cgroup_subsys *ss, struct cgroup *root); + int (*can_mount)(struct cgroup_subsys *ss, unsigned long subsys_bits); int subsys_id; int active; int disabled; diff --git a/kernel/cgroup.c b/kernel/cgroup.c index 62f1a52..3d43ff2 100644 --- a/kernel/cgroup.c +++ b/kernel/cgroup.c @@ -824,6 +824,25 @@ static int parse_cgroupfs_options(char *data, return 0; } +static int check_mount(unsigned long subsys_bits) +{ + int i; + int ret; + struct cgroup_subsys *ss; + + for (i = 0; i < CGROUP_SUBSYS_COUNT; i++) { + ss = subsys[i]; + + if (test_bit(i, &subsys_bits) && ss->can_mount) { + ret = ss->can_mount(ss, subsys_bits); + if (ret) + return ret; + } + } + + return 0; +} + static int …
creator: Li Zefan
date: 2008-04-09T02:28:15-00:00

Re: [RFC] Control Groups Roadmap ideas
type: item
description: On Tue, Apr 8, 2008 at 7:28 PM, Li Zefan <lizf@cn.fujitsu.com> wrote: > > Sounds good, and I wrote a prototype in a quick: Yes, that's pretty much what I was envisaging, thanks. Paul > > diff --git a/include/linux/cgroup.h b/include/linux/cgroup.h > index a6a6035..091bc21 100644 > --- a/include/linux/cgroup.h > +++ b/include/linux/cgroup.h > @@ -254,6 +254,7 @@ struct cgroup_subsys { > struct cgroup *cgrp); > void (*post_clone)(struct cgroup_subsys *ss, struct cgroup *cgrp); > void (*bind)(struct cgroup_subsys *ss, struct cgroup *root); > + int (*can_mount)(struct cgroup_subsys *ss, unsigned long subsys_bits); > int subsys_id; > int active; > int disabled; > diff --git a/kernel/cgroup.c b/kernel/cgroup.c > index 62f1a52..3d43ff2 100644 > --- a/kernel/cgroup.c > +++ b/kernel/cgroup.c > @@ -824,6 +824,25 @@ static int parse_cgroupfs_options(char *data, > return 0; > } > > +static int check_mount(unsigned long subsys_bits) > +{ > + int i; > + int ret; > + struct cgroup_subsys *ss; > + > + for (i = 0; i < CGROUP_SUBSYS_COUNT; i++) { > + ss = subsys[i]; > + > + if (test_bit(i, &subsys_bits) && ss->can_mount) { > + ret = ss->can_mount(ss, subsys_bits); > + if (ret) > + return ret; > + } > + } > + > + return 0; > +} > + > static int cgroup_remount(struct super_block *sb, int *flags, char *data) > { > int ret = 0; > @@ -839,6 +858,10 @@ static int cgroup_remount(struct super_block *sb, int *flags, char *data) > if (ret) > goto out_unlock; > > + ret = check_mount(opts.subsys_bits); > + if (ret) > + goto out_unlock; > + > /* Don't allow flags to change at remount */ > if (opts.flags != root->flags) { > ret = -EINVAL; > @@ -959,6 +982,13 @@ static int cgroup_get_sb(struct file_system_type *fs_type, > return ret; > } > > + ret = check_mount(opts.subsys_bits); > + if (ret) { > + if (opts.release_agent) > + kfree(opts.release_agent); > + return ret; > + } > + > root = kzalloc(sizeof(*root), GFP_KERNEL); > if (!root) { > if (opts.release_agent) > ------- > > for the example about …
creator: Paul Menage
date: 2008-04-10T20:10:30-00:00

Re: [RFC] Control Groups Roadmap ideas
type: item
description: Quoting Paul Menage (menage@google.com): > This is a list of some of the sub-projects that I'm planning for > Control Groups, or that I know others are planning on or working on. > Any comments or suggestions are welcome. > > > 1) Stateless subsystems > ----- > > This was motivated by the recent "freezer" subsystem proposal, which > included a facility for sending signals to all members of a cgroup. > This wasn't specifically freezer-related, and wasn't even something > that needed particular per-cgroup state - its only state is that set > of processes, which is already tracked by crgoups. So it could > theoretically be mounted on multiple hierarchies at once, and wouldn't > need an entry in the css_set array. > > This would require a few internal plumbing changes in cgroups, in particular: > > - hashing css_set objects based on their cgroups rather than their css pointers > - allowing stateless subsystems to be in multiple hierarchies > - changing the way hierarchy ids are calculated - simply ORing > together the subsystem would no longer work since that could result in > duplicates > > 2) More flexible binding/unbinding/rebinding > ----- > > Currently you can only add/remove subsystems to a hierarchy when it > has just a single (root) cgroup. This is a bit inflexible, so I'm > planning to support: > > - adding a subsystem to an existing hierarchy by automatically > creating a subsys state object for the new subsystem for each existing > cgroup in the hierarchy and doing the appropriate > can_attach()/attach_tasks() callbacks for all tasks in the system > > - removing a subsystem from an existing hierarchy by moving all tasks > to that subsystem's root cgroup and destroying the child subsystem > state objects > > - merging two existing hierarchies that have identical cgroup trees > > - (maybe) splitting one hierarchy into two separate hierarchies > > Whether all these operations should be forced through the mount() > system call, or whether they should be done via …
creator: serue
date: 2008-04-11T14:48:36-00:00

Re: [RFC] Control Groups Roadmap ideas
type: item
description: On Fri, Apr 11, 2008 at 8:18 PM, Serge E. Hallyn <serue@us.ibm.com> wrote: > > Quoting Paul Menage (menage@google.com): > > This is a list of some of the sub-projects that I'm planning for > > Control Groups, or that I know others are planning on or working on. > > Any comments or suggestions are welcome. > > > > > > 1) Stateless subsystems > > ----- > > > > This was motivated by the recent "freezer" subsystem proposal, which > > included a facility for sending signals to all members of a cgroup. > > This wasn't specifically freezer-related, and wasn't even something > > that needed particular per-cgroup state - its only state is that set > > of processes, which is already tracked by crgoups. So it could > > theoretically be mounted on multiple hierarchies at once, and wouldn't > > need an entry in the css_set array. > > > > This would require a few internal plumbing changes in cgroups, in particular: > > > > - hashing css_set objects based on their cgroups rather than their css pointers > > - allowing stateless subsystems to be in multiple hierarchies > > - changing the way hierarchy ids are calculated - simply ORing > > together the subsystem would no longer work since that could result in > > duplicates > > > > 2) More flexible binding/unbinding/rebinding > > ----- > > > > Currently you can only add/remove subsystems to a hierarchy when it > > has just a single (root) cgroup. This is a bit inflexible, so I'm > > planning to support: > > > > - adding a subsystem to an existing hierarchy by automatically > > creating a subsys state object for the new subsystem for each existing > > cgroup in the hierarchy and doing the appropriate > > can_attach()/attach_tasks() callbacks for all tasks in the system > > > > - removing a subsystem from an existing hierarchy by moving all tasks > > to that subsystem's root cgroup and destroying the child subsystem > > state objects > > > > - merging two existing hierarchies that have identical cgroup trees > > > > - (maybe) splitting…
creator: Balbir Singh
date: 2008-04-12T05:10:26-00:00

Re: [RFC] Control Groups Roadmap ideas
type: item
description: Quoting Balbir Singh (balbir@linux.vnet.ibm.com): > On Fri, Apr 11, 2008 at 8:18 PM, Serge E. Hallyn <serue@us.ibm.com> wrote: > > > > Quoting Paul Menage (menage@google.com): > > > This is a list of some of the sub-projects that I'm planning for > > > Control Groups, or that I know others are planning on or working on. > > > Any comments or suggestions are welcome. > > > > > > > > > 1) Stateless subsystems > > > ----- > > > > > > This was motivated by the recent "freezer" subsystem proposal, which > > > included a facility for sending signals to all members of a cgroup. > > > This wasn't specifically freezer-related, and wasn't even something > > > that needed particular per-cgroup state - its only state is that set > > > of processes, which is already tracked by crgoups. So it could > > > theoretically be mounted on multiple hierarchies at once, and wouldn't > > > need an entry in the css_set array. > > > > > > This would require a few internal plumbing changes in cgroups, in particular: > > > > > > - hashing css_set objects based on their cgroups rather than their css pointers > > > - allowing stateless subsystems to be in multiple hierarchies > > > - changing the way hierarchy ids are calculated - simply ORing > > > together the subsystem would no longer work since that could result in > > > duplicates > > > > > > 2) More flexible binding/unbinding/rebinding > > > ----- > > > > > > Currently you can only add/remove subsystems to a hierarchy when it > > > has just a single (root) cgroup. This is a bit inflexible, so I'm > > > planning to support: > > > > > > - adding a subsystem to an existing hierarchy by automatically > > > creating a subsys state object for the new subsystem for each existing > > > cgroup in the hierarchy and doing the appropriate > > > can_attach()/attach_tasks() callbacks for all tasks in the system > > > > > > - removing a subsystem from an existing hierarchy by moving all tasks > > > to that subsystem's root cgroup and destroying the child…
creator: serue
date: 2008-04-13T16:11:27-00:00

Re: [RFC] Control Groups Roadmap ideas
type: item
description: On Fri, Apr 11, 2008 at 7:48 AM, Serge E. Hallyn <serue@us.ibm.com> wrote: > > 2) More flexible binding/unbinding/rebinding > > ----- > > > > Currently you can only add/remove subsystems to a hierarchy when it > > has just a single (root) cgroup. This is a bit inflexible, so I'm > > planning to support: > > > > - adding a subsystem to an existing hierarchy by automatically > > creating a subsys state object for the new subsystem for each existing > > cgroup in the hierarchy and doing the appropriate > > can_attach()/attach_tasks() callbacks for all tasks in the system > > > > - removing a subsystem from an existing hierarchy by moving all tasks > > to that subsystem's root cgroup and destroying the child subsystem > > state objects > > > > - merging two existing hierarchies that have identical cgroup trees > > > > - (maybe) splitting one hierarchy into two separate hierarchies > > > > Whether all these operations should be forced through the mount() > > system call, or whether they should be done via operations on cgroup > > control files, is something I've not figured out yet. > > I'm tempted to ask what the use case is for this (I assume you have one, > you don't generally introduce features for no good reason), but it Back during the early versions of control groups, Paul Jackson proposed a bind/unbind API that would let you affect the subsystems on an active hierarchy, and it was always a goal of mine to implement that - current inflexibility is something that I've never been that keen on, but it was OK for the first big release and could be extended later. One of the potential scenarios was that you might want to have a very early boot script set up cpusets and node isolation for a set of system daemons, and then bind other subsystems on to the same hierarchy later in the boot process. > I'd stick with mount semantics. Just > mount -t cgroup -o remount,devices,cpu none /devwh" > should handle all cases, no? Yes, probably - particularly if we restrict it to addi…
creator: Paul Menage
date: 2008-04-14T05:24:56-00:00

Re: [RFC] Control Groups Roadmap ideas
type: item
description: Quoting Paul Menage (menage@google.com): > On Fri, Apr 11, 2008 at 7:48 AM, Serge E. Hallyn <serue@us.ibm.com> wrote: > > > 2) More flexible binding/unbinding/rebinding > > > ----- > > > > > > Currently you can only add/remove subsystems to a hierarchy when it > > > has just a single (root) cgroup. This is a bit inflexible, so I'm > > > planning to support: > > > > > > - adding a subsystem to an existing hierarchy by automatically > > > creating a subsys state object for the new subsystem for each existing > > > cgroup in the hierarchy and doing the appropriate > > > can_attach()/attach_tasks() callbacks for all tasks in the system > > > > > > - removing a subsystem from an existing hierarchy by moving all tasks > > > to that subsystem's root cgroup and destroying the child subsystem > > > state objects > > > > > > - merging two existing hierarchies that have identical cgroup trees > > > > > > - (maybe) splitting one hierarchy into two separate hierarchies > > > > > > Whether all these operations should be forced through the mount() > > > system call, or whether they should be done via operations on cgroup > > > control files, is something I've not figured out yet. > > > > I'm tempted to ask what the use case is for this (I assume you have one, > > you don't generally introduce features for no good reason), but it > > Back during the early versions of control groups, Paul Jackson > proposed a bind/unbind API that would let you affect the subsystems on > an active hierarchy, and it was always a goal of mine to implement > that - current inflexibility is something that I've never been that > keen on, but it was OK for the first big release and could be extended > later. > > One of the potential scenarios was that you might want to have a very > early boot script set up cpusets and node isolation for a set of > system daemons, and then bind other subsystems on to the same > hierarchy later in the boot process. > > > I'd stick with mount semantics. Just > > mount -t cgr…
creator: serue
date: 2008-04-14T14:11:19-00:00

Re: [RFC] Control Groups Roadmap ideas
type: item
description: Serge E. Hallyn wrote: > Quoting Balbir Singh (balbir@linux.vnet.ibm.com): >> On Fri, Apr 11, 2008 at 8:18 PM, Serge E. Hallyn <serue@us.ibm.com> wrote: >>> Quoting Paul Menage (menage@google.com): >>> > This is a list of some of the sub-projects that I'm planning for >>> > Control Groups, or that I know others are planning on or working on. >>> > Any comments or suggestions are welcome. >>> > >>> > >>> > 1) Stateless subsystems >>> > ----- >>> > >>> > This was motivated by the recent "freezer" subsystem proposal, which >>> > included a facility for sending signals to all members of a cgroup. >>> > This wasn't specifically freezer-related, and wasn't even something >>> > that needed particular per-cgroup state - its only state is that set >>> > of processes, which is already tracked by crgoups. So it could >>> > theoretically be mounted on multiple hierarchies at once, and wouldn't >>> > need an entry in the css_set array. >>> > >>> > This would require a few internal plumbing changes in cgroups, in particular: >>> > >>> > - hashing css_set objects based on their cgroups rather than their css pointers >>> > - allowing stateless subsystems to be in multiple hierarchies >>> > - changing the way hierarchy ids are calculated - simply ORing >>> > together the subsystem would no longer work since that could result in >>> > duplicates >>> > >>> > 2) More flexible binding/unbinding/rebinding >>> > ----- >>> > >>> > Currently you can only add/remove subsystems to a hierarchy when it >>> > has just a single (root) cgroup. This is a bit inflexible, so I'm >>> > planning to support: >>> > >>> > - adding a subsystem to an existing hierarchy by automatically >>> > creating a subsys state object for the new subsystem for each existing >>> > cgroup in the hierarchy and doing the appropriate >>> > can_attach()/attach_tasks() callbacks for all tasks in the system >>> > >>> > - removing a subsystem from an existing hierarchy by moving all tasks >>> > to that subsystem's root cgroup an…
creator: Balbir Singh
date: 2008-04-14T14:31:02-00:00

Re: [RFC] Control Groups Roadmap ideas
type: item
description: On Mon, Apr 14, 2008 at 7:11 AM, Serge E. Hallyn <serue@us.ibm.com> wrote: > > then all tasks are mapped under /containers. If login does a > clone(CLONE_NEWNS) for hallyn's login to give him a private /tmp, > then hallyn ends up under /containers/node_xyz, but we don't want him > to be virtualized under there. So I assume we'd want a virt.lock file > or something like that so, that when I create a container, my > start_container script can echo 1 > /containers/node_abc/virt.lock Yes, something like that. > > I assume the container will also have to remount a fresh copy of the > cgroup composition so it can have the dentry for /containers/node_abc > as the root dentry for /containers? Yes. Paul _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Paul Menage
date: 2008-04-14T15:03:57-00:00