[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, 2006-08-17 at 08:30 -0700, Andrew Morton wrote:
    > On Thu, 17 Aug 2006 09:21:51 -0400
    > Trond Myklebust <> wrote:
    > > Exactly how would a request limit help? All that boils down to is having
    > > the VM monitor global_page_state(NR_FILE_DIRTY) versus monitoring
    > > global_page_state(NR_FILE_DIRTY)+global_page_state(NR_WRITEBACK).
    > >
    > I assume that if NFS is not limiting its NR_WRITEBACK consumption and block
    > devices are doing so, we could get in a situation where NFS hogs all of the
    > fixed-size NR_DIRTY+NR_WRITEBACK resource at the expense of concurrent
    > block-device-based writeback.

    Since NFS has no control over NR_DIRTY, how does controlling
    NR_WRITEBACK help? The only resource that NFS shares with the block
    device writeout queues is memory.

    IOW: The resource that needs to be controlled is the dirty pages, not
    the write-out queue. Unless you can throttle back on the creation of
    dirty NFS pages in the first place, then the potential for unfairness
    will exist.


    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 18:21    [W:0.020 / U:19.228 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site