Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!uunet!auspex!guy
From: guy@auspex.auspex.com (Guy Harris)
Newsgroups: comp.protocols.nfs
Subject: Re: how many nfsd's should I run?
Message-ID: <6498@auspex.auspex.com>
Date: 8 Mar 91 19:41:27 GMT
References: <28975@cs.yale.edu> <2936@redstar.cs.qmw.ac.uk>
Organization: Auspex Systems, Santa Clara
Lines: 39

>>>If you have too many processes competing for the limited slots in the
>>>hardware context cache, your machine will roll over and die.
>
>>Given that nfsd runs in kernel mode inside nfssvc(), is this statement
>>about contexts correct?  If so, why is the default number of nfsds for
>>Sun 3s 8?
>
>1) Hardware contexts are a feature of the MMU/Instruction cache, and so Greg's 
>comment is specific to Sun4 machines.

Eh?  Hardware contexts aren't specific to Sun-4 machines; the *number*
of hardware contexts in various Sun machines that have them (not all do;
the Sun386i and 68030-based Sun-3's don't) is specific to the machine -
Sun-3s that have them have 8 contexts, some SPARC-based Suns have 16,
others have 8, others have 64.  (The "instruction cache" hasn't anything
to do with it; the only Suns I know of with instruction caches are the
Sun-3s, with the on-chip I caches and *maybe* the 4/110, due to the way
the software allocates physical addresses for pages so as not to make
the "static column RAM" "cache" not thrash.  The cache in the Suns I
know about is a unified I/D cache.)

>2) The nfssvc() system call never returns, but the process slot of the caller 
>is used as a cheap way to implement multi-threading in the kernel. When an 
>nfsd runs out of work, it does a sleep() waiting for requests to come in on 
>the socket bound to UDP port 2049. When it gets handles a request involving 
>disk I/O, it sleeps waiting for the result. All nice straightforward kernel 
>stuff provided that you have a process table entry to work with, but 
>impossible if you don't. Using a kernel like Mach or Chorus it would be done 
>with true multi-threading of the code, so lightweight process switches would 
>be the only overhead; under most UNIX systems it takes the full context switch 
>and hence can thrash the hardware contexts (if applicable).

It may not be applicable, *even on machines with hardware contexts*.  As
Larry McVoy has already noted, as of SunOS 4.0, the NFS server processes
release their address space; this means that, when a context switch is
done to such a process, the system doesn't bother switching the hardware
context on SPARC-based Suns, or switches to context 0 (the kernel
context) on Sun-3s with 68020s.  I.e., it won't thrash the hardware
contexts....