[lkml]   [1999]   [Mar]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    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);
    if (!--buf->b_count)
    printk("VFS: forgot an in-use buffer! (count=%d)\n",

    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: <>
    personal: <> or <>

    The Linux Scalability project:

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:50    [W:0.023 / U:6.272 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site