lkml.org 
[lkml]   [1999]   [Feb]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    Patch in this message
    /
    From
    Subject[PATCH] VM buffer behaviour, was Re: [Wait!] pre4 is broken!
    Date
    Hi,

    On Mon, 15 Feb 1999 15:46:05 -0800 (PST), Simon Kirby <sim@netnation.com> said:

    > While running "vmstat 1" in another console. It looked pretty happy until
    > "rm" started to run -- it kept "rmming" forever, in fact. vmstat showed a
    > solid ~850kb/sec being written out to disk (previously about 10MB/sec when
    > the file was being created), and it wouldn't stop. The system was very
    > responsive, however -- logging in to a new console, etc, was all pretty
    > good.

    > Luckily it didn't seem to destroy anything, so I'm guessing it's stuck
    > somehow flushing out the same buffers over and over again.

    It looks like it is simply being too aggressive about starting the
    wakeup_bdflush(1) behaviour. This is the problem with such a patch: if
    we make write buffering less aggressive then it is far too easy to lose
    write throughput on larger machines.

    Anyway, I have a couple of people currently testing or waiting to test
    the patch below against 2.2.2-pre4. The wakeup_bdflush(1) test is now
    conditional _only_ on the number of locked buffers, independently of
    the number of dirty buffers. The more people who can try this before
    2.2.2-pre4, the better.

    More importantly, it adds the check in bdflush to refile locked
    buffers on the clean list after IO. Linus, you missed this bit of the
    patch from 2.2.2-pre4, and it is the most important part of it:
    without that, it is impossible to know how many of the BUF_LOCKED
    buffers are _really_ locked, and therefore how to throttle the writes
    while keeping the IO queues full. There's no point releasing
    2.2.2-pre4 without that bit of the patch: it will simply stop doing
    anything useful (as Simon found) because the refile_buffer logic will
    see there being far too many BUF_LOCKED buffers, even after the IO has
    completed.

    --Stephen

    ----------------------------------------------------------------
    --- fs/buffer.c~ Tue Feb 16 11:52:10 1999
    +++ fs/buffer.c Tue Feb 16 11:57:55 1999
    @@ -877,8 +877,8 @@
    * If too high a percentage of the buffers are dirty...
    */
    if (nr_buffers_type[BUF_DIRTY] > too_many ||
    - (size_buffers_type[BUF_DIRTY] + size_buffers_type[BUF_LOCKED])/PAGE_SIZE > too_large) {
    - if (nr_buffers_type[BUF_LOCKED] > 2 * bdf_prm.b_un.ndirty)
    + size_buffers_type[BUF_DIRTY]/PAGE_SIZE > too_large) {
    + if (nr_buffers_type[BUF_LOCKED] > 3 * bdf_prm.b_un.ndirty)
    wakeup_bdflush(1);
    else
    wakeup_bdflush(0);
    @@ -1924,7 +1924,7 @@
    #ifdef DEBUG
    for(nlist = 0; nlist < NR_LIST; nlist++)
    #else
    - for(nlist = BUF_DIRTY; nlist <= BUF_DIRTY; nlist++)
    + for(nlist = BUF_LOCKED; nlist <= BUF_DIRTY; nlist++)
    #endif
    {
    ndirty = 0;
    @@ -1943,11 +1943,16 @@
    }

    /* Clean buffer on dirty list? Refile it */
    - if (nlist == BUF_DIRTY && !buffer_dirty(bh) && !buffer_locked(bh))
    - {
    - refile_buffer(bh);
    - continue;
    - }
    + if (nlist == BUF_DIRTY && !buffer_dirty(bh)) {
    + refile_buffer(bh);
    + continue;
    + }
    +
    + /* Unlocked buffer on locked list? Refile it */
    + if (nlist == BUF_LOCKED && !buffer_locked(bh)) {
    + refile_buffer(bh);
    + continue;
    + }

    if (buffer_locked(bh) || !buffer_dirty(bh))
    continue;
    -
    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:2.736 / U:0.016 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site