2009/8/24 Krzysztof Taraszka <krzysztof.taraszka@xxxxxxxxxxxxxx>
>
>
> 2009/8/24 Krzysztof Taraszka <krzysztof.taraszka@xxxxxxxxxxxxxx>
>
> 2009/8/24 Daniel Lezcano <daniel.lezcano@xxxxxxx>
>>
>>> Krzysztof Taraszka wrote:
>>>
>>>> 2009/8/24 Daniel Lezcano <daniel.lezcano@xxxxxxx>
>>>>
>>>>
>>>>> [ 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.
>>>>>
>>>>>
>>>>
>>>> Hi Daniel,
>>>>
>>>> I tried to compile my kernel tree (2.6.30.5) with your patch using
>>>> gcc-4.4,
>>>> gcc-4.3 and gcc-4.2 and i got this error on every gcc when linking
>>>> kernel:
>>>>
>>>> mm/built-in.o: In function `mem_cgroup_info':
>>>> (.text+0x27651): undefined reference to `__udivdi3'
>>>> mm/built-in.o: In function `mem_cgroup_info':
>>>> (.text+0x27678): undefined reference to `__udivdi3'
>>>> mm/built-in.o: In function `mem_cgroup_info':
>>>> (.text+0x276b0): undefined reference to `__udivdi3'
>>>> mm/built-in.o: In function `mem_cgroup_info':
>>>> (.text+0x276dd): undefined reference to `__udivdi3'
>>>> make: *** [.tmp_vmlinux1] Error 1
>>>>
>>>> this can be gcc based error. What kernel and gcc did you use for compile
>>>> your kernel?
>>>>
>>>
>>> I used a 2.6.30 kernel and
>>> gcc (GCC) 4.3.0 20080428 (Red Hat 4.3.0-8)
>>> Compiled on a x86_64 host.
>>>
>>> Do you have any warning at the compile time ?
>>>
>>>
>> No, did not see any warnings when memcontrol.c or fs/meminfo.c was
>> compiled.
>> Anyway, I will try to build in on the stable (lenny) version of debian
>> (right now I am working on unstable debian tree).
>> That might be gcc from unstable problem.
>>
>> I will let you know what exactly problem is.
>>
>>
> ok Daniel,
>
> 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.
> 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
> here is a small patch:
>
> --- memcontrol.c.orig 2009-08-24 21:19:36.000000000 +0200
> +++ memcontrol.c 2009-08-24 21:20:37.000000000 +0200
> @@ -1834,14 +1834,13 @@
> si_swapinfo(info);
>
> if (limit != LLONG_MAX) {
> - info->totalram = limit / info->mem_unit;
> - info->freeram = (limit - mystat.stat[MCS_RSS]) / info->mem_unit;
> + info->totalram = limit >> info->mem_unit;
> + info->freeram = (limit - mystat.stat[MCS_RSS]) >> info->mem_unit;
> }
>
> if (memsw_limit != LLONG_MAX) {
> - info->totalswap = memsw_limit / info->mem_unit;
> - info->freeswap = (memsw_limit - swap_in_u) / info->mem_unit;
> -
> + info->totalswap = memsw_limit >> info->mem_unit;
> + info->freeswap = (memsw_limit - swap_in_u) >> info->mem_unit;
> }
>
> return 0;
>
>
> I hope that simple change won't to break on your 64bit :)
>
>
>
Agrhhh!
It broken at all ;) I forgot that shift operation is true only when the
divisor is a power of 2 (if x=2^a then c=c/x is the same as c=c>>x).
So.. my last patch only fix compilation on 32bit machines but totaly
breaking show values by /proc/meminfo.
But.. I make another one which using do_div() macro and working as I wish.
It should look like that and it works for me :)
--- memcontrol.c.orig 2009-08-24 21:19:36.000000000 +0200
+++ memcontrol.c 2009-08-25 00:56:30.000000000 +0200
@@ -40,6 +40,7 @@
#include "internal.h"
#include <asm/uaccess.h>
+#include <asm/div64.h>
struct cgroup_subsys mem_cgroup_subsys __read_mostly;
#define MEM_CGROUP_RECLAIM_RETRIES 5
@@ -1834,14 +1835,27 @@
si_swapinfo(info);
if (limit != LLONG_MAX) {
- info->totalram = limit / info->mem_unit;
- info->freeram = (limit - mystat.stat[MCS_RSS]) / info->mem_unit;
+
+ u64 dd_totalram, dd_freeram;
+
+ dd_totalram = limit;
+ do_div(dd_totalram, info->mem_unit);
+ dd_freeram = (limit - mystat.stat[MCS_RSS]);
+ do_div(dd_freeram, info->mem_unit);
+ info->totalram = dd_totalram;
+ info->freeram = dd_freeram;
}
if (memsw_limit != LLONG_MAX) {
- info->totalswap = memsw_limit / info->mem_unit;
- info->freeswap = (memsw_limit - swap_in_u) / info->mem_unit;
+ u64 dd_totalswap, dd_freeswap;
+
+ dd_totalswap = memsw_limit;
+ do_div(dd_totalswap, info->mem_unit);
+ dd_freeswap = memsw_limit - swap_in_u;
+ do_div(dd_freeswap, info->mem_unit);
+ info->totalswap = dd_totalswap;
+ info->freeswap = dd_freeswap;
}
return 0;
this should work for 32 & 64bit systems.
--
Krzysztof Taraszka
dzimi@xxxxxxxxxxxxx
_______________________________________________
Containers mailing list
Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linux-foundation.org/mailman/listinfo/containers
