Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!brutus.cs.uiuc.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: Date: 12 Feb 90 18:59:22 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> Sender: news@ux1.cso.uiuc.edu (News) Organization: University of Illinois, Computer Systems Group Lines: 27 In-Reply-To: henry@utzoo.uucp's message of 7 Feb 90 22:18:00 GMT >>UNIX is just >>beginning to implement some of the ideas which have been working in >>Multics for two decades, such as mapping files to memory. > >Gee, how could we ever have lived without that for two decades? :-) >Maybe because we don't need it and it doesn't buy us very much? I'm glad to see that I'm not the only one thinking this way. Memory mapped files are great if you access files like memory - if you seek around in them randomly, etc. But memory mapped files can positivel *hurt* if you do sequential scans, and your OS doesn't provide an expected access type hint to prevent the scan from emptying the existing page store. Plus, files are *large*. There are people telling me that we won't need more than 32 bits of memory address, and I already have more than that in data. (True, this is just saying let's not put a broken limit on file sizes just because we already have one on memory) On the other hand... the XMF (Xylophone Memory System) reported by HP in SOSP 89 does some interesting tricks. The main one being that software computation of the file logic disk block to physical disk block to buffer cache address computation is short-circuited by using the virtual address translation mechanisms. -- Andy Glew, aglew@uiuc.edu