2009/8/26 Krzysztof Taraszka <span dir="ltr"><<a href="mailto:krzysztof.taraszka@gnuhosting.net">krzysztof.taraszka@gnuhosting.net</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;">
2009/8/26 Daniel Lezcano <span dir="ltr"><<a href="mailto:daniel.lezcano@free.fr" target="_blank">daniel.lezcano@free.fr</a>></span><br><div class="gmail_quote"><div><div></div><div class="h5"><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>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></div><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>
</blockquote></div><br>Okey.<br>I made few tests and this two ways work:<br><br>First way:<br>=======<br>lxc. smack enabled, policy loaded. cgroup not labeled.<br><br>a) start container<br>b) mount cgroup inside container<br>
c) mount --bind /cgroup/foo/memory.meminfo /proc/meminfo<br>d) secure the /cgroup on the host (ie: attr -S -s SMACK64 -V host /cgroup).<br><br>this step can be done inside lxc tools ;)<br><br>Second way:<br>==========<br>
lxc. smack enabled, policy loaded. cgroup not labeled.<br><br>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.<br>
b) start container<br>c) mount cgroup inside container<br>d) mount --bind /cgroup/foo/memory.meminfo /proc/meminfo<br><br>steps: b, c, d can be done inside lxc tools. step a can't and it is base on the admin policy.<br>
<br>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.<br><br><br>-- <br>Krzysztof Taraszka<br>