Created attachment 15235 [details] [review]
Patch to support kernel 2.5

*** Bug 104818 has been marked as a duplicate of this bug. ***

From reading the kernel development mailing list, it seems to be
expected from user utilities that they parse the /proc/meminfo field
headers instead of relying on the order of the lines of data.

Doing so would allow the kernel developers to play a bit with the
output of /proc/meminfo (and this is what they need, I guess) without
having to worry about breaking user utilities and libgtop. Also, it is
my personal opinion that relying on a fixed format is always some kind
of a gamble.

I would personally like to have comments on this, and I would be ready
to try to propose a concurrent patch if necessary.

*** Bug 122445 has been marked as a duplicate of this bug. ***

*** Bug 117815 has been marked as a duplicate of this bug. ***

Here's the output of /proc/meminfo from one of the duplicate bugs.

Linux 2.6.0-test4 on Debian SID:

cat /proc/meminfo

MemTotal:       515772 kB
MemFree:        130120 kB
Buffers:         35172 kB
Cached:         161680 kB
SwapCached:          0 kB
Active:         237840 kB
Inactive:       120708 kB
HighTotal:           0 kB
HighFree:            0 kB
LowTotal:       515772 kB
LowFree:        130120 kB
SwapTotal:     1132500 kB
SwapFree:      1132500 kB
Dirty:             140 kB
Writeback:           0 kB
Mapped:         227928 kB
Slab:            18572 kB
Committed_AS:   299116 kB
PageTables:       1780 kB
VmallocTotal:   516024 kB
VmallocUsed:     20616 kB
VmallocChunk:   493712 kB
HugePages_Total:     0
HugePages_Free:      0
Hugepagesize:     4096 kB


Below is the first three lines from the output generated by
cat /proc/meminfo on Linux 2.4.20, these are absent in 2.5/2.6

        total:    used:    free:  shared: buffers:  cached:
Mem:  30162944 28852224  1310720        0  4988928  7163904
Swap: 386576384  2654208 383922176

Philippe: that sounds like a great idea. Are you still interested in
working on a patch?


The patch already attached doesn't seem correct to me in that it only
checks for version = 2.5 or everythis else is considered 2.4 and lower
format. What if the version is 2.6 or greater?

Ok, I will try to do something for this patch.  Anyway, most of the
monitor applications didn't break on my kernel 2.6 test machine so I
guess it's just a case of building a more flexible parser. Also, I
hope that 2.6.0-test6 is near from stable enough to be reliable.

Incidentally, in my experience, overall stability in the 2.6-test
series has been very good; it's no mystery why more people are making
the jump.

Created attachment 20785 [details]
A patch to fix memory usage with 2.6 kernel

*** Bug 123522 has been marked as a duplicate of this bug. ***

seb128@debian.org: It seems that your patch is almost correct. It
seems to me though that we should be able to read the 2.4 mem file
just like the 2.5 and greater. 

Can't I just do
  buf->total = get_scaled(buffer, "SwapTotal:");
  buf->free = get_scaled(buffer, "SwapFree:");
for any of the versions? 2.4 /proc/meminfo contains every line in the
2.6 version plus the first two lines in addition. Thus your solution
for reading 2.6 /proc/meminfo should work with the 2.4 version.

Created attachment 20824 [details] [review]
A fix with no difference between 2.4 and 2.6 kernels

Patch committed to gnome-2-4 and HEAD.

Thanks