* Jan Safranek <[email protected]> [2009-01-27 16:56:10]:
> Hello,
>
> after playing a lot with configuration file for cgconfigparser I finally
> understood how the groups, mount points and subsystems (controllers)
> work together. But I am not sure if it is expected and user-friendly
> behavior.
>
> Let's say the user has following config file (sorry, it's a bit long):
>
> group cpu1 {
> perm {
> task {
> uid = jsafrane;
> gid = jsafrane;
> }
> admin {
> uid = root;
> gid = root;
> }
> }
> cpuset {
> }
> devices {
> devices.deny=a;
> }
> }
>
> group cpu1/cpu11 {
> cpuset{}
> }
>
> group cpu1/cpu12 {
> cpuset{}
> }
>
> mount {
> cpuset = /mnt/cgroups/cpu;
> devices = /mnt/cgroups/devices;
> }
>
> It's pretty simple - it creates /mnt/cgroups/cpu with 'cpuset' hierarchy
> and /mnt/cgroups/devices with 'devices'. So far so good.
>
> Now I have some problems understanding the groups. Looking at the config
> file, one would say that there is group cpu1 with two subgroups, cpu11
> and cpu12. And one would assume, that if cpu1 has denied access to all
> devices then also both subgroups have the access denied (as the kernel
> doc describes). But they don't! cpu11 and cpu12 are subgroups of cpu1
> only in hierarchy related to 'cpuset', they are not related to
> 'devices'. This is *very* inconvenient and it took me quite a time to
> realize what's wrong.
I agree with your view point, but we also realize that there will be
users demanding that flexibility.
>
> The whole concept of having mounts and groups separated is IMHO not user
> friendly. It's hard to say which groups are created in which hierarchies
> and what consequences it has. At least it does not correspond to final
> directory and kernel data structures.
>
As far as mount separation is concerned, the flexibility was required.
A set of tasks sharing CPU resources does not automatically entitle
them to share memory or IO resources. This flexibility has made user
space programming very hard, I agree.
> I would propose different config file structure, let's say something
> like this:
>
> mount cpuset,cpuacct {
> path=/mnt/cgroups/cpu;
> perm { /*... as usual ...*/ }
> group cpu1 { /*... parameters as usual */ }
> group cpu1/cpu11 { ... }
> /* other groups as needed */
> }
>
> mount devices {
> path = /mnt/cgroups/devices;
> perm { /* as usual */ }
> /* groups as needed */
> }
>
> This would ensure that the two hierarchies are separated and mapping to
> filesystem structure and back is clearly visible. A drawback might be
> that if a user wants to create groups in both hierarchies, he/she must
> create them twice.
>
> I studied the sources quickly and it seems to me it could be possible,
> but lot of things needs to be rewritten (e.g. most of the config.c) and
> internal data structures would change significantly. I'd volunteer to do
> that, if it's worth doing and you'd be interested in such rewrite. (Note
> it may take some time to me to do the rewrite, it's lot of code). Btw,
> XML config file would IMHO simplify lot of parsing and checking,
> wouldn't it?
>
I am not in favour of redoing the configuration file at this point in
time, but I don't mind supporting XML and tools to do things a little
differently, including allowing programs to append to the
configuration file. Changing the configuration file format after a
stable release 0.32 is very hard and even moving to XML is a big step
that should be considered only in a future release that might be far
far away :)
> On the other hand, I could write some documentation (man page?) about
> current cgconfig.conf structure, where I would emphasize the strange
> behavior described above.
>
That will be a great start and if we could get help with tools to
generate the configuration format, snapshot the current cgroup
filesystem, update the configuration format programatically, document
it and its nuances. We also have a big list at
http://libcg.wiki.sourceforge.net/todo
Thanks for looking through the madness :)
--
Balbir
------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
Libcg-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/libcg-devel
