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

[Peter Zijlstra <a.p.zijlstra@chello.nl>]

On Sun, 2005-12-04 at 18:03 +0300, Nikita Danilov wrote:
> Wu Fengguang writes:
>  > On Sun, Dec 04, 2005 at 03:11:28PM +0300, Nikita Danilov wrote:
>  > > Wu Fengguang writes:
>  > >  > When a page is referenced the second time in inactive_list, mark it with
>  > >  > PG_activate instead of moving it into active_list immediately. The actual
>  > >  > moving work is delayed to vmscan time.
>  > >  > 
>  > >  > This implies two essential changes:
>  > >  > - keeps the adjecency of pages in lru;
>  > > 
>  > > But this change destroys LRU ordering: at the time when shrink_list()
>  > > inspects PG_activate bit, information about order in which
>  > > mark_page_accessed() was called against pages is lost. E.g., suppose
>  > 
>  > Thanks.
>  > But this order of re-access time may be pointless. In fact the original
>  > mark_page_accessed() is doing another inversion: inversion of page lifetime.
>  > In the word of CLOCK-Pro, a page first being re-accessed has lower
> 
> The brave new world of CLOCK-Pro is still yet to happen, right?

Well, I have an implementation that is showing very promising results. I
plan to polish the code a bit and post the code somewhere this week.
(current state available at: http://linux-mm.org/PeterZClockPro2)

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

Actually, CLOCK-pro does not have an active list. Pure CLOCK-pro has but
one clock. It is possible to create approximations that have more
lists/clocks, and in those the meaning of active list are indeed
somewhat different, but I agree with nikita here, this is odd.

> Anyway, these issues should be addressed in CLOCK-pro
> implementation. Current MM tries hard to maintain LRU approximation in
> both active and inactive lists.

nod.


Peter Zijlstra
(he who has dedicated his spare time to the eradication of LRU ;-)