Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!auspex!guy From: guy@auspex.auspex.com (Guy Harris) Newsgroups: comp.protocols.nfs Subject: Re: NFS Performance Message-ID: <8440@auspex.auspex.com> Date: 20 Jun 91 20:38:54 GMT References: <1991Jun12.110005.3386@fennel.cc.uwa.oz.au> Organization: Auspex Systems, Santa Clara Lines: 28 >It's a well known phenomenon with early releases of SunOS 4. 8 nfsds >thrash the MMU/cache of a sun 3. This cache has exactly 8 slots; if only >the 8 nfsds are active, everything is fine; as soon as another process >starts to run, you have 9 processes scheduled round robin, and the >MMU/cache is managed LRU. Every context switch brings a cache reload, >which takes about 1ms on the machine you mention... and so on. Could you please point to the lines of source code in those early releases that either 1) cause NFS daemons not to release their user-mode address space and context or 2) cause context switches to processes without contexts (kernel processes such as NFS daemons) to reload the context register? If such code exists, it must have been in a release prior to SunOS 4.0.3, as: 1) the "nfs_svc()" call in SunOS 4.0.3, which the "nfsd" program makes to create an NFS daemon, calls "relvm()" which completely discards the user-mode address space of the process (e.g., it nulls out "u.u_procp->p_as"); 2) the context-switching code in SunOS 4.0.3 ("resume()") won't bother reloading the context register if it's switching to a process with no user-mode address space (i.e., with a null "u.u_procp->p_as"). Given that, the 8 vs. 4 has nothing whatsoever to do with the number of contexts in 4.0.3. Maybe releases prior to that missed 1) or 2), but I tend to doubt it.