Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!ux1.cso.uiuc.edu!ux1.cso.uiuc.edu!aglew
From: aglew@oberon.csg.uiuc.edu (Andy Glew)
Newsgroups: comp.arch
Subject: Re: the Multics from the black lagoon :-)
Message-ID: <AGLEW.90Feb13173046@oberon.csg.uiuc.edu>
Date: 13 Feb 90 23:30:46 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> <131761@sun.Eng.Sun.COM>
Sender: news@ux1.cso.uiuc.edu (News)
Organization: University of Illinois, Computer Systems Group
Lines: 32
In-Reply-To: lm@snafu.Sun.COM's message of 13 Feb 90 20:02:19 GMT

>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).

How about:

read:
    get the block from disk
    if the user buffer is page aligned
    	map it into the user address space
    else
    	copy it
    return

or even, if you are expecting the data not to be reused,
and your I/O system can do copies to arbitrary locations

read:
    lock the pages containing the user buffer down
    tell the I/O controller to write directly into the user memory.

--
Andy Glew, aglew@uiuc.edu