Re: memory handling in pre5/pre6

From: Rik van Riel (riel@conectiva.com.br)
Date: Fri Apr 21 2000 - 10:15:32 EST


On Fri, 21 Apr 2000, Andrea Arcangeli wrote:
> On Thu, 20 Apr 2000, Rik van Riel wrote:
>
> >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 see your point and ok we can do that.
>
> Also the pages inserted to the lru should all have the
> referenced bit clear and we're getting that wrong right now. I
> did a patch in my ftp area the try to fix that (it's called
> pagecache-aging-1). However also the buffer cache should clear
> the referenced bit while adding pages to the buffer cache while
> recycling from the freelist (and it's not yet doing that).

Doing this will give the pages a shorter life span in the
LRU queue, which may be good or wrong, depending on the
type of load. You must remember that we're not really working
with an LRU queue, but with second chance fifo :)

> >[..] Sure, it generates a bit more
> >swapOUT traffic,[..]
>
> I known about this bit indeed ;). However looking at the amount
> of swap with 2.3.99-pre is not good idea anyway...

The problem here is that shrink_mmap() is on a per-zone basis
while swap_out() is not. The fix in this a case is to have a
global queue for shrink_mmap(), which puts pages in a per-zone
scavenge queue. Then we can use swap_out() and shrink_mmap() to
to global page replacement while looking at the properties of
the local scavenge queue to determine which zone has the lowest
VM load and allocate pages there.

(well, probably a bit more sophisticated than this in order to
get maximal performance and avoid the bad border cases)

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