Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site amdahl.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!oliveb!3comvax!bnrmtv!amdahl!mat
From: mat@amdahl.UUCP (Mike Taylor)
Newsgroups: net.arch
Subject: Re: TLB design, nostalgia, & the PDP-8
Message-ID: <2230@amdahl.UUCP>
Date: Thu, 14-Nov-85 11:56:21 EST
Article-I.D.: amdahl.2230
Posted: Thu Nov 14 11:56:21 1985
Date-Received: Sat, 16-Nov-85 08:30:51 EST
References: <965@mcnc.mcnc.UUCP> <830@x.UUCP> <222@mips.UUCP> <223@redwood.UUCP>
Distribution: net
Organization: Amdahl Corp, Sunnyvale CA
Lines: 24

> Original-Subject: Re: 386 info
> A more important (and practical) reason: you want the TLB to be "listening"
> to memory-bus writes to the page table, so that if a page table line (entry)
> is written and the TLB contains a corresponding line, the TLB line is
> automatically updated (or at LEAST invalidated). This is so that if you
> are using the page table to manipulate data structures (as is often done
> in real-time systems or with various IPC message-passing mechanisms), when
> you diddle with a page-table entry you don't have to flush the entire TLB.
> (Yes, Virginia, a few systems out there have *large* TLBs, which are loaded
> by faulting but flushed by a single hardware command.)

You don't, by any chance, mean System/370 ? and PTLB ? IBM did fix that,
(in the 3033, I think) with the IPTE (Invalidate Page Table Entry)
instruction.  Listening to memory-bus writes doesn't help much in,
for example, a multiprocessor system where each CPU has its own TLB
and non-store-through cache, and the TLBs may contain entries for
address spaces that are not currently being dispatched.  For further
complication, page tables are of variable format (segment/page hierarchy),
in order to keep their size reasonable, and the memory system is
multiported.
-- 
Mike Taylor                        ...!{ihnp4,hplabs,amd,sun}!amdahl!mat

[ This may not reflect my opinion, let alone anyone else's.  ]