Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!ames!oliveb!pyramid!prls!mips!hansen
From: hansen@mips.UUCP
Newsgroups: comp.arch
Subject: Re: Life with TLB and no PT
Message-ID: <338@dumbo.UUCP>
Date: Thu, 23-Apr-87 15:32:18 EST
Article-I.D.: dumbo.338
Posted: Thu Apr 23 15:32:18 1987
Date-Received: Sat, 25-Apr-87 08:04:21 EST
References: <3027@sdcsvax.UCSD.EDU>
Lines: 32
Summary: MIPS R2000 already does it

In article <3027@sdcsvax.UCSD.EDU>, stuart@CS.ROCHESTER.EDU (Stuart Friedberg) writes:
> Prodded by something Avie Tevanian of the MACH research group said,
> I have been considering life with a translation lookaside buffer (TLB)
> but without hardware page tables (PT).  This message is intended to
> spark some discussion of a) what such a system would be like, and
> b) how existing architectures and operating systems can be instrumented
> to get some empirical data to guide TLB design and sizing.  Since it
> involves tradeoffs between hardware and software, I cross-posted to
> comp.os.research and comp.arch.

The MIPS R2000 processor already does it, and with a 4k page size, a
64-entry, fully-associative TLB, and 15-19 cycles to refill the TLB in
software from a simple page table, large benchmarks typically spend about 1%
of their execution time in the software TLB refill handler. There are 6-bit
process identifiers associated with each entry, so that the TLB doesn't need
to be flushed on context switches, and the permanently memory-resident
portion of the kernel doesn't use the TLB at all, which reduces the overall
size requirement of the TLB by a large margin.

An important benefit of the software TLB handler is that it is easily
changable. We use two different handlers for the two different UNIX ports we
have running on the machine (BSD 4.3 and V.3), because there are two
different page table formats in use.  We've been able to easily add code to
count TLB misses to verify our simulation data under real system conditions.
We have also used it to code around hardware problems in one revision of our
processor chip.

-- 
Craig Hansen
Manager, Architecture Development
MIPS Computer Systems, Inc.
...decwrl!mips!hansen