[lkml]   [2007]   [Oct]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 5/5] writeback: introduce writeback_control.more_io to indicate more io
    On Wed, Oct 03, 2007 at 07:47:45AM +1000, David Chinner wrote:
    > On Tue, Oct 02, 2007 at 04:41:48PM +0800, Fengguang Wu wrote:
    > > wbc.pages_skipped = 0;
    > > @@ -560,8 +561,9 @@ static void background_writeout(unsigned
    > > min_pages -= MAX_WRITEBACK_PAGES - wbc.nr_to_write;
    > > if (wbc.nr_to_write > 0 || wbc.pages_skipped > 0) {
    > > /* Wrote less than expected */
    > > - congestion_wait(WRITE, HZ/10);
    > > - if (!wbc.encountered_congestion)
    > > + if (wbc.encountered_congestion || wbc.more_io)
    > > + congestion_wait(WRITE, HZ/10);
    > > + else
    > > break;
    > > }
    > Why do you call congestion_wait() if there is more I/O to issue? If
    > we have a fast filesystem, this might cause the device queues to
    > fill, then drain on congestion_wait(), then fill again, etc. i.e. we
    > will have trouble keeping the queues full, right?

    You mean slow writers and fast RAID? That would be exactly the case
    these patches try to improve.

    The old writeback behaviors are sluggish when there is
    - single big dirty file;
    - single congested device
    the queues may well build up slowly, hit background_limit, and
    continue to build up, until hit dirty_limit. That means:
    - kupdate writeback could leave behind many expired dirty data
    - background writeback used to return prematurely
    - eventually it relies on balance_dirty_pages() to do the job,
    which means
    - writers get throttled unnecessarily
    - dirty_limit pages are pinned unnecessarily

    This patchset makes kupdate/background writeback more responsible,
    so that if (avg-write-speed < device-capabilities), the dirty data are
    synced timely, and we don't have to go for balance_dirty_pages().

    So for your question of queue depth, the answer is: the queue length
    will not build up in the first place.

    Also the name of congestion_wait() could be misleading:
    - when not congested, congestion_wait() will wakeup on write
    - when congested, congestion_wait() could also wakeup on write
    completions on other non-congested devices.
    So congestion_wait(100ms) normally only takes 0.1-10ms.

    For the more_io case, congestion_wait() serves more like 'to take a
    breath'. Tests show that the system could go mad without it.


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

     \ /
      Last update: 2007-10-03 03:37    [W:0.023 / U:13.376 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site