[ale] top and SWAP

Brian Pitts brian at polibyte.com
Fri Sep 7 11:38:47 EDT 2007


JK wrote:
> John Wells wrote:
> 
>> Guys,
>>
>> Would like some help in clarifying the SWAP column under top
> 
> I believe (based on knowledge of the 2.4 series kernels) that
> this reflects the amount of virtual memory owned by the process
> whose backing store is the swap partition.  However, just because
> a memory region is backed by swap does not mean it will ever
> actually be *written out* to disk.  The "Used" number is the
> amount of swap space actually in use on the disk.  If a swapped
> region is never actually written to (a situation that is quite
> common), it will never be physically present either in RAM or
> on disk (it's *really* "virtual").  This is because swap is only
> used to back anonymous (malloc()'d) memory, which is assumed to
> be 0 if never written to. There's no reason to ever allocate
> pages for 600MB of zeros; you only need real RAM or swap if the
> process writes data to a page.


I think this is almost right. A malloc will increase the size of the 
virtual image, but not the resident size. Perhaps top calculates SWAP as 
VIRT - RES? The relevant portions of the top man page:

        o: VIRT  --  Virtual Image (kb)
           The  total  amount  of virtual memory used by the task.  It 
includes all code, data and  shared  libraries  plus  pages  that  have 
  been swapped out.

           VIRT = SWAP + RES.

        p: SWAP  --  Swapped size (kb)
           The swapped out portion of a task?s total virtual memory image.

        q: RES  --  Resident size (kb)
           The non-swapped physical memory a task has used.

           RES = CODE + DATA.

        r: CODE  --  Code size (kb)
           The amount of physical memory devoted to executable code, 
also known as the ?text resident set? size or TRS.

        s: DATA  --  Data+Stack size (kb)
           The amount of physical memory devoted to other than 
executable code, also known as the ?data resident set? size or DRS.

For monitoring swap, try sar -W.

-Brian



More information about the Ale mailing list