Re: Fairness in love and swapping

["Stephen C. Tweedie" <sct@dcs.ed.ac.uk>]

Hi,

> AFAIK, mapped images aren't part of a proces' RSS, but
> are page-cached (page->inode type of RSS). And swapping
> of those vma's _is_ done in shrink_mmap() in filemap.c.

No, absolutely not.  These pages are certainly present in the page
cache, but they are not swapped out there, and filemap.c never deals
directly with vma scans.  shrink_mmap() refuses to touch any pages which
have a reference count not exactly equal to one, so it avoids memory
mapped pages like the plague.  Memory mapped images are referenced
directly by a process's page tables, so they count against its resident
set size (which is defined as the number of present user-mode pages in
the page tables).

vmscan.c::try_to_swap_out() unhooks these pages from the page tables
when it wants to.  The final swapout of these pages takes place at the
end of that function, where it calls filemap.c::page_unuse(), which
takes care of removing the page from the page cache as soon as the last
reference from the page tables is removed.

> Furthermore, it's quite useful if your read-ahead pages
> stay in memory for a while so you don't read them two
> or even three times before they're actually used.

We never will read more than once --- the pages are still in the page
cache, so whenever we try to swap them in, we can always find the
readahead copy there.  Memory-mapped pages have to be in the page cache
before we are allowed to link them into the page tables, so the pages
are shared by both in the page cache *and* the page tables.  It is the
swapper which is responsible for turfing shared pages.  shrink_mmap()
only ever looks for unshared cache pages and buffers.

> But if I've overlooked something, I'd really like to hear about
> it... A bit of a clue never hurts when coding up new patches :-)

You're welcome. :)

Cheers,
 Stephen.