2009/8/26 Daniel Lezcano <span dir="ltr"><<a href="mailto:daniel.lezcano@free.fr">daniel.lezcano@free.fr</a>></span><br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><div></div><div class="h5">KAMEZAWA Hiroyuki wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Mon, 24 Aug 2009 16:11:15 +0200<br>
Daniel Lezcano <<a href="mailto:daniel.lezcano@free.fr" target="_blank">daniel.lezcano@free.fr</a>> wrote:<br>
<br>
  <br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
[ snip ]<br>
    <br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
i think that /proc/meminfo should be mounted after /proc . why? i think<br>
that, because mounting /proc may override /proc/meminfo<br>
Am I right? :)<br>
<br>
<br>
                <br>
</blockquote>
Ha ! haha ! arrgh ! no way ! You are right :/<br>
<br>
            <br>
</blockquote>
Hehe ;)<br>
<br>
        <br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
In the case of application container, lxc mounts /proc but in the case of<br>
system container it is the system who do that so after the /proc/meminfo has<br>
been mounted.<br>
<br>
Maybe we can look at modifying fs/proc/meminfo.c instead. Let me do a small<br>
patch for the kernel...<br>
<br>
<br>
            <br>
</blockquote>
Okey. I am waiting for your patch :)<br>
      <br>
</blockquote>
Quick and dirty patch but at least working. It is no synced on the latest kernel version.<br>
I do not really like to touch fs/proc/meminfo.c but it's an example here.<br>
<br>
    <br>
</blockquote>
<br>
I'll strongly Nack to this.<br>
plz find a way to ln -s /path_to_cgroup/memory.meminfo   /mycontainer/meminfo<br>
  <br>
</blockquote>
<br></div></div>
Yep, I agree with you, I don't like this approach.<br>
<br>
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.<br>

<br>
If we consider having /cgroup/mycontainer/memory.meminfo with memory information in the same format than /proc/meminfo, that solves partially the problem:<br>
- 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 ...)<br>

<br>
- 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.<br>

<br>
Any ideas ?<br>
<br></blockquote><div><br>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.<br>I will test it tonight and give you raport how does it works for me.<br>
 <br></div></div>