Path: utzoo!attcan!uunet!aplcen!uakari.primate.wisc.edu!brutus.cs.uiuc.edu!apple!sun-barr!newstop!sun!snafu!lm
From: lm@snafu.Sun.COM (Larry McVoy)
Newsgroups: comp.arch
Subject: Re: the Multics from the black lagoon :-)
Message-ID: <131761@sun.Eng.Sun.COM>
Date: 13 Feb 90 20:02:19 GMT
References: <8859@portia.Stanford.EDU> <20571@watdragon.waterloo.edu> <49956@sgi.sgi.com> <4791@helios.ee.lbl.gov> <2093@crdos1.crd.ge.COM> <1990Feb7.221800.804@utzoo.uucp> <2106@crdos1.crd.ge.COM> <1990Feb12.204658.18336@utzoo.uucp>
Sender: news@sun.Eng.Sun.COM
Reply-To: lm@sun.UUCP (Larry McVoy)
Organization: Sun Microsystems, Mountain View
Lines: 41

In article <1990Feb12.204658.18336@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes:
>In article <2106@crdos1.crd.ge.COM> davidsen@crdos1.crd.ge.com (bill davidsen) writes:
>>  File mapping... replaces
>>the runtime and kernel buffering scheme with the kernel page mechanism,
>>which is often much faster.
>>  In VMS the performance gain was about 30%...
>
>I'm afraid my reaction to this is "what would the performance gain have
>been if the same effort had been put into speeding up normal I/O"?
>Modulo one or two requirements like alignment, if there is *any* real
>performance difference with only one process involved, it means you
>are comparing apples to oranges -- either the kernel I/O code has not
>been optimized to exploit the MMU, or you are comparing an I/O version
>which works (say) 512 bytes at a time to a mapped version that grabs
>the whole file at once.  When only one process is involved, read() and
>write() do everything that mmap() does, and there is no reason why they
>should be any slower.

Let's see, 

read:
	    get the block from disk
	    copy it out to the user buffer
	    return

mmap:
	    get the block from disk
	    map it into the user's address space
	    return

It seems to me that there is in extra copy in there.  In kernels that I've
profiled, this copy shows up very high on the list (in the top 2 or 3).

>SVR4:  every feature you ever |     Henry Spencer at U of Toronto Zoology
>wanted, and plenty you didn't.| uunet!attcan!utzoo!henry henry@zoo.toronto.edu


---
What I say is my opinion.  I am not paid to speak for Sun, I'm paid to hack.
    Besides, I frequently read news when I'm drjhgunghc, err, um, drunk.
Larry McVoy, Sun Microsystems     (415) 336-7627       ...!sun!lm or lm@sun.com