Article View: comp.arch
Article #13541Re: AM29000 MMU [really MIPS TLB] [long]
From: ned
Date: Thu, 30 Apr 1987 21:17
Date: Thu, 30 Apr 1987 21:17
54 lines
3052 bytes
3052 bytes
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...
Technical Details
Message-ID:
<95@ksr.UUCP>Path:
arc1-ca.pugleaf.net!utzoo!utgpu!water!watmath!clyde!rutgers!husc6!harvard!ksr!john!nedReferences:
<67@bernina.UUCP> <27207@rochester.ARPA> <121@motsj1.UUCP> <342@winchester.UUCP> <93@ksr.UUCP> <351@winchester.UUCP>Show Full Headers
Complete Article Headers
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: arc1-ca.pugleaf.net!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