Bug 168444 - Memory usage conflicts with /proc/meminfo
Memory usage conflicts with /proc/meminfo
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: procps (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Karel Zak
Brian Brock
Depends On:
Blocks: 187538
  Show dependency treegraph
Reported: 2005-09-15 20:47 EDT by Mark Seger
Modified: 2007-11-30 17:07 EST (History)
0 users

See Also:
Fixed In Version: RHBA-2006-0365
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-05-10 18:05:14 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Mark Seger 2005-09-15 20:47:25 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803

Description of problem:
If you run slabtop and look at the memory usage it does not agree with the slab field in /proc/meminfo.  I wrote a simple script that added up the memory in /proc/slabinfo and it agrees with /proc/meminfo so it appears that slabtop is wrong.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.run slabtop
2.cat /proc/meminfo
3.compare memory usage from slabtop with 'slab' field in /proc/meminfo

Actual Results:  /proc/meminfo slab field does not match either Active Memory OR Total Memory.

Expected Results:  The 2 should match OR if slabtop is reporting something different it should say so.

Additional info:
Comment 1 Karel Zak 2005-09-21 04:42:14 EDT
Which procps and kernel version are you running? There is not 'slab' field in
/proc/meminfo in RHEL3 (kernel 2.4.x).
Comment 2 Karel Zak 2005-10-20 08:56:06 EDT
Since there are insufficient details provided in this report for
us to investigate the issue further, and we have not received the
feedback we requested, we will assume the problem was not
reproduceable or has been fixed in a later update for this product.

Users who have experienced this problem are encouraged to upgrade
to the latest update release, and if this issue is still
reproduceable, please contact the Red Hat Global Support Services
page on our website for technical support options:

If you have a telephone based support contract, you may contact
Red Hat at 1-888-GO-REDHAT for technical support for the problem
you are experiencing.
Comment 3 Mark Seger 2005-10-21 08:22:59 EDT
I don't know what the reference about not receiving requested information as I
haven't received any requests.  That said, I don't understand what else is
needed.  Slabtop total memory usage is different than what's reported for slab
usage in /proc/meminfo.  What else is there to say?
Comment 4 Karel Zak 2005-10-21 08:51:33 EDT
Mark, did you read my comment #1? I need more information like:

  uname -a
  rpm -q procps
Comment 5 Mark Seger 2005-10-21 09:30:19 EDT
sorry about that, I guess I did miss it.  8-(

[root@cagxc1 ~]# uname -a
Linux cagxc1 2.6.9-11.3hp.XCsmp #1 SMP Tue Jul 5 01:12:29 EDT 2005 ia64 ia64
ia64 GNU/Linux

[root@cagxc1 ~]# rpm -q procps

from slabtop
 Active / Total Size (% used)       : 48092.62K / 57381.68K (83.8%)

from /proc/meminfo
Slab:            58496 kB
Comment 6 Karel Zak 2005-10-21 09:40:58 EDT
Thanks. So we talk about RHEL4 ;-)
Comment 7 Karel Zak 2005-10-21 11:23:50 EDT
The slabtop command calculates "Total Size" from /proc/slabinfo as
(num_objs * objsize) + (num_objs * objsize) + .... for each line in the file. It
means that the result is exact number of used memory.

I'm really not sure how kernel calculates the "Slab" field in the /proc/meminfo
file, but from my point of view it seems like "number of slab pages" * "size of
page" / 1024.

# tail +3 /proc/slabinfo | cut -b "26-31,32-38" | gawk 'BEGIN {FS=" "} {
printf("%s+", $1*$2) }' | sed "s/+$/\n/" | bc


# grep "Slab" /proc/meminfo
  Slab:            34064 kB

Reassign to kernel for more information.
Comment 8 Mark Seger 2005-10-21 11:42:08 EDT
for what it's worth, I wrote a utility that goes through each entry in
/proc/slabinfo and calculates total memory as well and my value agrees exactly
with /proc/meminfo and that's why I figure slabtop must have a bug in it.
btw - your code above is making assumtions about column positions it shouldn't
be making since they can vary - at least on my system.  Here are the first few
lines of /proc/slabinfo:

ip_conntrack_expect      0      0    256   63    1 : tunables  120   60    8 :
slabdata      0      0      0
ip_conntrack          22     62    512   31    1 : tunables   54   27    8 :
slabdata      2      2      0
ip_vs_conn             0      0    256   63    1 : tunables  120   60    8 :
slabdata      0      0      0
nfs_write_data        36     42    768   21    1 : tunables   54   27    8 :
slabdata      2      2      0

note the first entry shifts everything over...  Is this the problem?  I'm doing
everything in perl, only looking at field numbers as separated by whitespace.
Comment 9 Karel Zak 2005-10-21 11:53:35 EDT
My code above was example only -- I don't expect that it works always right.
Ignore it...

By the way, procps RHEL4-U2 changelog:

* Tue Jul 19 2005 Karel Zak <kzak@redhat.com> 3.2.3-8.2
- fix #151376 - RHEL4: slabtop calculation overflow

It means you have to update from procps-3.2.3-7EL where slabtop uses 'int'
instead 'long'.

Comment 10 Karel Zak 2005-10-21 13:06:56 EDT
Well, I wrote small "slab.py" script that calculate total slab memory usage:

#!/usr/bin/env python
import sys
f = open('/proc/slabinfo')
fields = []
for l in f.readlines():
fields = fields[2:]  # skip header
sum = 0
for f in fields:
  sum += (long(f[2]) * long(f[3]))
print "Slab Total:     ", sum/1024, "kB"


# ./slab.py; grep Slab /proc/meminfo
Slab Total:      34443 kB
Slab:            36428 kB

# uname -a
Linux i386-4as.test.redhat.com 2.6.9-22.ELsmp #1 SMP Mon Sep 19 18:32:14 EDT
2005 i686 i686 i386 GNU/Linux
Comment 11 Mark Seger 2005-10-21 13:14:49 EDT
I just wrote one too in perl and I don't think we're doing the same thing.  For
one, it looks like the posted script is looking at active slabs and I'm looking
at allocated since it's allocated memory that's being taken up that I think we
care about.  Anyhow, in addition, you just don't multiply the number of pages
times the number of slabs, you have to include the pagesize, don't you?  This is
my script and it EXACTLY agrees with /proc/meminfo:

#!/usr/bin/perl -w
open PROC,"</proc/slabinfo" or die;
$line=<PROC>; $line=<PROC>;
while ($line=<PROC>) {
    ($pps, $all)=(split(/\s+/, $line))[5,14];
    #print "PPS: $pps  $all\n";
print "ALL: $allTot  ALLB: $allTotB\n";

[root@cagxc1 procps]# grep Slab /proc/meminfo; ./slab.pl
Slab:            58320 kB
ALL: 3386  ALLB: 58320
Comment 12 Mark Seger 2005-10-21 13:22:02 EDT
ok, I think I know what's going on.  I'm calculating how much memory is being
taken up by slabs.  Since chunks of memory are allocated and slabs created from
those allocations, I believe it makes sense to track the allocated memory.  It
seems that slabtop is tracking how many bytes of actual slabs are being used and
so it not a measure of physical memory.  Since /proc/meminfo cares about
physical memory it agrees with me and not slabtop.  In other words we're both
right, but perhaps some clarification in the slabtop manpage might help.  Or
not... 8-)
Comment 13 Karel Zak 2005-10-21 13:32:01 EDT
Yes! :-) I said (comment #7) that /proc/meminfo counts pages of memory or
something like this, because the number from /proc/meminfo is always possible
divide by 4 (page size=4096). The slaptop has care about _bytes_.

Well, I will try explain it in the slabtop man page. Thanks.
Comment 14 Mark Seger 2005-10-21 13:59:13 EDT
The wording does need to be careful because both numbers cound bytes.  Here is
what I believe is going on.  If I have 128 byte slabs that I wish to allocate  
      out of 1 4096 page, that's 40 slabs.  If someone allocates 1 slab, they
are given 128 bytes but there is still 4096 bytes of memory being allocated. 
The next 39 slabs allocated will not result in any more memory being allocted.
Then, when the 41st slab is requested another 4096 bytes of memory will be
allocated.  It's these 4096 slabs that I'm talking about with /proc/meminfo and
it's the 128 byte chunks that slabtop is talking about.
Comment 24 Red Hat Bugzilla 2006-05-10 18:05:14 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.


Note You need to log in before you can comment on or make changes to this bug.