Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!spool.mu.edu!snorkelwacker.mit.edu!thunder.mcrcim.mcgill.edu!mouse
From: mouse@thunder.mcrcim.mcgill.edu (der Mouse)
Newsgroups: comp.unix.internals
Subject: Re: NFS and slow links
Message-ID: <1991Feb27.110403.1985@thunder.mcrcim.mcgill.edu>
Date: 27 Feb 91 11:04:03 GMT
References: <1991Feb26.033503.12885@Citicorp.COM>
Organization: McGill Research Centre for Intelligent Machines
Lines: 37

In article <1991Feb26.033503.12885@Citicorp.COM>, dsamperi@Citicorp.COM (Dominick Samperi) writes:
[ stuff about linking when the a.out is NFS-remote ]

> But there is a significant hit when NFS is used to copy a large file
> (or create a large executable file).  One observation that I cannot
> explain is the fact that large executables that are located in remote
> (NFS-mounted) directories seem to start up quickly (faster than a
> straight copy).

One plausible reason for this is that the executable is probably a
ZMAGIC executable, so it's not read in all at once.  Starting it up is
a matter of the following (I'm glossing over things here; let's not get
excessively nit-picky):

	- allocating swap space for the data segment (data+bss in the
	  executable file)

	- loading the initialized data

	- creating demand-zero pages for the bss

	- branching to the entry point

Notice that the text segment is not brought over - yet.  Instead, it is
brought over on demand using the normal paging mechanisms: trying to
execute an instruction that happens to not be in core at the moment
causes a page fault, and that page of the executable is brought over.

Try linking your executable as an OMAGIC executable instead, so the
text segment isn't paged out of the a.out file, and see if the
performance difference goes away....

					der Mouse

			old: mcgill-vision!mouse
			new: mouse@larry.mcrcim.mcgill.edu