Paul Menage wrote: > [RFC] Support multiply-bindable cgroup subsystems > > This patch allows a cgroup subsystem to be marked as bindable on > multiple cgroup hierarchies independently, when declared in > cgroup_subsys.h via MULTI_SUBSYS() rather than SUBSYS(). > > The state for such subsystems cannot be accessed directly from a > task->cgroups (since there's no unique mapping for a task) but instead > must be accessed via a particular control group object. > > Multiply-bound subsystems are useful in cases where there's no direct > correspondence between the cgroup configuration and some property of > the kernel outside of the cgroups subsystem. So this would not be > applicable to e.g. the CFS cgroup, since there has to a unique mapping > from a task to its CFS run queue. > > As an example, the "debug" subsystem is marked multiply-bindable, > since it has no state outside the cgroups framework itself. > Great, this makes the debug subsystem more useful. Sometimes I want to see some debug info in different hierarchies, but I can't just because it can only be bound to one hierarchy. > Example usage: > > mount -t cgroup -o name=foo,debug,cpu cgroup /mnt1 > mount -t cgroup -o name=bar,debug,memory cgroup /mnt2 > > Open Issues: > > - in the current version of this patch, mounting a cgroups hierarchy > with no options does *not* get you any of the multi-bindable > subsystems; possibly for consistency it should give you all of the > multi-bindable subsystems as well as all of the single-bindable > subsystems. > Yeah, the latter is preferrable. > - how can we avoid the checkpatch.pl errors due to creative use of > macros to generate enum names? checkpatch.pl can sometimes generate false-positive, let's happily ignore those "errors". ;) But it whould be better if those macros can be handled in a cleaner way. _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers
