[lkml]   [2007]   [Jan]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] nfs: fix congestion control

    On Tue, 2007-01-16 at 23:08 +0100, Peter Zijlstra wrote:
    > Subject: nfs: fix congestion control
    > The current NFS client congestion logic is severely broken, it marks the
    > backing device congested during each nfs_writepages() call and implements
    > its own waitqueue.
    > Replace this by a more regular congestion implementation that puts a cap
    > on the number of active writeback pages and uses the bdi congestion waitqueue.
    > NFSv[34] commit pages are allowed to go unchecked as long as we are under
    > the dirty page limit and not in direct reclaim.
    > A buxom young lass from Neale's Flat,
    > Bore triplets, named Matt, Pat and Tat.
    > "Oh Lord," she protested,
    > "'Tis somewhat congested ...
    > "You've given me no tit for Tat."

    What on earth is the point of adding congestion control to COMMIT?
    Strongly NACKed.

    Why 16MB of on-the-wire data? Why not 32, or 128, or ...
    Solaris already allows you to send 2MB of write data in a single RPC
    request, and the RPC engine has for some time allowed you to tune the
    number of simultaneous RPC requests you have on the wire: Chuck has
    already shown that read/write performance is greatly improved by upping
    that value to 64 or more in the case of RPC over TCP. Why are we then
    suddenly telling people that they are limited to 8 simultaneous writes?


    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-01-17 00:37    [W:0.025 / U:87.652 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site