>to demonstrate that not having a real buffer reclamation policy hurts
>performance when the file+VM working set exceeds the size of physical
>memory, i created this short patch against fs/buffer.c in 2.2.3:
>
>--- buffer.c Tue Mar 9 13:58:42 1999
>+++ buffer.c.new Fri Mar 26 15:31:05 1999
>@@ -1445,7 +1445,12 @@
> */
> int try_to_free_buffers(struct page * page_map)
> {
>- struct buffer_head * tmp, * bh = page_map->buffers;
>+ struct buffer_head * tmp, * bh;
>+
>+ /* shrink_mmap() usually picks an awful page to steal. let's
>+ choose one that's more likely to have old data on it. */
>+ bh = lru_list[BUF_CLEAN]->b_this_page;
>+ page_map = mem_map + MAP_NR(bh->b_data);
>
> tmp = bh;
> do {
>
Note that you should also revert to freeing at least the freelist (this is
the reason Linus posted the patch against 2.2.4) and all other lru-list if
the BUF_CLEAN is empty.
But more important you could have the first entry in the lru list not
freeable (don't ask me why ;), and in such case you would have big
stability problems.
Note that in ftp://e-mind.com/pub/linux/andrea-tree/2.2.4_andrea3.bz2 I am
just freeing pages in shrink_mmap() in perfect lru basis (taking care also
of buffer aging). But I am doing it at the pagemap level. I see it far
more clean and general. I am touching the buffer not in bread but in
get_hash_table and in getblk if the buffer is not found in the hash table.
Performances are impressive here. I can checkin a whole linux CVS tree in
2sec. Having a perfect lru rocks.
Andrea Arcangeli
-
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/