On Wed, 19 Apr 2000, Rik van Riel wrote:
>On Thu, 20 Apr 2000, Andrea Arcangeli wrote:
>> On Wed, 19 Apr 2000, Rik van Riel wrote:
>>
>> >After this comment I looked at the code again and lo and behold,
>> >we were *both* wrong ;) (the original code put pages in the wrong
>>
>> Could you elaborate?
>>
>> Referenced pages in 2.3.99-pre6-pre3 (and all previous 2.3.x) are rolled
>> immediatly from the back to the top of the lru. That's fine as far I can
>> tell. See:
>>
>> dispose = &zone->lru_cache;
>> if (test_and_clear_bit(PG_referenced, &page->flags))
>> /* Roll the page at the top of the lru list,
>> * we could also be more aggressive putting
>> * the page in the young-dispose-list, so
>> * avoiding to free young pages in each pass.
>> */
>> goto dispose_continue;
>>
>> If the page was referenced we clear the bit and we re-link the
>> page immediatly in the lru and such page will become lru->_next_
>> (it was in the lru->_prev_ when we encountered it).
>>
>> Later shrink_mmap will keep eating from lru->_prev_ and so the
>> referenced page will be the _last_ one that we'll try to
>> process. What's wrong with that?
>
>As you mentioned in one of your emails, we don't want to waste
>shrink_mmap() time scanning over pages that we just scanned.
We never scanned a reference page! We only rolled it over. So we have to
scan it as soon as it returns to us as non referenced.
>Because of this it makes sense to put the referenced pages in
>the &young queue and splice it back into the lru list later.
This will cause swap load since we'll forbid ourself to scan all the
potentially freeable pages by doing so.
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Apr 23 2000 - 21:00:16 EST