Messages in this thread Patch in this message | | | Date | Sat, 20 Mar 1999 04:37:55 +0100 (CET) | From | Andrea Arcangeli <> | Subject | [patch] fix for buffer hash leakage [Re: [PATCH]: for discussion - buffer cache growth] |
| |
On Fri, 12 Mar 1999, Chuck Lever wrote:
>i'd like some help solving the blocked processes problem, and comments on >the instrumentation. thanks!
Well Chuck, you was right pointing out to me this evening that your istrumentation patch was showing a buffer hash leakage.
I implemented an alternate debugging approch but I trivially reproduced the leakage here too.
The bug is in bforget. bforget gets called by ext2 at truncate time. So right now when you truc a file with tons of clean buffers that are mapping the file blocks, you'll make such buffers unfindable anymore. So most of the buffers were made unuseful for caching purposes and you had always to wait to discard them (try_to_free_buffer()) and read again from disk. This is the reason of your stall and performance drop across bench-passes.
This is also the reason that while I was under pine and I was writing back a big mailing-list-folder (as linux-kernel ;) some time, then I always got all other process stuck. I think this is also the bottleneck that is been reported before 2.2.0 is been out.
The real problem is that bforget itself remove the buffer from the hash. Then it recall refilebuffer that will run `file_buffer()', but _only_ if the buffer has to be refiled (it belongs to a different list than its current state), and this is not the case for a just clean buffer. So a just clean buffer could be unhashed and so it could become unfindable.
At least this is what I think at this very late time... (but I drunk also some good beer before return to home.... ;).
So here my patch that fix this problem fine here (it adds also my debugging code I used to monitor if it really works). Maybe I am ill due the late time, but it seems to improve a _lot_ performances of a truncate (and so of `rm`).
Let me know if it makes any difference for your bench ;).
Index: fs/buffer.c =================================================================== RCS file: /var/cvs/linux/fs/buffer.c,v retrieving revision 1.1.2.25 diff -u -r1.1.2.25 buffer.c --- buffer.c 1999/03/20 01:48:41 1.1.2.25 +++ linux/fs/buffer.c 1999/03/20 03:09:59 @@ -76,6 +76,7 @@ static int nr_buffers_type[NR_LIST] = {0,}; static int nr_buffer_heads = 0; static int nr_unused_buffer_heads = 0; +static int nr_hashed_buffers = 0; /* This is used by some architectures to estimate available memory. */ int buffermem = 0; @@ -433,6 +434,8 @@ } *pprev = next; bh->b_pprev = NULL; + + nr_hashed_buffers--; } } @@ -568,6 +571,7 @@ *bhp = bh; bh->b_pprev = bhp; } + nr_hashed_buffers++; } } @@ -847,7 +851,6 @@ { mark_buffer_clean(buf); clear_bit(BH_Protected, &buf->b_state); - remove_from_hash_queue(buf); buf->b_dev = NODEV; refile_buffer(buf); if (!--buf->b_count) @@ -1495,6 +1498,7 @@ printk("Buffer memory: %6dkB\n",buffermem>>10); printk("Buffer heads: %6d\n",nr_buffer_heads); printk("Buffer blocks: %6d\n",nr_buffers); + printk("Buffer hashed: %6d\n",nr_hashed_buffers); for(nlist = 0; nlist < NR_LIST; nlist++) { found = locked = dirty = used = lastused = protected = 0; Andrea Arcangeli
PS. Goodnight...
- 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/
| |