lkml.org 
[lkml]   [2007]   [Sep]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: A unresponsive file system can hang all I/O in the system on linux-2.6.23-rc6 (dirty_thresh problem?)
    Date
    On Thursday 27 September 2007 23:50, Andrew Morton wrote:
    > Actually we perhaps could address this at the VFS level in another
    > way. Processes which are writing to the dead NFS server will
    > eventually block in balance_dirty_pages() once they've exceeded the
    > memory limits and will remain blocked until the server wakes up -
    > that's the behaviour we want.

    It is not necessary to restrict total dirty pages at all. Instead it is
    necessary to restrict total writeout in flight. This is evident from
    the fact that making progress is the one and only reason our kernel
    exists, and writeout is how we make progress clearing memory. In other
    words, if we guarantee the progress of writeout, we will live happily
    ever after and not have to sell the farm.

    The current situation has an eerily similar feeling to the VM
    instability in early 2.4, which was never solved until we convinced
    ourselves that the only way to deal with Moore's law as applied to
    number of memory pages was to implement positive control of swapout in
    the form of reverse mapping[1]. This time round, we need to add
    positive control of writeout in the form of rate limiting.

    I _think_ Peter is with me on this, and not only that, but between the
    too of us we already have patches for most of the subsystems that need
    it, and we have both been busy testing (different subsets of) these
    patches to destruction for the better part of a year.

    Anyway, to fix the immediate bug before the one true dirty_limit removal
    patch lands (promise) I think you are on the right track by noticing
    that balance_dirty_pages has to become aware of how congested the
    involved block device is, since blocking a writeout process on an
    underused block device is clearly a bad idea. Note how much this idea
    looks like rate limiting.

    [1] We lost the scent for a number of reasons, not least because the
    experimental implementation of reverse mapping at the time was buggy
    for reasons entirely unrelated to the reverse mapping itself.

    Regards,

    Daniel
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2007-09-29 02:49    [W:4.322 / U:0.044 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site