[lkml]   [2007]   [Sep]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: A unresponsive file system can hang all I/O in the system on linux-2.6.23-rc6 (dirty_thresh problem?)
    On Fri, 28 Sep 2007 13:00:53 -0400 Trond Myklebust <> wrote:

    > On Thu, 2007-09-27 at 23:50 -0700, 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.
    > >
    > > What we _don't_ want to happen is for other processes which are writing to
    > > other, non-dead devices to get collaterally blocked. We have patches which
    > > might fix that queued for 2.6.24. Peter?
    > Do these patches also cause the memory reclaimers to steer clear of
    > devices that are congested (and stop waiting on a congested device if
    > they see that it remains congested for a long period of time)? Most of
    > the collateral blocking I see tends to happen in memory allocation...

    No, they don't attempt to do that, but I suspect they put in place
    infrastructure which could be used to improve direct-reclaimer latency. In
    the throttle_vm_writeout() path, at least.

    Do you know where the stalls are occurring? throttle_vm_writeout(), or via
    direct calls to congestion_wait() from page_alloc.c and vmscan.c? (running
    sysrq-w five or ten times will probably be enough to determine this)

    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-09-28 20:53    [W:0.021 / U:3.392 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site