buffer cache behavior on memory-constrained systems

Chuck Lever (cel@monkey.org)
Fri, 26 Mar 1999 15:45:56 -0500 (EST)


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 {

i've tested this on a 64M box, and performance is markedly better under
heavy load. the buffer cache size doesn't fluctuate wildly, and CPU
utilization is significantly better. because the buffer cache is working
better, file system block read rate is lower, leaving more bandwidth for
writes and swapping out.

admittedly, this is a kludge. however, i think it might be worth
considering a similar patch for 2.2.x, since this is a simple change and
could be important for folks who run servers that occasionally find
themselves short of memory.

- Chuck Lever

--
corporate:	<chuckl@netscape.com>
personal:	<chucklever@netscape.net> or <cel@monkey.org>

The Linux Scalability project: http://www.citi.umich.edu/projects/citi-netscape/

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