You are here: Home ยป Blog

Cheat sheet: understanding the pmap(1) output

Posted on Friday, July 03 2015 at 09:17 | Category: Linux | 2 Comment(s)

pmap(1) can be used to list the individual address areas which are mapped into a process. It essentially reads the /proc/$pid/smaps file and represents the data in a more readable format. On Linux, there is the command line option -XX which displays all information the kernel provides (the output might change when newer kernels provide different metrics).

Lets consider the following simple C program:

#include <stdio.h>

int main(int argc, char *argv[]) {
    return 0;

We can now launch this application (called "minimal") and call pmap with its process id:

$ ./minimal & pmap -XX $!

As a result, we get the output as shown in this cheat sheet (click on the image for a larger, readable version):

One interesting metric is the PSS value, also known as "Proportional Share Size". This is the amount of memory which is private to the mapping, plus the partial amount of shared mappings of this process. For example, if the process has mapped 100 KiB of private memory, another 200 KiB of shared memory which is shared between two processes and another 150 KiB which is shared between three processes, the PSS is calculated like 100 KiB + 200 KiB / 2 + 150 KiB / 3 = 250 KiB. This can be directly observed when starting the "minimal" application more than once. Lets examine the first mapping which is reported my pmap when the application is started once (this is the code section of the executable) (only showing the first few columns here):

$ ./minimal & pmap -XX $!
         Address Perm   Offset Device   Inode Size Rss Pss Shared_Clean Shared_Dirty Private_Clean Private_Dirty 
        00400000 r-xp 00000000  08:01 3948320    4   4   4            0            0             4             0

The application now continues to run, and we can simply start it once again and dump the mappings of this new process:

$ ./minimal & pmap -XX $!
         Address Perm   Offset Device   Inode Size Rss Pss Shared_Clean Shared_Dirty Private_Clean Private_Dirty
        00400000 r-xp 00000000  08:01 3948320    4   4   2            4            0             0             0

Here, we can observe two things:

  • The Pss value for the new process is 2, not 4 - this is because the code section is shared between two processes, the one which we started first and the one which we started second
  • The Private values are now 0, while the Shared values are now 4 - we are now sharing one page (4 KiB) between the two processes.

Furthermore, if we use pmap to examine the mapping of the first process again (assumed that its process ID was 13944), we see that also for this first process the values have changed:

$ pmap -XX 13944
13944:   ./minimal
         Address Perm   Offset Device   Inode Size Rss Pss Shared_Clean Shared_Dirty Private_Clean Private_Dirty
        00400000 r-xp 00000000  08:01 3948320    4   4   2            4            0             0             0
Note that memory which can be shared (e.g. Code from a shared library) but which is mapped only into this particular process is counted as private, unless it will be mapped in at least one additional process.

Understanding free and top memory statistics [Update]

Posted on Friday, June 12 2015 at 12:15 | Category: Linux | 1 Comment(s)

Both top and free can be used to gather basic information about memory usage, but each of them reports the statistics in a slightly different way which might not be directly obvious. An example output of free, using the -m switch to report numbers in MiB instead of KiB, is as follows:

Lets ignore the last line (Swap - it simply shows the total swap space and how much from that swap space is allocated and how much is still free) and focus on physical memory:

The first three numbers in the Mem: line are straight forward: the "total" column shows the total physical memory available (most likely, this system has 8 GiB installed and uses a part of it for its graphics device, hence the "total" column shows less than 8 GiB). The "used" column shows the amount of memory which is currently in use, and the "free" column shows the amount which is still available.

Then, there are the "buffers" and "cached" columns - they show how much from the "used" memory is really used for buffers and caches. Buffers and caches is memory which the kernel uses for temporary data - if an application requires more memory, and there is no memory "free" anymore, the kernel can still use this temporary memory and assign it to application processes (probably resulting in lower I/O performance since there is not as much cache memory available now).

Finally, there is the "+/- buffers/cache" line: This might look strange first, but what it does is that it also reports the "used" and "free" memory, without the buffers and caches - as said above, buffer and cache memory is dynamic and can be assigned to an application process, if required. Hence, the "+/- buffers/cache" line actually shows the memory which is used by and available for processes.

The following diagram shows the memory allocation from the sample above:

top returns almost the same information, in a slightly different layout (note that the numbers are somewhat different since some time has elapsed between the execution of the two commands):

The main difference is that it does not directly show the "used" and "free" memory without the buffers - but this can be easily calculated.

Another thing which looks strange is that the amount of "cached" memory is shown in the "Swap" line - however, it has nothing to do with swap, probably it has been put there to use the available screen area as efficient as possible.

Update: procps >= 3.3.10

Starting with procps 3.3.10, the output of free has changed which might cause some confusion. I came across this through a question on StackOverflow: Linux "free -m": Total, used and free memory values don't add up. Essentially, free does not show the "+/- buffers/cache" line anymore, but instead shows an "available" column which is taken from the MemAvailable metric which has been introduced with kernel 3.14. See for a complete description:

MemAvailable: An estimate of how much memory is available for starting new applications, without swapping. Calculated from MemFree, SReclaimable, the size of the file LRU lists, and the low watermarks in each zone. The estimate takes into account that the system needs some page cache to function well, and that not all reclaimable slab will be reclaimable, due to items being in use. The impact of those factors will vary from system to system.

The new format of the free output looks like this:

The main difference is that the "buff/cache" values are not part of "Used" anymore, but counted separately. Hence, the total memory is calculated as "used + buff/cache + free":

Since the "available" value is an estimation which considers some system specific factors, it can not directly be calculated from the other values which are shown by free.

Windows Clipboard Inspector

Posted on Tuesday, June 09 2015 at 12:38 | Category: News | 3 Comment(s)

When working on copy&paste features, it is useful to be able to inspect the current contents of the Clipboard. Unfortunately, at least Windows 7 does not include a clipboard viewer which shows the current clipboard data in all available formats, but Free Clipboard Viewer seems to do the trick. It automatically updates whenever new content is copied into the clipboard and updates the list of available formats accordingly on the left side, while the content itself is displayed on the right side. The following screen shot shows how the tool displays a part of its own web page after some content has been marked and copied into the clipboard with CTRL-C:

This tutorial shows how to expose a plain Java Bean as a Data Control, and how to create a user interface from this Data Control. The sample use case is to show the current time depending on a timezone which can be selected from a drop down list.

Displaying results 5 to 8 out of 115