lkml.org 
[lkml]   [1999]   [Mar]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
Date
From
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/

\
 
 \ /
  Last update: 2005-03-22 13:50    [W:0.064 / U:0.180 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site