Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!rpi!zaphod.mps.ohio-state.edu!tut.cis.ohio-state.edu!ucbvax!decwrl!sgi!shinobu!odin!maddog!pkr
From: pkr@maddog.sgi.com (Phil Ronzone)
Newsgroups: comp.arch
Subject: Re: Multics & Memory mapped files
Message-ID: <4015@odin.SGI.COM>
Date: 13 Feb 90 01:10:04 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> <5180@crdgw1.crd.ge.com> <2115@crdos1.crd.ge.COM>
Sender: news@odin.SGI.COM
Organization: Silicon Graphics, Inc., Mountain View, CA
Lines: 22

In article <2115@crdos1.crd.ge.COM> davidsen@crdos1.crd.ge.com (bill davidsen) writes:
>In article <5180@crdgw1.crd.ge.com> hammondr@sunroof.crd.ge.com (Richard A Hammond) writes:
>| Everybody seems to be missing the crucial fact about memory mapped files!
>| They ONLY work for cases where the file size is < virtual address space!!!
>
>  You're right, but in general it doesn't matter. I looked over files on
>about 200 Suns for large files, and the largest single file was under
>100MB. Therefore for most applications there isn't a problem.
>
>  I'm not disagreeing that a problem is not impossible, but it's really
>uncommon. You have to support really large text and database files, but
>the average application never get a large file by 32 bit standards.


Yes, but in most MMU software/hardware designs, the user address space
is NOT 32 bits, but 32 bits - N, where N has been as high as 8.


------Me and my dyslexic keyboard----------------------------------------------
Phil Ronzone   Manager Secure UNIX           pkr@sgi.COM   {decwrl,sun}!sgi!pkr
Silicon Graphics, Inc.               "I never vote, it only encourages 'em ..."
-----In honor of Minas, no spell checker was run on this posting---------------