Path: utzoo!attcan!uunet!aplcen!uakari.primate.wisc.edu!zaphod.mps.ohio-state.edu!usc!snorkelwacker!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 & SUN4s Message-ID: Date: 6 Jul 90 21:38:29 GMT References: <3300142@m.cs.uiuc.edu> <1990Jun29.154940.22762@tera.com> <2936@skye.ed.ac.uk> <1990Jul06.003628.2633@esegue.segue.boston.ma.us> <1122@sirius.ucs.adelaide.edu.au> Sender: pcg@aber-cs.UUCP Organization: Coleg Prifysgol Cymru Lines: 49 In-reply-to: francis@chook.ua.oz.au's message of 6 Jul 90 13:30:48 GMT In article <1122@sirius.ucs.adelaide.edu.au> francis@chook.ua.oz.au (Francis Vaughan) writes: [ ... on the SPARC MMU and TLB, and paging page tables ... ] Each pmeg holds 32 entries (or on the SS-1 64 entries) where each entry refers to a page. SS-1s have MMU memory for only 128 pmegs or 64*128 =8192 page entries. That means it can only hold entries for 32 megabytes of virtual memory agragate for all processes running on the machine. Thhat would be entirely adequate if this were a TLB; a TLB with 8192 entries would be quite large, actually. The catch of course is the granularity of this TLB: Since that is in chunks of 64*4=256KB and you need a seperate chunk (therefore pmeg) for data, bss, code, no matter how little is used the system rapidly runs out of pmegs. The Sun-3s were even worse, they cached entire page tables in one of typically eight slots; if there were more than eight active address spaces you had the page tables (several dozen kilobytes -- 256MB of 8KB pages) swapped to/from memory. If the OS needs a pmeg and the hardware table is full, it selects a used one and trashes it. This is done with a software cache manager that copies the kernel version of the table into the hardware table. You take quite a perfomance hit when this happens. The crazy thing is that SUN-OS places all the pages refered to by the reused pmeg onto the free list. I don't know whether this is still true, but SunOS used to have a round robin scheduler, i.e. FIFO, with a page table cache replacement algorithm approximating LRU, i.e. LIFO. It is well known that LIFO replacement with a FIFO access pattern results in a miss on every single access as soon as the length of the FIFO exceeds the depth of the LIFO. This resulted (and probably still results) in the wonderful phenomenon, easily observed, that with 9 active address spaces and an 8 context cache, a cache miss occurred on every single address space activation. A wonderful example of the left hand not knowing what the right hand is up to. -- 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