As you can see in this screenshot, top reports chrome is using more than 11Gb of virtual memory, and yet only 0.417 Gb of swap space is being used. What is the reason for this? Is virtual memory not stored in the swap space? Why does my swap usage not correspond to my virtual memory usage?

screenshot of top

  • You could also present top's output using copy/paste rather than as an image. For example, top -bn1 | head -5 will provide the first five lines in your image. – DK Bose Dec 3 '19 at 10:12
  • Virtual Memory does not occupy physical pages before real writes. – Alvin Liang Dec 3 '19 at 10:12
  • Real writes or real reads, that is. Needless to say, a JPEG image has to be in the physical memory before it is decompressed and rendered properly. – gmt42 Dec 3 '19 at 10:30

I can't see much from this, but what is important is RES column, which is "resident set size". To quote man top:

      RES  - anything occupying physical memory which, beginning with
             Linux-4.5, is the sum of the following three fields:
             RSan - quadrant 1 pages, which include any
                    former quadrant 3 pages if modified
             RSfd - quadrant 3 and quadrant 4 pages
             RSsh - quadrant 2 pages
      VIRT - everything in-use and/or reserved (all quadrants)

While VIRT column shows 11.740 GB, RES columns is only 120.0 MB. Large VIRT can amount to all memory mapped cache files and all malloc() generated anonymous mapping that hasn't yet been allocated to a physical memory page, due to Linux's "optimistic memory allocator". Attempt to access some of such pages may still result in SIGSEGV (Segmentation fault) if no physical pages are available.

See the explanation in the NOTES section of man malloc:

       By default, Linux follows an optimistic memory allocation strategy.  This means that  when
       malloc()  returns  non-NULL there is no guarantee that the memory really is available.  In
       case it turns out that the system is out of memory, one or more processes will  be  killed
       by  the  OOM  killer.   For more information, see the description of /proc/sys/vm/overcom‐
       mit_memory and /proc/sys/vm/oom_adj in proc(5), and the Linux kernel source file  Documen‐

Hope this helps.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.