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

Krzysztof Taraszka krzysztof.taraszka at gnuhosting.net
Wed Aug 26 06:50:52 PDT 2009


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.
_______________________________________________
Containers mailing list
Containers at lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers




More information about the Devel mailing list