Path: utzoo!attcan!uunet!mailrus!cs.utexas.edu!sun-barr!newstop!sun!amdahl!terry From: terry@uts.amdahl.com (Lewis T. Flynn) Newsgroups: comp.arch Subject: Re: Multics & Memory mapped files Message-ID: Date: 12 Feb 90 17:22:24 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> Reply-To: terry@amdahl.uts.amdahl.com (Lewis T. Flynn) Organization: Amdahl Corporation, Sunnyvale CA Lines: 83 In article pcg@rupert.cs.aber.ac.uk (Piercarlo Grandi) writes: > >The general approach of doing memory mapped things is to assume >that they exist independently from the process address space, and >that you can map sections of the entity in sections of the >address space; in this way an entity may be much larger than an >address space (see how MUSS does it, SP&E August 1979). > >You separate address space from data space entirely; a job may >have several data space segments that are not mapped in any >address space window. > >If you allow a user program the ability to manipulate its address >space map, this becomes very easy to do; you can even (like in >Mach) have virtual data segments, where the address space fault >handler fakes data instead of mapping in data space entity. True. >Once you have this, you discover all the problems with memory mapped >entities. One can be easily solved, the other not so easily. > >The first is data space aliasing. You have portions of data space >visible thru different ranges of address space, possibly multiply >in the same address space, or multiply in different address >spaces (shared memory). This is bad. The cure is to allow it only >for irrevocably read only segments; the others can only be mapped >in one place at a time; address spaces take turns at mapping a >segment (this is the MUSS approach -- MUSS has convenient >'messages' that pass around permission to map a segment). This >makes for safe interprocess communication, and need not (on a >suitable HW VM architecture) be inefficient at all. I don't understand why this is bad. In the implementation I am familiar with, users mapped in according to their needs and priveleges (if you only had read access, that's all you could map in; if you had read/write, you could do either). If more than one application mapped in read/write they had to coordinate, but that wasn't too different to do. Perhaps my confusion is due to an invalid comparison. KeyKOS segments only loosely correspond to files and usually shared files were more convenient to access using a file paradigm (like read/write/lseek) so that multiple read/write access was managed transparently. >The second problem is address space aliasing. This is that you >may map the same segment at different times in different portions >of the address space. This means that you cannot use absolute >addresses in a segment (as well as the obvious semantic hazards). >The *only* solution is to have a single address space for all >processes, i.e. a capability machine (if you want protection >:->). If you mean a single level store that is used to build all other address spaces, then I agree. That's the most successful way I've heard of (my own experience in this area is limited, but I was fortunate enough to work with exceptional people who had been studying this particular problem for a long time). Capabilities and objects sure make life simpler here. [other discussion] >A very large database can be built of multiple segments, and if >they are properly implemented there is really no limit of size, >as you slide multiple windows over multiple segments. A suitably >written library can make this virtually painless. Note that something >similar is always needed, except on single very large address space >machines. An alternative is to use a segment definition that is independent of the hardware limitation. This doesn't remove the multiple window requirement, but, for most practical cases, does remove the need for multiple segments for size reasons. In the case with which I am most familiar, the implemenation allowed a segment size of 2**59 bytes on a machine whose physical segment was limited to 2**24 bytes. You mapped in the part you needed, and the VMM worried about the rest. >-- >Piercarlo "Peter" Grandi | ARPA: pcg%cs.aber.ac.uk@nsfnet-relay.ac.uk >Dept of CS, UCW Aberystwyth | UUCP: ...!mcvax!ukc!aber-cs!pcg >Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk Terry Disclaimer: I have no idea what Amdahl's views on these matters are.