On 08/12/2010 01:59 PM, Ivana Hutarova Varekova wrote:
> On 08/12/2010 10:36 AM, Balbir Singh wrote:
>> * Ivana Varekova<[email protected]>   [2010-08-09 14:49:37]:
>>
>>
>>> CHANGELOG v1
>>> * more verbose comments
>>> * tune the variable names/description/usage in display_controller_data 
>>> function
>>> * remove unnecesary .stat exception
>>>
>>> SYNOPSIS:
>>> cgsnapshot [-h] [-n] [controller] [...]
>>> Generate the configuration file from the current hierarchie(s) of control 
>>> groups
>>>     -h, --help              Display this help
>>>     -n, --no-errors Omit the output
>>> the output have the same format as cgconfig.conf file (the values are in 
>>> commas)
>>>
>>> EXAMPLE:
>>> $ /home/varekova/bg/libcgroup/20100719/libcg/src/tools/cgsnapshot -n
>>> # Configuration file generated by cgsnapshot
>>> mount {
>>>      cpuset = /cgroup/cpuset;
>>>      cpu = /cgroup/devices;
>>>      cpuacct = /cgroup/memoryd;
>>>      memory = /cgroup/memory;
>>>      devices = /cgroup/devices;
>>>      freezer = /cgroup/freezer;
>>>      net_cls = /cgroup/net_cls;
>>> }
>>>
>>> group daemons {
>>>     perm {
>>>             admin {
>>>                     uid = root;
>>>                     gid = root;
>>>             }
>>>             task {
>>>                     uid = root;
>>>                     gid = root;
>>>             }
>>>     }
>>>     cpuset {
>>>             cpuset.memory_spread_slab="0";
>>>             cpuset.memory_spread_page="0";
>>>             cpuset.memory_migrate="0";
>>>             cpuset.sched_relax_domain_level="-1";
>>>             cpuset.sched_load_balance="1";
>>>             cpuset.mem_hardwall="0";
>>>             cpuset.mem_exclusive="0";
>>>             cpuset.cpu_exclusive="0";
>>>     }
>>> }
>>>
>>>
>> Is this a generated sample? BTW, I ran the code through the generated
>> hierarchy from samples/large_cgconfig.conf and took a snapshot. Then I
>> loaded the snapshot using cgconfigparser, the load failed.
>>
> The problem with samples/large_cgconfig.conf are the duplicate groups:
> cgsnapshot do separate  group definitions for all control groups in
> separate hierarchies, but
> cgconfigparser allows only one  group definition for each control group
> name. In this example there are groups with the same name in two
> different hierarchies, so cgsnapshot write two  group definitions.

I think cgconfigparser can handle two groups with the same name, as long 
as they are in separate hierarchies. The problem is with memory parameters.

With kernel 2.6.36-0.0.rc0.git1.fc15.x86_64, cgconfig parser tries to 
write "oom_kill_disable 0\nunder_oom 0" to 
/cgroup/memory/CBSFxx/Zcz6/memory.oom_control, which fails with EINVAL.

With 2.6.32-63.el6.x86_64, cgconfigparser writes "0" to 
/cgroup/memory/CBSFxx/memory.use_hierarchy, which fails with EBUSY.

I think there must be some better logic to handle these special 
parameters. I was thinking about a configuration file with exception 
that should be not processed by cgsnapshot, which distributions would 
tailor appropriate to the kernel they ship.

Jan

------------------------------------------------------------------------------
This SF.net email is sponsored by 

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
_______________________________________________
Libcg-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/libcg-devel

Reply via email to