Path: utzoo!attcan!uunet!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: 30 Jun 90 22:03:10 GMT References: <3300142@m.cs.uiuc.edu> <9758@pt.cs.cmu.edu> Sender: pcg@aber-cs.UUCP Organization: Coleg Prifysgol Cymru Lines: 61 In-reply-to: lindsay@MATHOM.GANDALF.CS.CMU.EDU's message of 28 Jun 90 20:23:51 GMT In article <9758@pt.cs.cmu.edu> lindsay@MATHOM.GANDALF.CS.CMU.EDU (Donald Lindsay) writes: [ ... on paging page tables ... ] The OS designer balances memory demands and swap speed against swap frequency. Note that a 16 byte table entry per 512 byte page is only a 3% overhead. Most designs run leaner. Actually this 3% overhead can be mostly obviated, as the need of paging page tables. The clear win is to have reverse page map tables for the paging itself, whose size is only proportional to the size of real memory, and segment map tables for the description of valid stretches of address space. 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. 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). The chip designer does control the cost of a simple TLB refill. For example, the 88000 and 68020 (well, 68851) have table-walk hardware, whereas the R3000 designers punted TLB refill to an interrupt handler and some special instructions. Refilling the TLB in software is arguably a win -- most obviously because it allows collection of a lot of interesting statistics, and this can help the page replacement policy. It also gets the hardware designer out of some very sticky points. I think that the very best references on the subject are Ibbet and Morris "The MU5 Computer System", MacMillan, and some MU6 papers and reports by Knowles, Woods, Edwards, etc... from Manchester University. They are *the* virtual memory people, incidentally. Discussions on this topic usually move on the the issue of Process ID tags, which are variously a few bits (MIPS) or one bit (88000). (Does the i860 have PIDs?) From there one gets into task switch issues, which is to say, flushing. :-). IMNHO TLBs without address space (*not* process, please) id tags are ridiculous. Some IBM guy measured the hit from cold restarting translation of address space maps because of TLB flush, and it is, ehm, arresting. I find it incredible that system architects in this time and age still design MMUs without address space tags in the TLBs. But then somebody *did* design the SUN-3 MMU, and the address space tag issue looks miniscule compared to what has been perpetrated there. :-> :-/. Hey, after all you win the benchmark wars on MIPS (the four letter word) ratings and other CPU, or at best, single user, oriented ratings. -- 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