[Tfug] I'm using ~2GB of swap space that doesn't exist.

[Bexley Hall]

Hi John,

--- On Wed, 9/16/09, John Gruenenfelder <johng at as.arizona.edu> wrote:

> -0700, Bexley Hall wrote:
> >> PR  NI  VIRT  RES  SHR S %CPU 
> >> 20   0 1939m 1.4g 1.4g S 10.0 11.9   1:31.98
> vmware-vmx
> >
> >{grrrr... can't easily reformat this  :< ]
> > 
> >> I have no swap space, yet, vmware-vmx is using 1939MB of it.
> >
> >The total image (TEXT+DATA) is 1939M.  Pull 11G of RAM out of your box
> >and watch how the numbers change  :>
> 
> Correct me if I'm wrong, but I've always taken the VIRT
> value to mean the amount of address space allocated to a 
> process by the kernel/MMU.

Yes.  The "program's footprint" in memory (my TEXT+DATA comment).

> On a 1GB system, you could allocate 3GB of memory and you'd see the
> VIRT value skyrocket, but until you actually try to use that memory,
> it's not really connected to any physical memory.

This *can* also be true (depends on how VM is implemented in
the particular OS).  Once you have "faulted" the pages in, then
they require backing store (i.e. swap) [1]

On most desktop software, the TEXT image is faulted in when the
program is exec'd.  And, the Data segment (init'ed data) as well
as BSS are often also "created" at this time. [2]

The Heap, by contrast, may just be an alloc'd chunk of memory
which may or may not be faulted in until needed (though usually some
portion of the heap is needed RSN.

In the OP's case, I assume the program has loaded and is executing
so all of this preliminary mapping has taken place.  My "remove 11G
comment" was to illustrate that cutting physical RAM is the only
way he can *hope* to see any swap size mentioned.  (and, even then, 
it will only reflect what is actively "in use" at the time)

As you drive physical memory to 0, swap more accurately reflects the
real needs of your program (until, of course, you can't satisfy the
wired-down requests and things bomb!  :> )

IIRC, many old FBSD releases would run on as little as *5* (five) MB
of physical RAM (and on a 386sx, to boot!)  :>

--don

[1] Technically, this isn't strictly true, either.  In my OS, I
"cheat" knowing that some stuff exists on nonvolatile media so
why *duplicate* it on volatile media when I can just page-in
from the original non-volatile medium (!)  Of course, this means
I have to "color" each memory action accordingly.  (small price
to pay since it is done at "develop time").

[2] This needn't also be true, either.  But, it greatly complicates
the loading of programs (e.g., now the "disk image" of the program
and its associated so's have to be effectively locked so that they
can't be altered or unlinked while there is a pending use for
them (i.e., the program that is running but hasn't yet needed
those parts of those objects).