Re: memory handling in pre5/pre6

From: Rik van Riel (riel@conectiva.com.br)
Date: Thu Apr 20 2000 - 07:33:52 EST


On Thu, 20 Apr 2000, Andrea Arcangeli wrote:
> On Wed, 19 Apr 2000, Rik van Riel wrote:
>
> >> 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.

Rolling it over _is_ having scanned it.

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

Which is good. The page was accessed, so we're much better
off looking for a non-accessed page that's mapped in a
process than throwing out a recently accessed page and doing
away with page aging...

I've tried it both with and without this change and it just
works better if we honour the referenced bit. By doing this
we'll have a larger amount of pages in the LRU queue and are
doing much better aging. Sure, it generates a bit more
swapOUT traffic, but that's ok since only swapIN is really
timing critical and we now have to do a bit less of that.

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:17 EST