Re: [PATCH] 2.6.4-rc2-mm1: vm-split-active-lists

[Mike Fedyk]

Jamie Lokier wrote:
> Mike Fedyk wrote:
>
> > That would have other side benefits.  If the anon page matches (I'm not 
> > calling it "!dirty" since that might have other semantics in the current 
> > VM) what is in swap, it can be cleaned without performing any IO.  Also, 
> > suspending will have much less IO to perform before completion.
>
>
> Exactly those sort of benefits.

:)

> Btw, When you say "You're saying all anon memory should become
> swap_cache eventually" it's worth noting that there are benefits to
> doing it the other way too: speculatively pulling in pages that are
> thought likely to be good for interactive response, at the expense of
> pages which have been used more recently, and must remain in RAM for a
> short while while they are considered in use, but aren't ranked so
> highly based on some interactivity heuristics.

IIUC, the current VM loses the aging information as soon as a page is 
swapped out.  You might be asking for a LFU list instead of a LRU list.
Though, a reverse LFU (MFU -- most frequently used?) used only for swap 
might do what you want also...

> I.e. fixing the "everything swapped out in the morning" problem by
> having a long term slow rebalancing in favour of pages which seem to
> be requested for interactive purposes, competing against the short
> term balance of whichever pages have been used recently or are
> predicted by short term readahead.

There was talk in Andrea's objrmap thread about using two LRU lists, but 
I forget what the benefits of that were.

> Both replicating RAM pages to swap, and replicating swap or
> file-backed pages to RAM can be speculative and down slowly, over the
> long term, and when there is little other activity or I/O.

In short, that probably would require some major surgery in the VM.

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