Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!uwm.edu!ux1.cso.uiuc.edu!ux1.cso.uiuc.edu!aglew From: aglew@oberon.csg.uiuc.edu (Andy Glew) Newsgroups: comp.arch Subject: Re: Inverted Page Tables Message-ID: Date: 22 Feb 90 00:35:52 GMT References: <9708@spool.cs.wisc.edu> <20270@cfctech.cfc.com> <11112@encore.Encore.COM> <753@dgis.dtic.dla.mil> <3606@uceng.UC.EDU> <757@dgis.dtic.dla.mil> <4852@scolex.sco.COM> <29718@brunix.UUCP> <6998@celit.fps.com> <43367@ame Sender: news@ux1.cso.uiuc.edu (News) Organization: University of Illinois, Computer Systems Group Lines: 22 In-Reply-To: lindsay@MATHOM.GANDALF.CS.CMU.EDU's message of 21 Feb 90 22:43:56 GMT >>1) Several posters have mentioned that there is some unspecified but obvious >>(to them) major problem with using inverted page tables together with >>memory mapped files. I wonder if someone could enlighten us regarding >>this problem, since apparently it isn't obvious to every system architect :-) > >The big problem is with sharing. > >The word "inverted" is used, because the table is a map from physical >addresses to virtual addresses. More precisely, you use an array, and >use physical page numbers as subscripts. Each table entry tells you >what virtual page is mapped to there. > >SO: only one page can be mapped to there. Unless, of course, the OS >goes through a fair bit of grief to make the machine work right in >spite of its design. Now, let's see. Physical page addresses map to virtual? Via a hash function? What ever happened to hash chaining? :-) Especially if the TLB miss is handled in software (like on MIPS). -- Andy Glew, aglew@uiuc.edu