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?
> 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.
Anyway, these issues should be addressed in CLOCK-pro
implementation. Current MM tries hard to maintain LRU approximation in
both active and inactive lists.
[...]
>
> Though I have a strong feeling that with the extra PG_activate bit, the
> + ClearPageReferenced(page);
> line should be removed. That is, let the extra reference record live through it.
> The point is to smooth out the inter-reference distance. Imagine the following
> situation:
>
> - + - + + - - + -
> 1 2 3 4 5
> +: reference time
> -: shrink_list time
>
> One page have an average inter-reference distance that is smaller than the
> inter-scan distance. But the distances vary a bit. Here we'd better let the
> reference count accumulate, or at the 3rd shrink_list time it will be evicted.
I think this is pretty normal and acceptable variance. Idea is that when
system is short on memory scan rate increases together with the
precision of reference tracking.
[...]
>
> Thanks,
Che-che,
> Wu
Nikita.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
