Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!husc6!harvard!ksr!john!ned
From: ned@john.UUCP
Newsgroups: comp.arch
Subject: Re: AM29000 MMU [really MIPS TLB] [long]
Message-ID: <95@ksr.UUCP>
Date: Thu, 30-Apr-87 17:17:50 EDT
Article-I.D.: ksr.95
Posted: Thu Apr 30 17:17:50 1987
Date-Received: Sat, 2-May-87 00:46:23 EDT
References: <67@bernina.UUCP> <27207@rochester.ARPA> <121@motsj1.UUCP> <342@winchester.UUCP> <93@ksr.UUCP> <351@winchester.UUCP>
Sender: nobody@ksr.UUCP
Reply-To: ned@ksr.UUCP (Kittlitz)
Distribution: world
Organization: Kendall Square Research, Cambridge MA
Lines: 54

I found the Compcon article. I don't understand how EntryHi (the VPN
part of the TLB entry) gets set, based on guess-translation of the
opcodes in your sample.  I get an implication that k0/k1 are somehow
not in the general register set, but I didn't see that in the article
(or do you just not preserve two registers?)

I don't know Unix, so whether or not the reclaim list is a standard
thing, I don't know exactly how it is used. I am familiar with several
systems using "clock" algorithms, which operate as:
   - is PTE used off? This page hasn't been used for a while.
     - is modified on? time to purify the page
     - else modified is off, this page can be re-used
   - else PTE used is on, turn it off.
Each manipulation which turns off a bit in the PTE has to ensure that
it is off in all TLBs.

In article <351@winchester.UUCP> mash@winchester.UUCP (John Mashey) writes:
>Multi-processors: here's what I can say:
>	2) It is possible for TLBs and main PTEs to get out of synch.
>	If you go thru all of the transitions, it turns out that
>	the out-of-synch cases are either:
>		a) Innocent, such as another CPU marks a page Dirty,
>		and I still have a non-writable TLB entry. [so what:
>		I'll take an extra trap if I reference the page before
>		I've had to reload that TLB entry anyway].
>		OR
>		b) Potentially dangerous, but really rare, and the transition
>		is trappable.  For example, the page daemon running on
>		another CPU invalidates a PTE that I still have a TLB entry of.
>		This is tricky, and longer than I'm willing to describe here,
>		but one observes that in most cases, such pages are going onto
>		the reclaim list, and there's plenty of time to catch up with
>		them and fix them, AS LONG AS YOU TRAP MODIFIES.


Re b),I don't know how you can trap modifies if write-enable is on in
some TLB.

To avoid instantaneous clearing of TLBS, it seems to me that you need
a reference count associated with each PTE (number of TLBs that have
this cached).  The TLB replacement algorithm would manipulate the
counts of the victim and new entry. I expect there is some other
method involving periodic scanning of a list of changed PTEs, followed
by updating your TLB.





-----
disclaimer: generic disclaimer *

* - have you seen advertisements with '*'s, and no footnote?
It's the same with this disclaimer...