[Devel] Re: [PATCH v4 0/4] cgroups: support for module-loadable subsystems
On Thu, Jan 07, 2010 at 04:51:17PM +0900, KAMEZAWA Hiroyuki wrote: On Thu, 7 Jan 2010 02:48:12 -0500 Ben Blum bb...@andrew.cmu.edu wrote: 2. Making this to be reasonable value. #define CGROUP_SUBSYS_COUNT (BITS_PER_BYTE*sizeof(unsigned long)) I can't find why. We limit to this many since cgroupfs_root has subsys_bits to keep track of all of them. should it be less, perhaps? It's ok if it's clear that this decistion is done by implementation choice, not by cgroup's nature mhm, well, it is the upper limit due to nature, but why it and not a smaller number is by choice. the memory footprint is not great, it is true, but implementing dynamically sized subsystem tracking data structures requires much cleverer code in many places. yes. I don't request that. it might be possible to have a config option as CGROUP_EXTRA_SUBSYSTEMS (with max being 64 or 32) which would add slots for subsystems outside of the kernel tree, to avoid using up a lot of blank slots in typical use cases. not entirely sure how to implement it in the scope of the configuration world, just speculation. 3. show whehter a subsys is a loadable module or not via /proc/cgroups with just y or n? possible, and probably easy. do note that since they are sorted by subsys_id, all the ones above a certain line will be n and all below will be y. yes. #subsys_namehierarchy num_cgroups enabled module cpuset 0 1 1 0 and 0/1 to show y/n ? (but this cause interface incompatibility...) well, format should be agreed upon. 1/0 would be consistent with the rest of the output. Thanks, -Kame ___ Containers mailing list contain...@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers ___ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel
[Devel] Re: [PATCH v4 0/4] cgroups: support for module-loadable subsystems
On Thu, Jan 07, 2010 at 02:42:19PM +0800, Li Zefan wrote: KAMEZAWA Hiroyuki wrote: On Wed, 6 Jan 2010 20:26:06 -0500 Ben Blum bb...@andrew.cmu.edu wrote: On Wed, Jan 06, 2010 at 04:04:14PM -0800, Andrew Morton wrote: On Thu, 31 Dec 2009 00:10:50 -0500 Ben Blum bb...@andrew.cmu.edu wrote: This patch series implements support for building, loading, and unloading subsystems as modules, both within and outside the kernel source tree. It provides an interface cgroup_load_subsys() and cgroup_unload_subsys() which modular subsystems can use to register and depart during runtime. The net_cls classifier subsystem serves as the example for a subsystem which can be converted into a module using these changes. What is the value in this? What are the usage scenarios? Why does the benefit of this change exceed the cost/risk/etc of merging it? As discussed in the first posting of these patches, this provides the ability for arbitrary subsystems to be used with cgroups.. cls_cgroup would have already been a module except for a lack of support from cgroups, and the change also allows other module-loadable classifiers to add subsystems of their own. Hmm, do you have your own module in plan ? Maybe the new blkio_cgroup can also be made module-able. certainly looks promising. one thing I note while looking over it is that it wants .use_id = 1, and the load_subsys interface neglects to make a call to init_idr. adding calls to cgroup_init_idr has a few possible complications... what use does blkio have for use_id? ___ Containers mailing list contain...@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers ___ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel
[Devel] Re: [PATCH v4 0/4] cgroups: support for module-loadable subsystems
On Thu, Jan 07, 2010 at 03:14:32AM -0500, Ben Blum wrote: On Thu, Jan 07, 2010 at 02:42:19PM +0800, Li Zefan wrote: KAMEZAWA Hiroyuki wrote: On Wed, 6 Jan 2010 20:26:06 -0500 Ben Blum bb...@andrew.cmu.edu wrote: On Wed, Jan 06, 2010 at 04:04:14PM -0800, Andrew Morton wrote: On Thu, 31 Dec 2009 00:10:50 -0500 Ben Blum bb...@andrew.cmu.edu wrote: This patch series implements support for building, loading, and unloading subsystems as modules, both within and outside the kernel source tree. It provides an interface cgroup_load_subsys() and cgroup_unload_subsys() which modular subsystems can use to register and depart during runtime. The net_cls classifier subsystem serves as the example for a subsystem which can be converted into a module using these changes. What is the value in this? What are the usage scenarios? Why does the benefit of this change exceed the cost/risk/etc of merging it? As discussed in the first posting of these patches, this provides the ability for arbitrary subsystems to be used with cgroups.. cls_cgroup would have already been a module except for a lack of support from cgroups, and the change also allows other module-loadable classifiers to add subsystems of their own. Hmm, do you have your own module in plan ? Maybe the new blkio_cgroup can also be made module-able. certainly looks promising. one thing I note while looking over it is that it wants .use_id = 1, and the load_subsys interface neglects to make a call to init_idr. adding calls to cgroup_init_idr has a few possible complications... what use does blkio have for use_id? oh, oops, while tracing the calls that init_idr does i ended up looking at the wrong functions and made it out to be harder than it was (in several places, even). still it would need to be included in load_subsys and the single error case handled appropriately. ___ Containers mailing list contain...@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers ___ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel
[Devel] Re: [PATCH v4 0/4] cgroups: support for module-loadable subsystems
On Thu, Jan 07, 2010 at 02:42:19PM +0800, Li Zefan wrote: KAMEZAWA Hiroyuki wrote: On Wed, 6 Jan 2010 20:26:06 -0500 Ben Blum bb...@andrew.cmu.edu wrote: On Wed, Jan 06, 2010 at 04:04:14PM -0800, Andrew Morton wrote: On Thu, 31 Dec 2009 00:10:50 -0500 Ben Blum bb...@andrew.cmu.edu wrote: This patch series implements support for building, loading, and unloading subsystems as modules, both within and outside the kernel source tree. It provides an interface cgroup_load_subsys() and cgroup_unload_subsys() which modular subsystems can use to register and depart during runtime. The net_cls classifier subsystem serves as the example for a subsystem which can be converted into a module using these changes. What is the value in this? What are the usage scenarios? Why does the benefit of this change exceed the cost/risk/etc of merging it? As discussed in the first posting of these patches, this provides the ability for arbitrary subsystems to be used with cgroups.. cls_cgroup would have already been a module except for a lack of support from cgroups, and the change also allows other module-loadable classifiers to add subsystems of their own. Hmm, do you have your own module in plan ? Maybe the new blkio_cgroup can also be made module-able. Ok, the following two patches make this happen (or at least pretend to well enough to fool me). The first one adds use_id initialization in cgroup_load_subsys, and the second rearranges config options and some code as appropriate in block/ and adds EXPORT_SYMBOLs in cgroup.c. -- bblum --- block/Kconfig |2 - block/Kconfig.iosched |2 - block/blk-cgroup.c| 53 +++--- block/blk-cgroup.h| 10 ++-- include/linux/iocontext.h |2 - kernel/cgroup.c | 31 +- 6 files changed, 77 insertions(+), 23 deletions(-) ___ Containers mailing list contain...@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers ___ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel
[Devel] Re: [PATCH v4 0/4] cgroups: support for module-loadable subsystems
On Thu, 31 Dec 2009 00:10:50 -0500 Ben Blum bb...@andrew.cmu.edu wrote: This patch series implements support for building, loading, and unloading subsystems as modules, both within and outside the kernel source tree. It provides an interface cgroup_load_subsys() and cgroup_unload_subsys() which modular subsystems can use to register and depart during runtime. The net_cls classifier subsystem serves as the example for a subsystem which can be converted into a module using these changes. What is the value in this? What are the usage scenarios? Why does the benefit of this change exceed the cost/risk/etc of merging it? ___ Containers mailing list contain...@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers ___ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel
[Devel] Re: [PATCH v4 0/4] cgroups: support for module-loadable subsystems
On Wed, Jan 06, 2010 at 04:04:14PM -0800, Andrew Morton wrote: On Thu, 31 Dec 2009 00:10:50 -0500 Ben Blum bb...@andrew.cmu.edu wrote: This patch series implements support for building, loading, and unloading subsystems as modules, both within and outside the kernel source tree. It provides an interface cgroup_load_subsys() and cgroup_unload_subsys() which modular subsystems can use to register and depart during runtime. The net_cls classifier subsystem serves as the example for a subsystem which can be converted into a module using these changes. What is the value in this? What are the usage scenarios? Why does the benefit of this change exceed the cost/risk/etc of merging it? As discussed in the first posting of these patches, this provides the ability for arbitrary subsystems to be used with cgroups.. cls_cgroup would have already been a module except for a lack of support from cgroups, and the change also allows other module-loadable classifiers to add subsystems of their own. ___ Containers mailing list contain...@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers ___ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel
[Devel] Re: [PATCH v4 0/4] cgroups: support for module-loadable subsystems
On Wed, 6 Jan 2010 20:26:06 -0500 Ben Blum bb...@andrew.cmu.edu wrote: On Wed, Jan 06, 2010 at 04:04:14PM -0800, Andrew Morton wrote: On Thu, 31 Dec 2009 00:10:50 -0500 Ben Blum bb...@andrew.cmu.edu wrote: This patch series implements support for building, loading, and unloading subsystems as modules, both within and outside the kernel source tree. It provides an interface cgroup_load_subsys() and cgroup_unload_subsys() which modular subsystems can use to register and depart during runtime. The net_cls classifier subsystem serves as the example for a subsystem which can be converted into a module using these changes. What is the value in this? What are the usage scenarios? Why does the benefit of this change exceed the cost/risk/etc of merging it? As discussed in the first posting of these patches, this provides the ability for arbitrary subsystems to be used with cgroups.. cls_cgroup would have already been a module except for a lack of support from cgroups, and the change also allows other module-loadable classifiers to add subsystems of their own. Hmm, do you have your own module in plan ? Thanks, -Kame ___ Containers mailing list contain...@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers ___ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel
[Devel] Re: [PATCH v4 0/4] cgroups: support for module-loadable subsystems
KAMEZAWA Hiroyuki wrote: On Wed, 6 Jan 2010 20:26:06 -0500 Ben Blum bb...@andrew.cmu.edu wrote: On Wed, Jan 06, 2010 at 04:04:14PM -0800, Andrew Morton wrote: On Thu, 31 Dec 2009 00:10:50 -0500 Ben Blum bb...@andrew.cmu.edu wrote: This patch series implements support for building, loading, and unloading subsystems as modules, both within and outside the kernel source tree. It provides an interface cgroup_load_subsys() and cgroup_unload_subsys() which modular subsystems can use to register and depart during runtime. The net_cls classifier subsystem serves as the example for a subsystem which can be converted into a module using these changes. What is the value in this? What are the usage scenarios? Why does the benefit of this change exceed the cost/risk/etc of merging it? As discussed in the first posting of these patches, this provides the ability for arbitrary subsystems to be used with cgroups.. cls_cgroup would have already been a module except for a lack of support from cgroups, and the change also allows other module-loadable classifiers to add subsystems of their own. Hmm, do you have your own module in plan ? Maybe the new blkio_cgroup can also be made module-able. ___ Containers mailing list contain...@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers ___ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel
[Devel] Re: [PATCH v4 0/4] cgroups: support for module-loadable subsystems
On Thu, 07 Jan 2010 14:42:19 +0800
Li Zefan l...@cn.fujitsu.com wrote:
KAMEZAWA Hiroyuki wrote:
On Wed, 6 Jan 2010 20:26:06 -0500
Ben Blum bb...@andrew.cmu.edu wrote:
On Wed, Jan 06, 2010 at 04:04:14PM -0800, Andrew Morton wrote:
On Thu, 31 Dec 2009 00:10:50 -0500
Ben Blum bb...@andrew.cmu.edu wrote:
This patch series implements support for building, loading, and
unloading subsystems as modules, both within and outside the kernel
source tree. It provides an interface cgroup_load_subsys() and
cgroup_unload_subsys() which modular subsystems can use to register and
depart during runtime. The net_cls classifier subsystem serves as the
example for a subsystem which can be converted into a module using these
changes.
What is the value in this? What are the usage scenarios? Why does the
benefit of this change exceed the cost/risk/etc of merging it?
As discussed in the first posting of these patches, this provides the
ability for arbitrary subsystems to be used with cgroups.. cls_cgroup
would have already been a module except for a lack of support from
cgroups, and the change also allows other module-loadable classifiers
to add subsystems of their own.
Hmm, do you have your own module in plan ?
Maybe the new blkio_cgroup can also be made module-able.
Hmm, I read the patch slightly. I'm not enough expert to review this patch..
I requst following as TODO.
(No objection to the direction/patch.)
1. Add documentation about load/unlod module.
It seems module unloading will not succuess while subsystem is mounted.
Right ?
2. Making this to be reasonable value.
#define CGROUP_SUBSYS_COUNT (BITS_PER_BYTE*sizeof(unsigned long))
I can't find why.
3. show whehter a subsys is a loadable module or not via /proc/cgroups
4. how to test ? load/unload NET_CLS is enough ?
Last one is question.
5. Is following path is safe ?
find_css_set() {
read_lock(css_set_lock);
get template including pointer
read_unlock(css_set_lock);
use template to build new css_set.
Thanks,
-Kame
___
Containers mailing list
contain...@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers
___
Devel mailing list
Devel@openvz.org
https://openvz.org/mailman/listinfo/devel
[Devel] Re: [PATCH v4 0/4] cgroups: support for module-loadable subsystems
On Thu, Jan 07, 2010 at 04:16:27PM +0900, KAMEZAWA Hiroyuki wrote:
On Thu, 07 Jan 2010 14:42:19 +0800
Li Zefan l...@cn.fujitsu.com wrote:
KAMEZAWA Hiroyuki wrote:
On Wed, 6 Jan 2010 20:26:06 -0500
Ben Blum bb...@andrew.cmu.edu wrote:
On Wed, Jan 06, 2010 at 04:04:14PM -0800, Andrew Morton wrote:
On Thu, 31 Dec 2009 00:10:50 -0500
Ben Blum bb...@andrew.cmu.edu wrote:
This patch series implements support for building, loading, and
unloading subsystems as modules, both within and outside the kernel
source tree. It provides an interface cgroup_load_subsys() and
cgroup_unload_subsys() which modular subsystems can use to register and
depart during runtime. The net_cls classifier subsystem serves as the
example for a subsystem which can be converted into a module using
these
changes.
What is the value in this? What are the usage scenarios? Why does the
benefit of this change exceed the cost/risk/etc of merging it?
As discussed in the first posting of these patches, this provides the
ability for arbitrary subsystems to be used with cgroups.. cls_cgroup
would have already been a module except for a lack of support from
cgroups, and the change also allows other module-loadable classifiers
to add subsystems of their own.
Hmm, do you have your own module in plan ?
Maybe the new blkio_cgroup can also be made module-able.
Hmm, I read the patch slightly. I'm not enough expert to review this patch..
I requst following as TODO.
(No objection to the direction/patch.)
1. Add documentation about load/unlod module.
could perhaps use more, i suppose.
It seems module unloading will not succuess while subsystem is mounted.
Right ?
yes, when you mount it, it takes a reference on the module, so you get
module is in use.
2. Making this to be reasonable value.
#define CGROUP_SUBSYS_COUNT (BITS_PER_BYTE*sizeof(unsigned long))
I can't find why.
We limit to this many since cgroupfs_root has subsys_bits to keep track
of all of them. should it be less, perhaps? the memory footprint is not
great, it is true, but implementing dynamically sized subsystem tracking
data structures requires much cleverer code in many places.
3. show whehter a subsys is a loadable module or not via /proc/cgroups
with just y or n? possible, and probably easy. do note that since
they are sorted by subsys_id, all the ones above a certain line will be
n and all below will be y.
4. how to test ? load/unload NET_CLS is enough ?
load, mount, remount, unmount, mount with different combinations, unload
was the general approach I took, plus using gdb to examine state.
Last one is question.
5. Is following path is safe ?
find_css_set() {
read_lock(css_set_lock);
get template including pointer
read_unlock(css_set_lock);
use template to build new css_set.
should be, because that code is dealing with a cgrp's/css's specific
-subsys array, which state is protected by refcounts held by the
already mounted hierarchy, and the other entries in the array are not
cared about by the particular css in question.
Thanks,
-Kame
___
Containers mailing list
contain...@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers
___
Devel mailing list
Devel@openvz.org
https://openvz.org/mailman/listinfo/devel
[Devel] Re: [PATCH v4 0/4] cgroups: support for module-loadable subsystems
On Thu, 7 Jan 2010 02:48:12 -0500 Ben Blum bb...@andrew.cmu.edu wrote: 2. Making this to be reasonable value. #define CGROUP_SUBSYS_COUNT (BITS_PER_BYTE*sizeof(unsigned long)) I can't find why. We limit to this many since cgroupfs_root has subsys_bits to keep track of all of them. should it be less, perhaps? It's ok if it's clear that this decistion is done by implementation choice, not by cgroup's nature the memory footprint is not great, it is true, but implementing dynamically sized subsystem tracking data structures requires much cleverer code in many places. yes. I don't request that. 3. show whehter a subsys is a loadable module or not via /proc/cgroups with just y or n? possible, and probably easy. do note that since they are sorted by subsys_id, all the ones above a certain line will be n and all below will be y. yes. #subsys_namehierarchy num_cgroups enabled module cpuset 0 1 1 0 and 0/1 to show y/n ? (but this cause interface incompatibility...) Thanks, -Kame ___ Containers mailing list contain...@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers ___ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel
