On Thu, Feb 28, 2008 at 1:40 PM, Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote: > > Maybe cgroups shouldn't be putting kernel-generated files in places where > user-specified files appear? > 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. > (Am still thrashing around a bit here without an overview of the overall > layout and naming). 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 _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers