Path: utzoo!utgpu!jarvis.csri.toronto.edu!jonah
Newsgroups: comp.arch
From: jonah@db.toronto.edu (Jeffrey Lee)
Subject: Re: the Multics from the black lagoon :-)
Message-ID: <90Feb13.175832est.2845@ois.db.toronto.edu>
Organization: University of Toronto, CSRI
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>
Date: 13 Feb 90 22:59:21 GMT
Lines: 37

lm@snafu.Sun.COM (Larry McVoy) writes:

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

What about:

read:
	if (pagealigned(buffer) and multipage(buffer)) {
		read the blocks from disk into the user's buffer
	} else {
		get the blocks from disk
		copy it into the user's buffer
	}

The test should be *very* cheap in comparison to the rest of what is
being done and will avoid the copying.  It also means *less* changes to
existing user code -- just enough to make sure that read buffers are
page aligned.  Simply changing stdio and recompiling libc and
applications should speed up a large fraction of code *without* having
to rewire it use a *different* access policy (mmap) or to special case
stream vs file i/o.

The changes to the system are (a) localized, and (b) affect large numbers
of applications.

Jeff Lee -- jonah@cs.toronto.edu