[Devel] Re: [lxc-devel] Memory Resources

[Krzysztof Taraszka]

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.


-- 
Krzysztof Taraszka
_______________________________________________
Containers mailing list
Containers at lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers