On Thu, Feb 28, 2008 at 1:40 PM, Andrew Morton
<akpm@linux-foundation.org> wrote:
Well, that API (mixing control files and group directories in the same
directory namespace) was inherited directly from cpusets.
It wouldn't be hard to throw that away and move all the user-created
group directories into their own subdirectory, i.e. change the
existing directory layout from something like:
/mnt/cgroup/
tasks
cpu.shares
memory.limit_in_bytes
memory.usage_in_bytes
user_created_groupname1/
tasks
cpu.shares
memory.limit_in_bytes
memory.usage_in_bytes
user_created_groupname2/
tasks
cpu.shares
memory.limit_in_bytes
memory.usage_in_bytes
to something like:
/mnt/cgroup/
tasks
cpu.shares
memory.limit_in_bytes
memory.usage_in_bytes
groups/
user_created_groupname1/
tasks
cpu.shares
memory.limit_in_bytes
memory.usage_in_bytes
groups/
user_created_groupname2/
tasks
cpu.shares
memory.limit_in_bytes
memory.usage_in_bytes
groups/
That would completely solve the namespace problem, at the cost of a
little extra verbosity/inelegance for human users (I suspect
programmatic users would prefer it), and lack of compatibility with
2.6.24. I'd also need to make the existing model a mount option so
that we could keep compatibility with the cpusets filesystem API.
Pretty much the same as cpusets, other than the additional
kernel-generated files in each directory, as provided by the resource
subsystems. So the same potential problem faced cpusets, but the fact
that new cpuset features weren't being developed quickly meant the
problem was less likely to actually bite people.
Paul
--
