Messages in this thread | | | From | Nikita Danilov <> | Date | Sun, 4 Dec 2005 18:03:15 +0300 | Subject | Re: [PATCH 01/16] mm: delayed page activation |
| |
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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |