Jonathan Stone wrote:
> I dont' propose to change any of the default values,
> but I would like to raise some compiled-in upper bounds:
> 
> usr.sbin/nfsd/nfsd.c: MAXNFSDCNT to 128
> 	      still on the low side, for specsfs runs.
> 
> sys/nfs/nfs.h NFS_MAXRAHEAD from 4 to 32 
> 	      (32 requests * 32k reads comes to 1 Mbyte), barely
> 	      enough to fill a 10ms latency at 100 Mbyte/sec.

Why is there any upper limit at all? The limits should be either
removed or bumped to even higher value, IMHO.

> I'm also wondering how much we could gain by turning worker nfds's
> (.e., not the master process which listens for inbound TCP
> connections) into kthreads.  Seems like the same approach used for
> nfsiod's would also work here; and (on some arches at least) switching
> from one kthread to another should not require an mmu context-switch.
> Given a hundred-odd nfsds and a machine not doing much else, the
> savings would add up.

Since the worker threads only call nfssvc() in loop, this would be
reasonable to do. Alternatively, we could just use normal userland
threads instead of forked processes there, saving MMU switches too.

Jaromir
-- 
Jaromir Dolecek <jdolecek@NetBSD.org>            http://www.NetBSD.cz/
-=- We should be mindful of the potential goal, but as the Buddhist -=-
-=- masters say, ``You may notice during meditation that you        -=-
-=- sometimes levitate or glow.   Do not let this distract you.''   -=-