Path: utzoo!utgpu!watserv1!watmath!att!rutgers!mailrus!wuarchive!mit-eddie!bloom-beacon!eru!luth!sunic!mcsun!ukc!dcl-cs!aber-cs!odin!pcg From: pcg@cs.aber.ac.uk (Piercarlo Grandi) Newsgroups: comp.arch Subject: Re: Paging page tables Message-ID: Date: 10 Jul 90 13:35:34 GMT References: <3300142@m.cs.uiuc.edu> <9758@pt.cs.cmu.edu> <58001@bbn.BBN.COM> Sender: pcg@aber-cs.UUCP Organization: Coleg Prifysgol Cymru Lines: 56 In-reply-to: lkaplan@bbn.com's message of 5 Jul 90 21:04:01 GMT In article <58001@bbn.BBN.COM> lkaplan@bbn.com (Larry Kaplan) writes: [ I had written: ] >In this way you have the best of all worlds, because >you can have a very large address space with only locally dense data >space mappings, and a very low overhead. This reverse scheme fails to save you much on machines with large physical memories which are becomming more and more common. We build UNIX machines that regularly have 1 or more gigabytes of real physical memory. Yes, but as somebody else has already remarked, reverse maps mean that the overhead is proportional to physical size, i.e. for a given memory configuration it is constant, while direct maps are proportional to virtual size. Of course if your workload underutilizes real memory, that is the combined sizes of all virtual address spaces is less than the size of the physical memory you lose, but then you are wasting much more space in data space than in translation tables. Allocating segment tables on demand is certainly helpful, though. The only way to get around the fundamentally poor encoding of direct maps and their ensuing unsuitability for large sparse locally dense address spaces is to use many levels of page tables; three levels is not common (region, segment, page). This has problems of its own, typically not just latency (TLBs help here as well), but complicated fault handling and restartability. >I am quite sure that Don Lindsay could expound on the advantages of >this approach from direct observation, as the Mach portable virtual >memory code uses exactly this approach (well, the MACH people actually >bitch about the reverse map MMU in the IBM RISCs, because they abuse >copy-on-write, and reverse map makes it difficult, but this is just >because they use the wrong virtual memory model, i.e. copy-on-write). Wrong virtual model? This sounds like a religious comment. Religious maybe, but the eveils of data space aliasing are there for everybody to see... I at least do see them :-). My understanding is that UNIX has wanted to have true copy-on-write semantics for a while but just never got around to it. I still think that fork() has the wrong semantics and a more decoupled design would be neater and more efficient. If you stay within the fork() based model of address space coupled to control thread, creating a new control thread requires creating a new address space, and copy-on-write is just a fairly tolerable implementation technique. On a PDP-11 it was not really terribly necessary, with its 64KB limit on data space. -- Piercarlo "Peter" Grandi | ARPA: pcg%cs.aber.ac.uk@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk