Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!columbia!rutgers!mit-eddie!genrad!decvax!ucbvax!sdcsvax!darrell From: mash@mips.UUCP (John Mashey) Newsgroups: comp.os.research,mod.os Subject: Re: Life with TLB and no PT Message-ID: <3044@sdcsvax.UCSD.EDU> Date: Sun, 26-Apr-87 15:36:21 EDT Article-I.D.: sdcsvax.3044 Posted: Sun Apr 26 15:36:21 1987 Date-Received: Mon, 27-Apr-87 00:57:25 EDT Sender: darrell@sdcsvax.UCSD.EDU Organization: MIPS Computer Systems, Sunnyvale, CA Lines: 26 Approved: mod-os@sdcsvax.uucp Xref: mnetor comp.os.research:15 mod.os:155 In article <3040@sdcsvax.UCSD.EDU> mcvoy@crys.WISC.EDU (Larry McVoy) writes: >hansen@mips.UUCP (Craig Hansen) writes: >>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 > >Does that mean you wrap process id's around at 64? If not, how do you know >if you have a hit or not? The 6-bit identifiers are treated as a resource onto which 16-bit real PIDs are mapped dynamically, there being no longer-term association. When you run out, you flush the whole TLB, then give each process a new PID as you dispatch it. In the worst case, where you had >64 processes being round-robbined thru the complete cycle, the overhead for this costs 1 microsecond / context switch [on a 5Mips machine]. Real systems don't work this way, since you often have much more back-and-forth switching. If you understand the amount of work that UNIX does on a context switch, this is completely in the noise. Note that 68K designs that use SRAM MMUs usually have the same sort of algorithm, except they must load up the SRAMs, and there are usually less than 64 contexts [such as 8 on Sun3s], i.e. not a problem. -- -john mashey DISCLAIMER: UUCP: {decvax,ucbvax,ihnp4}!decwrl!mips!mash, DDD: 408-720-1700, x253 USPS: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086