Messages in this thread | | | Date | Sat, 27 Mar 1999 15:13:19 +0100 (CET) | From | Andrea Arcangeli <> | Subject | Re: buffer cache behavior on memory-constrained systems (fwd) |
| |
As first thanks again to MikeG for forwarding me this email while the kernel list is down here ;).
>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/
| |