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.) --b. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
