[CRIU] [PATCH 1/4] cg: Add ability to dump custom cgroup properties

Pavel Emelyanov xemul at virtuozzo.com
Fri May 6 06:15:58 PDT 2016


On 05/06/2016 04:05 PM, Cyrill Gorcunov wrote:
> On Fri, May 06, 2016 at 03:56:52PM +0300, Pavel Emelyanov wrote:
>> On 05/06/2016 03:46 PM, Cyrill Gorcunov wrote:
>>> On Fri, May 06, 2016 at 03:30:21PM +0300, Pavel Emelyanov wrote:
>>>>> +
>>>>> +/*
>>>>> + * Predefined properties.
>>>>> + */
>>>>> +static const char *cpu_props[] = {
>>>>> +	"cpu.shares",
>>>>> +	"cpu.cfs_period_us",
>>>>> +	"cpu.cfs_quota_us",
>>>>> +	"cpu.rt_period_us",
>>>>> +	"cpu.rt_runtime_us",
>>>>> +	"notify_on_release",
>>>>> +};
>>>>
>>>> I thought we agreed on putting these "defaults" into a text file sitting somewhere
>>>> in ... I don't know ... /etc? /var/something? ... anyway. So have we agreed on that
>>>> or not?
>>>
>>> Well. I would rather prefer keep them here for a while. I need to play with
>>> predefined configs on our vz7 containers (which will require libvzctl patching)
>>> and then once everything goes smooth we can switch to dynamically read default
>>> properties. This patch is already heavy enough, lets do such thing on top please.
>>
>> It will be hard to do it on top. Once we move the list of props to work on
>> into separate file we can give up using the --cgroup-props option. Actually
>> we can give up with the --cgroup-props-file option too by suggesting to
>> replace the file itself :)
>>
>> So my current concern is more about the API extension you propose.
> 
> In which format we gonna keep it there? Yaml too?

Yes. The same format that you propose for custom file.

> No, I think having these options is a win,
> hardcoded place is never a good option.

Tons of software keep configuration in "hardcoded" places.

-- Pavel



More information about the CRIU mailing list