Re: is "shared memory" hardcoded to zero in gnome-system-monitor?

["Jasper St. Pierre" <jstpierre mecheye net>]

It seems 0 is the correct value. See this bug:

https://bugzilla.gnome.org/show_bug.cgi?id=129863

And while the filenames have changed from 2.4, it seems the behavior is still the same:

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/mm/page_alloc.c#n2999

On Wed, Mar 5, 2014 at 7:54 PM, Giovanni Gherdovich <g gherdovich gmail com> wrote:

Hello,

I was reading libgtop code and noticed this snippet at sysdeps/linux/mem.c
https://git.gnome.org/browse/libgtop/tree/sysdeps/linux/mem.c#n58

--------------8<-----------------------
file_to_buffer(server, buffer, sizeof buffer, FILENAME);

buf->total  = get_scaled(buffer, "MemTotal:");
buf->free   = get_scaled(buffer, "MemFree:");
buf->used   = buf->total - buf->free;
buf->shared = 0;
buf->buffer = get_scaled(buffer, "Buffers:");
buf->cached = get_scaled(buffer, "Cached:");
--------------8<-----------------------

where FILENAME is /proc/meminfo.

Question:
why is buf->shared hardcoded to zero?
Is it intentional or a woops?

"man proc" is pretty vague about the "Shmem" field
of /proc/meminfo (it says "to be documented"),
which seems to be the candidate for filling buf->shared,
http://linux.die.net/man/5/proc

but I was suprised to discover that gnome-system-monitor
is wired to a flat constant zero (is it?) when it comes to show
the amount of shared memory.

Cheers,
GGhh

_______________________________________________
gtk-devel-list mailing list
gtk-devel-list gnome org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

--
  Jasper