lkml.org 
[lkml]   [1999]   [Mar]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch] fix for buffer hash leakage
On Sat, 20 Mar 1999, Andrea Arcangeli wrote:
> 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.

yes, that's exactly what i've found. i have a simple patch that i'm
testing on the big Dell right now, that is slightly different from yours.
i thought it would be better to put the forgotten buffers onto the free
list instead. to wit, here's my bforget():

[ -3 lines, +2 lines, for those of you keeping track ]

void __bforget(struct buffer_head * buf)
{
clear_bit(BH_Protected, &buf->b_state);
remove_from_queues(buf);
put_last_free(buf);
if (!--buf->b_count)
return;
printk("VFS: forgot an in-use buffer! (count=%d)\n",
buf->b_count);
}
the reason for this is to discourage buffer turn-over by keeping the free
list supplied. if getblk() can take a buffer from the free list instead
of allocating another page, that reduces the likelihood that shrink_mmap()
will steal pages away from the buffer cache.

this discourages the buffer cache from growing out of control, without
using an artificial cap, and keeps system performance consistently good
during heavy file system loads. i think invalidate_buffers() ought to add
invalidated buffers to the free list, too.

testing on the Dell looks good -- buffer cache is holding at 91M, and
every drop of the CPUs are utilized; no blocking processes.

ps: andrea how do these throughput numbers sound to you? :)

run 1 run 2 run 3 run 4 run 5
4227.1 4247.4 4237.2 4247.4 4240.4

you see, even inter-run variation is small!

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

\
 
 \ /
  Last update: 2005-03-22 13:50    [from the cache]
©2003-2011 Jasper Spaans