On Fri, Sep 17, 2010 at 3:09 PM, Ivana Hutarova Varekova
<[email protected]> wrote:
> On 09/15/2010 07:49 PM, Balbir Singh wrote:
>> * Ivana Varekova<[email protected]>  [2010-09-08 12:46:10]:
>>
>>
>>> the default cgsnapshot configuration file
>>> contains all variables from  2.6.34
>>>
>>>
>>> Signed-off-by: Ivana Hutarova Varekova<[email protected]>
>>> ---
>>>
>>>   samples/Makefile.am               |    3 ++
>>>   samples/cgsnapshot_whitelist.conf |   47 
>>> +++++++++++++++++++++++++++++++++++++
>>>   2 files changed, 49 insertions(+), 1 deletions(-)
>>>   create mode 100644 samples/cgsnapshot_whitelist.conf
>>>
>>> diff --git a/samples/Makefile.am b/samples/Makefile.am
>>> index 5e28c6f..9c1ec02 100644
>>> --- a/samples/Makefile.am
>>> +++ b/samples/Makefile.am
>>> @@ -1 +1,2 @@
>>> -EXTRA_DIST = cgconfig.conf cgred.conf cgrules.conf cgconfig.sysconfig
>>> +EXTRA_DIST = cgconfig.conf cgred.conf cgrules.conf cgconfig.sysconfig \
>>> +             cgsnapshot_whitelist.conf
>>> diff --git a/samples/cgsnapshot_whitelist.conf 
>>> b/samples/cgsnapshot_whitelist.conf
>>> new file mode 100644
>>> index 0000000..4cdac1e
>>> --- /dev/null
>>> +++ b/samples/cgsnapshot_whitelist.conf
>>> @@ -0,0 +1,47 @@
>>> +#memory
>>> +memory.memsw.failcnt=Y
>>> +memory.memsw.limit_in_bytes=Y
>>> +memory.memsw.max_usage_in_bytes=Y
>>> +memory.swappiness=Y
>>> +memory.use_hierarchy=Y
>>> +memory.failcnt=Y
>>> +memory.soft_limit_in_bytes=Y
>>> +memory.limit_in_bytes=Y
>>> +memory.max_usage_in_bytes=Y
>>> +memory.force_empty=N        -TODO
>>> +memory.move_charge_at_immigrate=Y
>>> +
>>>
>> Why do we snapshot failcnt?
>>
>>
>>> +#cpu
>>> +cpu.rt_runtime_us=Y
>>> +cpu.shares=N                - TODO
>>>
>> Why is this N?
>>
>>
>>> +cpu.rt_period_us=Y
>>> +
>>> +#cpuacct
>>> +cpuacct.usage=Y
>>> +
>>> +#devices
>>> +devices.deny=N              - TODO
>>> +devices.allow=N             - TODO
>>> +
>>> +#cpuset
>>> +cpuset.memory_spread_slab=Y
>>> +cpuset.memory_spread_page=Y
>>> +cpuset.memory_migrate=Y
>>> +cpuset.sched_relax_domain_level=Y
>>> +cpuset.sched_load_balance=Y
>>> +cpuset.mem_hardwall=Y
>>> +cpuset.mem_exclusive=Y
>>> +cpuset.cpu_exclusive=Y
>>> +cpuset.mems=Y
>>> +cpuset.cpus=Y
>>> +
>>> +#ns
>>> +
>>> +#freezer
>>> +freezer.state=Y
>>> +
>>> +#net_cls
>>> +net_cls.classid=Y
>>> +
>>> +#blkio
>>> +blkio.weight=Y
>>> \ No newline at end of file
>>>
>> ???
>>
>>
>> My big concern is having a file that closely represents the kernel
>> version in a library, how should new libraries deal with older kernels
>> and vice-versa?
>>
>>
> Hello,
> the purpose of this file is to have the configuration with which
> cgsnapshot is currently able to work. E.g. for now the
>
> cpu.shares and devices.*
> variable are the problems and the configuration with them generated by 
> cgsnapshot cant be used by cgconfigparser. When the logic will be add they 
> will be set to "y". failcnt are not problem for cgsnapshot so there is "y".
>
> If the kernel will be newer and will have a new variable, then there can't be 
> guaranteed this variable will not need new logic too, so will be implicitly 
> omit until it sb will add it. (But if the user will not use silent mode then 
> he or she will see warnings about the new variables).
>
> There should not be the problem for older kernels because of in this file 
> could be variables from all previous kernel versions which are ok for 
> cgsnapshot in arbitrary version of kernel.
>

tbh, i don't like this approach. i would prefer to assume we can
handle a file, as opposed to not, and maintain a blacklist, to which
someone can add further files.

Dhaval

------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
_______________________________________________
Libcg-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/libcg-devel

Reply via email to