cprice@mips.COM (Charlie Price) (02/16/91)
In article <14013@sunquest.UUCP> terry@venus.sunquest.com (Terry R. Friedrichsen) writes: > >1) Given the "problem" I refer to above with the Sun, do other workstations >like MIPS R3000-based ones or the IBM RS/6000 have some similar problem? The "problem" is just a characteristic of some Sun MMU design. It always costs something to keep a lot of translation information around. You make various tradeoffs when designing a machine. The Sun lower-end design is only able to keep information for ~8 different processes in high-speed hardware without needing to do some relatively-expensive refill from main memory. This costs in performance in environments that are highly multiprogrammed. On the other hand, this lets them deliver a fairly low cost workstation. The more-expensive, faster, more capable server machines have larger amounts of memory for this sort of thing. About the MIPS processors: The R2000 and R3000 have the MMU built into the processors (unlike the Sun systems where it is external logic). * 64-entry, fully-associative TLB (8 more-or-less reserved for the kernel) * 6-bit Process_ID tag stored with the TLB entries so we don't have to flush on context switches. * software refill on miss (about 10 instructions) * Random replacement policy (with 56 entries for user) assisted by a write-random instruction. Compared to the real work involved in a context switch and the system calls used to cause the switches, any TLB refills needed are probably down in the noise. The R4000 looks about the same, the details differ a bit. The R6000, the ECL processor, is quite different in implementation. The TLB is in secondary cache, but most memory references don't need to be completely translated because the cache system makes good use of virtual-tags to get most cache hits right without neededing the complete physical address. -- Charlie Price cprice@mips.mips.com (408) 720-1700 MIPS Computer Systems / 928 Arques Ave. / Sunnyvale, CA 94086-23650