[lxc-devel] Memory Resources

[Daniel Lezcano]

Krzysztof Taraszka wrote:
> 2009/8/26 Krzysztof Taraszka <krzysztof.taraszka at gnuhosting.net>
>
>   
>> 2009/8/26 Daniel Lezcano <daniel.lezcano at free.fr>
>>
>>     
>>> KAMEZAWA Hiroyuki wrote:
>>>
>>>       
>>>> On Mon, 24 Aug 2009 16:11:15 +0200
>>>> Daniel Lezcano <daniel.lezcano at free.fr> wrote:
>>>>
>>>>
>>>>
>>>>         
>>>>> [ snip ]
>>>>>
>>>>>
>>>>>           
>>>>>>  i think that /proc/meminfo should be mounted after /proc . why? i
>>>>>>             
>>>>>>>> think
>>>>>>>> that, because mounting /proc may override /proc/meminfo
>>>>>>>> Am I right? :)
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>                 
>>>>>>> Ha ! haha ! arrgh ! no way ! You are right :/
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>> Hehe ;)
>>>>>>
>>>>>>
>>>>>>
>>>>>>             
>>>>>>> In the case of application container, lxc mounts /proc but in the case
>>>>>>> of
>>>>>>> system container it is the system who do that so after the
>>>>>>> /proc/meminfo has
>>>>>>> been mounted.
>>>>>>>
>>>>>>> Maybe we can look at modifying fs/proc/meminfo.c instead. Let me do a
>>>>>>> small
>>>>>>> patch for the kernel...
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>> Okey. I am waiting for your patch :)
>>>>>>
>>>>>>
>>>>>>             
>>>>> Quick and dirty patch but at least working. It is no synced on the
>>>>> latest kernel version.
>>>>> I do not really like to touch fs/proc/meminfo.c but it's an example
>>>>> here.
>>>>>
>>>>>
>>>>>
>>>>>           
>>>> I'll strongly Nack to this.
>>>> plz find a way to ln -s /path_to_cgroup/memory.meminfo
>>>> /mycontainer/meminfo
>>>>
>>>>
>>>>         
>>> Yep, I agree with you, I don't like this approach.
>>>
>>> We are trying to solve the problem of the userspace tools which look at
>>> the /proc/meminfo file to display memory informations. That looks weird to
>>> set a max memory usage of 256MB via the cgroup and having the 'free' command
>>> showing 4GB of total memory. More than looking weird, Dietmar explained that
>>> can puzzle applications relying on these informations for taking some
>>> decisions.
>>>
>>> If we consider having /cgroup/mycontainer/memory.meminfo with memory
>>> information in the same format than /proc/meminfo, that solves partially the
>>> problem:
>>> - we run an application container, the application won't mount /proc so
>>> the lxc tools do that for the application (at least to isolate the pids
>>> information), it is easy to mount --bind /cgroup/mycontainer/memory.meminfo
>>> to /proc/meminfo before the application takes the control, that is to say
>>> before 'exec'. Tested and verified with the memory tools (free, top, etc
>>> ...)
>>>
>>> - we run a system container, we can do this mount-bind but when the
>>> application, aka /sbin/init, takes the control, the /proc is mounted by the
>>> system services, so we lose the /proc/meminfo we previously set. Hence
>>> meminfo in the cgroup directory does not solve the problem for this use
>>> case.
>>>
>>> Any ideas ?
>>>
>>>
>>>       
>> If I may... I have been thinking about that last few days and... I think
>> that mounting /proc/meminfo can be done with mounted cgrop and secured by
>> SMACK64.
>> I will test it tonight and give you raport how does it works for me.
>>
>>
>>     
>
> Okey.
> I made few tests and this two ways work:
>
> First way:
> =======
> lxc. smack enabled, policy loaded. cgroup not labeled.
>
> a) start container
> b) mount cgroup inside container
> c) mount --bind /cgroup/foo/memory.meminfo /proc/meminfo
> d) secure the /cgroup on the host (ie: attr -S -s SMACK64 -V host /cgroup).
>
> this step can be done inside lxc tools ;)
>
> Second way:
> ==========
> lxc. smack enabled, policy loaded. cgroup not labeled.
>
> a) do not label whole /cgrop directory (DO NOT DO: attr -S -s SMACK64 -V
> host /cgroup). Label dedicate files only (for example: /cgroup/cpuset.cpus,
> /cgroup/vs1/cpuset.cpus, etc). Do not label the /cgrop/vs1 directory. Label
> with vs1 label only /cgroup/vs1/memory.meminfo. All other files label with
> host label to do not allow read them.
> b) start container
> c) mount cgroup inside container
> d) mount --bind /cgroup/foo/memory.meminfo /proc/meminfo
>
> steps: b, c, d can be done inside lxc tools. step a can't and it is base on
> the admin policy.
>
> I think that the first solution is more automatic and can be done by lxc
> tools (maybe command line switch? I can prepare a patch for that.
>   

I do not know smack, what does smack here ? Will this solution avoid the 
container to overwrite /proc/meminfo by remounting /proc ?