Tools like top show processes using two kinds of memory:

• Resident memory, labelled RES: How much physical memory, how much RAM, your process is using. RES is the important number.
• Virtual memory, labelled VIRT: How much memory your process thinks it’s using. Usually much bigger than RES, thanks to the Linux kernel’s clever memory management.

Here’s a short C program to illustrate the difference:

#include <stdio.h>
#include <stdlib.h>

void fill(unsigned char* addr, size_t amount) {
    unsigned long i;
    for (i = 0; i < amount; i++) {
        *(addr + i) = 42;
    }
}

int main(int argc, char **argv) {

    unsigned char *result;
    char input;
    size_t s = 1<<30;

    result = malloc(s);
    printf("Addr: %p\n", result);
    //fill(result, s);

    scanf("%c", &input);
    return 0;
}

Save it as mem.c, compile it cc -Wall -g mem.c -o mem and run it.

It requests 1 Gig of memory (1 « 30), but doesn’t use it. With top (or htop, which is much nicer), or even ps -Ao rsz,vsz,cmd | grep mem view it’s memory usage. The resident size should be quite small (~280k for me), but the virtual size will be the full 1 Gig we requested.

Uncomment the fill line, compile and run it again. You should see the resident size get much bigger, as we’re actually using the memory we requested (we’re filling it with the number 42). The kernel has to give us real memory to work with.

We can request far more virtual memory than the machine can handle. Here’s a screenshot where I’ve requested 16 Gig of memory, on a machine with only 3 Gig of RAM and 3 Gig of swap. The VIRT’s sum up to way more than that machine can handle. At the top left of the screenshot you can see none of that memory has really been allocated. The kernel won’t allocate it until we use it.

In summary, virtual size can largely be ignored. Resident size is the important number.