1

Consider the following pmap output of a simple tail process on Linux:

$ pmap -x 3974
3974:   tail -F /var/log/syslog
Address           Kbytes     RSS   Dirty Mode   Mapping
0000000000400000      60      36       0 r-x--  tail
000000000060e000       4       4       4 r----  tail
000000000060f000       4       4       4 rw---  tail
0000000000610000     132      12      12 rw---    [ anon ]
00007ffff7775000    2792      44       0 r----  locale-archive
00007ffff7a2f000    1672     432       0 r-x--  libc-2.17.so
00007ffff7bd1000    2048       0       0 -----  libc-2.17.so
00007ffff7dd1000      16      16      16 r----  libc-2.17.so
00007ffff7dd5000       8       8       8 rw---  libc-2.17.so
00007ffff7dd7000      16      12      12 rw---    [ anon ]
00007ffff7ddb000     132     104       0 r-x--  ld-2.17.so
00007ffff7fd7000      12      12      12 rw---    [ anon ]
00007ffff7ff7000      12      12      12 rw---    [ anon ]
00007ffff7ffa000       8       4       0 r-x--    [ anon ]
00007ffff7ffc000       4       4       4 r----  ld-2.17.so
00007ffff7ffd000       8       8       8 rw---  ld-2.17.so
00007ffffffde000     132      24      24 rw---    [ stack ]
ffffffffff600000       4       0       0 r-x--    [ anon ]
----------------  ------  ------  ------
total kB            7064     736     116

Given the process and the state of it, I can get ps to output various information about its memory usage:

$ ps -lp 3974
F S   UID   PID  PPID  C PRI  NI ADDR SZ WCHAN  TTY          TIME CMD
0 S  1000  3974  3972  0  80   0 -  1766 -      pts/0    00:00:00 tail

$ ps vp 3974
  PID TTY      STAT   TIME  MAJFL   TRS   DRS   RSS %MEM COMMAND
 3974 pts/0    Ss+    0:00      3    57  7006   660  0.0 tail -F /var/log/syslog

$ ps lp 3974
F   UID   PID  PPID PRI  NI    VSZ   RSS WCHAN  STAT TTY        TIME COMMAND
0  1000  3974  3972  20   0   7064   660 -      Ss+  pts/0      0:00 tail -F /var/log/syslog

However, with the exception of the VSZ field from the l output, these all differ more or less from the info pmap gives about the individual mappings. Most strange of all is clearly the SZ field from the -l output, which I just can't seem to at all figure out what it's counting. I haven't found any explanation of what it does in any documentation (the manpage mentions something cryptic about the "core image", but doesn't define that term, and I can't see any combination of fields from pmap that would add up to 1766 or even anything remotely close to that). Does anyone know?

However, the RSS field from the v and l outputs also differ slightly from pmap, and so does the DRS field in the v output. Though the difference isn't all that great, it still perplexes me a bit.

1 Answer 1

1

The SZ field, which is described by ps's documentation as (for completeness):

size in physical pages of the core image of the process. This includes text, data, and stack space. Device mappings are currently excluded; this is subject to change. See vsz and rss.

seems to be identical to the first number reported by the procfs in /proc/$PID/statm:

$ tailf /var/log/vmware-installer &; PID=$!
$ pmap -x $PID | tail -n 1
total kB            6788     616     132
$ ps -lp $PID
F S   UID   PID  PPID  C PRI  NI ADDR SZ WCHAN  TTY          TIME CMD
0 S   516 13848 13657  0  85   5 -  1697 -      pts/7    00:00:00 tailf
$ cat /proc/$PID/statm
1697 153 120 2 0 81 0

The format of statm is described in the kernel documentation (/usr/src/linux/Documentation/filesystems/proc.txt):

Table 1-3: Contents of the statm files (as of 2.6.8-rc3)
..............................................................................
Field    Content
size     total program size (pages)         (same as VmSize in status)
resident size of memory portions (pages)       (same as VmRSS in status)
shared   number of pages that are shared       (i.e. backed by a file)
trs      number of pages that are 'code'       (not including libs; broken,
                                                        includes data segment)
lrs      number of pages of library            (always 0 on 2.6)
drs      number of pages of data/stack         (including libs; broken,
                                                        includes library text)
dt       number of dirty pages                 (always 0 on 2.6)
..............................................................................

This is neither much informative, but at least shows that the linux kernel itself reports that number.

1
  • While that doesn't answer the question, it is helpful in that I can perhaps look at the kernel source to figure out the actual answer. Thanks!
    – Dolda2000
    Aug 22, 2013 at 5:05

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .