Search code examples
linuxvirtual-memorytop-commandswapfilememory-overcommitment

Linux `top` command: how much process memory is physically stored in swap space?


Let's say I run my program on a 64-bit Linux machine with 64 Gb of RAM. In my very small C program immediately after the start I do

void *p = sbrk(1024ull * 1024 * 1024 * 120);

this moving my data segment break forward by 120 Gb.

After the above sbrk call top entry for my process shows RES at some low value, VIRT at 120g, and SWAP at 120g.

After this operation I write something into the first 90 Gb of the above region

memset(p, 0xAB, 1024ull * 1024 * 1024 * 90);

This causes some changes in the top entry for my process: VIRT expectedly remains at 120g, RES becomes almost 64g, SWAP drops to around 56g.

The common Swap stats in the header of top output show that swap file usage increases, which is expected since my program will have to push about 26 Gb of memory pages into the swap file.

So, according to the above observations, SWAP column simply reports my process's non-RES address space regardless of whether this address space has been "materialized", i.e. regardless of whether I already wrote something into that region of virtual memory.

But is there any way to figure out how much of that SWAP size has actually been "materialized" and backed up by something stored in the swap file? I.e. is there any way to make top to display that 26 Gb value for my process?


Solution

  • The behavior depends on a version of procps you are using. For instance, in version 3.0.5 SWAP value equals:

    task->size - task->resident
    

    and it is exactly what you are encountering. Man top.1 says:

    VIRT = SWAP + RES
    

    Procps-ng, however, reads /proc/pid/status and sets SWAP correctly

    https://gitlab.com/procps-ng/procps/blob/master/proc/readproc.c#L383

    So, you can update procps or look at /proc/pid/status directly