<br><br><div class="gmail_quote">2009/8/24 Krzysztof Taraszka <span dir="ltr"><<a href="mailto:krzysztof.taraszka@gnuhosting.net">krzysztof.taraszka@gnuhosting.net</a>></span><br><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">2009/8/24 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"><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>Krzysztof Taraszka wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
2009/8/24 Daniel Lezcano <<a href="mailto:daniel.lezcano@free.fr" target="_blank">daniel.lezcano@free.fr</a>><br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
[ 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;">
i think that /proc/meminfo should be mounted after /proc . why? i think<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;">
that, because mounting /proc may override /proc/meminfo<br>
Am I right? :)<br>
<br>
<br>
<br>
<br>
</blockquote>
Ha ! haha ! arrgh ! no way ! You are right :/<br>
<br>
<br>
<br>
</blockquote>
Hehe ;)<br>
<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<br>
has<br>
been mounted.<br>
<br>
Maybe we can look at modifying fs/proc/meminfo.c instead. Let me do a<br>
small<br>
patch for the kernel...<br>
<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<br>
kernel version.<br>
I do not really like to touch fs/proc/meminfo.c but it's an example here.<br>
<br>
</blockquote>
<br>
<br>
Hi Daniel,<br>
<br>
I tried to compile my kernel tree (2.6.30.5) with your patch using gcc-4.4,<br>
gcc-4.3 and gcc-4.2 and i got this error on every gcc when linking kernel:<br>
<br>
mm/built-in.o: In function `mem_cgroup_info':<br>
(.text+0x27651): undefined reference to `__udivdi3'<br>
mm/built-in.o: In function `mem_cgroup_info':<br>
(.text+0x27678): undefined reference to `__udivdi3'<br>
mm/built-in.o: In function `mem_cgroup_info':<br>
(.text+0x276b0): undefined reference to `__udivdi3'<br>
mm/built-in.o: In function `mem_cgroup_info':<br>
(.text+0x276dd): undefined reference to `__udivdi3'<br>
make: *** [.tmp_vmlinux1] Error 1<br>
<br>
this can be gcc based error. What kernel and gcc did you use for compile<br>
your kernel?<br>
</blockquote>
<br></div></div>
I used a 2.6.30 kernel and<br>
gcc (GCC) 4.3.0 20080428 (Red Hat 4.3.0-8)<br>
Compiled on a x86_64 host.<br>
<br>
Do you have any warning at the compile time ?<br>
<br>
</blockquote></div><br></div></div>No, did not see any warnings when memcontrol.c or fs/meminfo.c was compiled.<br>Anyway, I will try to build in on the stable (lenny) version of debian (right now I am working on unstable debian tree).<br>
That might be gcc from unstable problem.<br><br>I will let you know what exactly problem is.<br><br></blockquote><div><br>ok Daniel,<br><br>i found a problem. I am runnning my debian box under vmware 32bit box so your patch can not be compiled propertly on the 32bit system, so I decided to make a little change in your patch.<br>
I used shift operation instead of div. in the asm/div64.h is macro do_div() but using shift instead of div is easier that implementing do_div macro, so<br>here is a small patch:<br><br>--- memcontrol.c.orig 2009-08-24 21:19:36.000000000 +0200<br>
+++ memcontrol.c 2009-08-24 21:20:37.000000000 +0200<br>@@ -1834,14 +1834,13 @@<br> si_swapinfo(info);<br> <br> if (limit != LLONG_MAX) {<br>- info->totalram = limit / info->mem_unit;<br>- info->freeram = (limit - mystat.stat[MCS_RSS]) / info->mem_unit;<br>
+ info->totalram = limit >> info->mem_unit;<br>+ info->freeram = (limit - mystat.stat[MCS_RSS]) >> info->mem_unit;<br> }<br> <br> if (memsw_limit != LLONG_MAX) {<br>- info->totalswap = memsw_limit / info->mem_unit;<br>
- info->freeswap = (memsw_limit - swap_in_u) / info->mem_unit;<br>-<br>+ info->totalswap = memsw_limit >> info->mem_unit;<br>+ info->freeswap = (memsw_limit - swap_in_u) >> info->mem_unit;<br>
}<br> <br> return 0;<br><br><br>I hope that simple change won't to break on your 64bit :) <br><br>-- <br>Krzysztof Taraszka<br><a href="mailto:dzimi@pld-linux.org">dzimi@pld-linux.org</a><br><br><pre></pre> </div>
</div>