🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.arch
Article #13503

Re: AM29000 memory management (was flame)

#13503
From: John Mashey
Date: Sat, 25 Apr 1987 04:46
37 lines
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!mash
References: <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