Messages in this thread | | | Date | Thu, 7 Jan 2010 03:04:38 -0500 | From | Ben Blum <> | Subject | 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 <bblum@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_name hierarchy 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 > > >
| |