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@xxxxxxxxxxxxxx> 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 > > > _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers
