Re: size of swapped-out part of the process

[Bryan Donlan]

On Mon, Nov 17, 2008 at 2:42 PM, Victoria Muntean <vikimun@xxxxxxxxx> wrote:
> On 11/17/08, Hugh Dickins <hugh@xxxxxxxxxxx> wrote:
>> On Mon, 17 Nov 2008, Victoria Muntean wrote:
>>> How can I calculate size of swapped-out part of the process from
>>> /proc/PID/*, even if approximately ?
>>> For example, I have VmSize=1216192 kB, VmRSS = 628788 kB, but global
>>> swap-in-use==0.
>>> Hence (VmSize - VmRSS) is far from being swapped-out part of the
>>> process. What is ?
>>
>> I'm sorry, we don't record those numbers per process or per mm,
>> so you won't find them in /proc/PID/status or /proc/PID/statm.
>>
>> And we'd probably resist accepting a patch to add them,
>> so as not to enlarge key data structures to hold them.
>>
>> There's also an ambiguity about what "swapped-out" means: does
>> it include shared file pages which were once mapped into the
>> process, but have since been freed under memory pressure?
>>
>> But it looks like you're interested in swapped-out to mean written
>> on swap.  In that case, if you have CONFIG_PROC_PAGE_MONITOR=y,
>> you can read /proc/PID/smaps and add up all the "Swap:" lines.
>
> Can you possibly explain what types of pages create  "VSZ>>RSZ"
> effect in total absence of swapping and plenty of free memory ?

mmap(2) a file, then don't touch some pages in it. This happens all
the time with shared libraries - for example, if you link in
imagemagick, but never use JPEG encoding/decoding, the pages of memory
corresponding to libjpeg will never be touched, and so will be
accounted in VSZ but not RSZ.

If there's memory pressure (even if you have plenty of cache, this can
occur just from IO activity), long-unaccessed pages from these mmaps
may be evicted after being read as well.

Also, some programs have a habit of allocating much more memory than
they actually use - the pages they don't access are not mapped, and so
are not accounted in RSZ either. If they never write to them, they
won't be present in swap either.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/