Re: [PATCH 01/16] mm: delayed page activation

[Wu Fengguang <wfg@mail.ustc.edu.cn>]

On Tue, Dec 06, 2005 at 08:55:13PM +0300, Nikita Danilov wrote:
> Wu Fengguang writes:
>  > On Sun, Dec 04, 2005 at 06:03:15PM +0300, Nikita Danilov wrote:
>  > >  > inter-reference distance, and therefore should be better protected(if ignore
>  > >  > possible read-ahead effects). If we move re-accessed pages immediately into
>  > >  > active_list, we are pushing them closer to danger of eviction.
>  > > 
>  > > Huh? Pages in the active list are closer to the eviction? If it is
>  > > really so, then CLOCK-pro hijacks the meaning of active list in a very
>  > > unintuitive way. In the current MM active list is supposed to contain
>  > > hot pages that will be evicted last.
>  > 
>  > The page is going to active list anyway. So its remaining lifetime in inactive
>  > list is killed by the early move.
> 
> But this change increased lifetimes of _all_ pages, so this is

Yes, it also increased the lifetimes by meaningful values: first re-accessed
pages are prolonged more lifetime. Immediately removing them from inactive_list 
is basicly doing MRU eviction.

> irrelevant. Consequently, it has a chance of increasing scanning
> activity, because there will be more referenced pages at the cold tail
> of the inactive list.

Delayed activation increased scanning activity, while immediate activation
increased the locking activity. Early profiling data on a 2 CPU Xeon box showed
that the delayed activation acctually cost less time.

> And --again-- this erases information about relative order of
> references, and this is important. In the past, several VM modifications
> (like split inactive_clean and inactive_dirty lists) were tried that had
> various advantages over current scanner, but maintained weaker LRU, and
> they all were found to degrade horribly under certain easy triggerable
> conditions.

Yeah, the patch does need more testing. 
It has been in -ck tree for a while, and there's no negative report about it.

Andrew, and anyone in the lkml, do you feel ok to test it in -mm tree?
It is there because some readahead code test the PG_actvation bit explicitly.
If the answer is 'not for now', I'll strip it out from the readahead patchset
in the next version.

Thanks,
Wu