Re: [PATCH] vmscan: evict use-once pages first (v2)

[Andrew Morton]

On Fri, 01 May 2009 10:05:53 -0400
Rik van Riel <riel@xxxxxxxxxx> wrote:

> Andrew Morton wrote:
> 
> >> When we implement working set protection, we might as well
> >> do it for frequently accessed unmapped pages too.  There is
> >> no reason to restrict this protection to mapped pages.
> > 
> > Well.  Except for empirical observation, which tells us that biasing
> > reclaim to prefer to retain mapped memory produces a better result.
> 
> That used to be the case because file-backed and
> swap-backed pages shared the same set of LRUs,
> while each following a different page reclaim
> heuristic!

No, I think it still _is_ the case.  When reclaim is treating mapped
and non-mapped pages equally, the end result sucks.  Applications get
all laggy and humans get irritated.  It may be that the system was
optimised from an overall throughput POV, but the result was
*irritating*.

Which led us to prefer to retain mapped pages.  This had nothing at all
to do with internal impementation details - it was a design objective
based upon empirical observation of system behaviour.

> Today:
> 1) file-backed and swap-backed pages are separated,
> 2) the majority of mapped pages are on the swap-backed LRUs
> 3) the accessed bit on active pages no longer means much,
>     for good scalability reasons, and
> 4) because of (3), we cannot really provide special treatment
>     to any individual page any more, however
> 
> This means we need to provide our working set protection
> on a per-list basis, by tweaking the scan rate or avoiding
> scanning of the active file list alltogether under certain
> conditions.
> 
> As a side effect, this will help protect frequently accessed
> file pages (good for ftp and nfs servers), indirect blocks,
> inode buffers and other frequently used metadata.

Yeah, but that's all internal-implementation-of-the-day details.  It
just doesn't matter how the sausages are made.  What we have learned is
that the policy of retaining mapped pages over unmapped pages, *all
other things being equal* leads to a more pleasing system.


--
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/