Article View: comp.arch
Article #13503Re: AM29000 memory management (was flame)
From: John Mashey
Date: Sat, 25 Apr 1987 04:46
Date: Sat, 25 Apr 1987 04:46
37 lines
2728 bytes
2728 bytes
In article <121@motsj1.UUCP> rich@motsj1.UUCP (Rich Goss) writes:
...discussions of TLBs that don't have hardware-set modify and access
bits...
>
>The used and modified flags should be stored along with the page
>address in the TLB. Otherwise, the MMU will always have to check
>the page table descriptor in main memory to see if these two
>flags have been updated on every access to the page being
>referenced......
>I do not know how the 29000 MMU operates but the scenario I have
>described is used in many demand paged MMU schemes including the
>Motorola 68851 PMMU.
1) It is true that many do work this way. That is NOT a reason to
claim that they "should" work this way, and have trouble working without.
2) I guarantee you that you don't
need to have hardware-set modify and reference bits in the TLB.
Machines work perfectly well without them. The one I'm writing this on
works without them, and its performance is fine, and both System V and
4.3BSD ports came up quickly on it.
3) With some operating systems, the LAST thing in the world that
the OS wants is for the hardware to set modify bits anywhere without
trapping to the OS. For example, System V does copy-on-write handling,
and it ends up making pages look read-only that are really writable,
so it can trap writes, copy the page, and then give it a modifiable
page. I.e., it has to fake out the hardware to get done what it wants.
4) All the statistics say that "change writable, but clean page to
dirty page" is an infrequent event, that happens on the order of
page-in rates, not on the order of memory access rates. Hence it is
quite reasonable to do it in software.
5) Others have already talked on the rationale for doing TLBs this way.
See also "Operating System Support on a RISC", IEEE COMPCON,
SanFrancisco, March 1986, 138-143: we talked about this a year ago.
--
-john mashey DISCLAIMER: <generic disclaimer, I speak for me only, etc>
UUCP: {decvax,ucbvax,ihnp4}!decwrl!mips!mash, DDD: 408-720-1700, x253
USPS: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086
Technical Details
Message-ID:
<342@winchester.UUCP>Path:
arc1-ca.pugleaf.net!utzoo!mnetor!seismo!gatech!hubcap!ncrcae!ncr-sd!bigbang!pyramid!prls!mips!mashReferences:
<67@bernina.UUCP> <27207@rochester.ARPA> <121@motsj1.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!mnetor!seismo!gatech!hubcap!ncrcae!ncr-sd!bigbang!pyramid!prls!mips!mash From: mash@mips.UUCP (John Mashey) Newsgroups: comp.arch Subject: Re: AM29000 memory management (was flame) Message-ID: <342@winchester.UUCP> Date: Sat, 25-Apr-87 00:46:32 EDT Article-I.D.: winchest.342 Posted: Sat Apr 25 00:46:32 1987 Date-Received: Sun, 26-Apr-87 20:07:01 EDT References: <67@bernina.UUCP> <27207@rochester.ARPA> <121@motsj1.UUCP> Reply-To: mash@winchester.UUCP (John Mashey) Distribution: world Organization: MIPS Computer Systems, Sunnyvale, CA Lines: 37