Re: memory handling in pre5/pre6

From: Rik van Riel (riel@conectiva.com.br)
Date: Wed Apr 19 2000 - 18:02:21 EST


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.
Because of this it makes sense to put the referenced pages in
the &young queue and splice it back into the lru list later.

They entered the "lru" queue in essentially random order anyway,
so we might as well chose the more efficient way of disposing the
page in the private queue which is spliced back into the main
list later.

regards,

Rik

--
The Internet is not a network of computers. It is a network
of people. That is its real strength.

Wanna talk about the kernel? irc.openprojects.net / #kernelnewbies http://www.conectiva.com/ http://www.surriel.com/

- 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