[lkml]   [2008]   [Aug]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: high latency NFS
    On Fri, Aug 01, 2008 at 05:23:20PM +1000, Dave Chinner wrote:
    > On Thu, Jul 31, 2008 at 05:03:05PM +1000, Neil Brown wrote:
    > > You might want to track the max length of the request queue too and
    > > start more threads if the queue is long, to allow a quick ramp-up.
    > Right, but even request queue depth is not a good indicator. You
    > need to leep track of how many NFSDs are actually doing useful
    > work. That is, if you've got an NFSD on the CPU that is hitting
    > the cache and not blocking, you don't need more NFSDs to handle
    > that load because they can't do any more work than the NFSD
    > that is currently running is.
    > i.e. take the solution that Greg banks used for the CPU scheduler
    > overload issue (limiting the number of nfsds woken but not yet on
    > the CPU),

    I don't remember that, or wasn't watching when it happened.... Do you
    have a pointer?

    > and apply that criteria to spawning new threads. i.e.
    > we've tried to wake an NFSD, but there are none available so that
    > means more NFSDs are needed for the given load. If we've already
    > tried to wake one and it hasn't run yet, then we've got enough
    > NFSDs....

    OK, so you do that instead of trying to directly measure

    > Also, NFSD scheduling needs to be LIFO so that unused NFSDs
    > accumulate idle time and so can be culled easily. If you RR the
    > nfsds, they'll all appear to be doing useful work so it's hard to
    > tell if you've got any idle at all.

    Those all sound like good ideas, thanks.

    (Still waiting for a volunteer for now, alas.)


     \ /
      Last update: 2008-08-01 21:19    [W:0.020 / U:3.108 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site