[lkml]   [2006]   [Aug]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: RFC - how to balance Dirty+Writeback in the face of slow writeback.
    On Thu, 17 Aug 2006 14:08:58 +1000
    Neil Brown <> wrote:

    > So I think you need to throttle when Dirty+Writeback hits dirty_ratio


    > (which we don't quite get right at the moment). But the trick is to
    > throttle gently and fairly, rather than having a hard wall so that any
    > one who hits it just stops.

    I swear, I had all this working in 2001. Perhaps I dreamed it. But I
    specifically remember testing that processes which were performing small,
    occasional writes were not getting blocked behind the activity of other
    processes which were doing massive write()s. Ho hum, not to worry.

    I guess a robust approach would be to track, on a per-process,
    per-threadgroup, per-user, etc basis the time-averaged page-dirtying rate.
    If it is "low" then accept the dirtying. If it is "high" then this process
    is a heavy writer and needs throttling earlier. Up to a point - at some
    level we'll need to throttle everyone as a safety net if nothing else.

    Something like that covers the global dirty+writeback problem. The other
    major problem space is the multiple-backing-device problem:

    a) One device is being written to heavily, another lightly

    b) One device is fast, another is slow.

    Thus far, the limited size of the request queues has saved us from really,
    really serious problems. But that doesn't work when lots of disks are
    being used. To solve this properly we'd need to account for
    dirty+writeback(+unstable?) pages on a per-backing-dev basis.

    But as a first step, yes, using dirty+writeback for the throttling
    threshold and continuing to rely upon limited request queue size to save us
    from disaster would be a good step.

    btw, one thing which afaik NFS _still_ doesn't do is to wake up processes
    which are stuck in blk_congestion_wait() when NFS has retired a bunch of
    writes. It should do so, otherwise NFS write-intensive workloads might end
    up sleeping for too long. I guess the amount of buffering and hysteresis
    we have in there has thus far prevented any problems from being observed.
    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: 2006-08-17 08:17    [W:0.022 / U:13.060 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site