Bug#224371: #224371 gnome-applets: System monitor: Memory constantly at 100%

[Steve Fosdick]

I have spent some time looking at this, I can at least get a
graph that shows more than one figure by stopping the multiload
applet from doing its own user memory calculation and having it
instead trust libgtop2, i.e. the following patch:

--- gnome-applets-2.4.0/multiload/linux-proc.c  2003-07-13
02:58:21.000000000 +0100
+++ gnome-applets-2.4.0.new/multiload/linux-proc.c      2004-01-18
04:32:46.000000000 +0000
@@ -130,7 +130,6 @@
 GetMemory (int Maximum, int data [5], LoadGraph *g)
 {
     int user, shared, buffer, cached;
-    unsigned long tmp_user;
  
     glibtop_mem mem;
  
@@ -138,9 +137,7 @@
  
     assert ((mem.flags & needed_mem_flags) == needed_mem_flags);
  
-    tmp_user = mem.used - mem.buffer - mem.shared - mem.cached;
-
-    user    = rint (Maximum * (float)tmp_user / mem.total);
+    user    = rint (Maximum * (float)mem.user / mem.total);
     shared  = rint (Maximum * (float)mem.shared / mem.total);
     buffer  = rint (Maximum * (float)mem.buffer / mem.total);
     cached = rint (Maximum * (float)mem.cached / mem.total);

By comparison, the equivalent calculation in libgtop2 looks like this:

buf->user =  buf->total - buf->free - buf->cached - buf->buffer;

Given that buf->total - buf->free is the same as buf->used the
difference between the calculation in libgtop2 and inside the
multiload applet itself is including 'shared' in the calculation.

The reason I think the calculation inside the multiload applet
gives silly results is because the figure from libgtop2 for 'shared'
on 2.6 kernels is actually the amount of mapped memory.  I'm guessing
this refers to memory mapped files and presumably memory mapped
files don't have to be read into physical memory all at once so
this could very well be a figure for the amount of mapped adress
space, i.e. virtual memory rather than an amount of physical
memory.  If this is the case then it isn't valid to use this in a
calculation that deals with physical memory and doing so could
sometimes result in the value for user memory going negative.

Missing shared memory out of the calculation probably doesn't give
the correct answer either as that part of the shared (mapped) memory
that is physical memory would be double counted (as shared and
again as user memory).

I am not sure what the answer is here.  Do we need input from kernel
developers to confirm exactly what the /proc/meminfo fields mean?  Is
there there somewhere this should be discussed?  Or do we give up on
the shared memory and always return zero for it, just like the
2.4 kernel does?

Steve.