Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!gatech!amdcad!tim
From: tim@amdcad.AMD.COM (Tim Olson)
Newsgroups: comp.arch
Subject: Re: AM29000 memory management (was flame)
Message-ID: <16331@amdcad.AMD.COM>
Date: Thu, 23-Apr-87 10:48:03 EST
Article-I.D.: amdcad.16331
Posted: Thu Apr 23 10:48:03 1987
Date-Received: Sat, 25-Apr-87 09:44:30 EST
References: <67@bernina.UUCP> <27207@rochester.ARPA>
Organization: Advanced Micro Devices, Inc., Sunnyvale, Ca.
Lines: 60
Summary: The right place is in external hardware...

In article <27207@rochester.ARPA>, stuart@rochester.ARPA (Stuart Friedberg) writes:
> In article <67@bernina.UUCP>, tve@ethz.UUCP (Th. von Eicken) writes:
> > When reading the data sheet I noticed that the TLB entries
> > don not have any "page used" flag nor any "page modified"
> > flag. Does that mean that the AM29000 memory managenent is even
> > more crippled than on a VAX (which doesn't have a "page used" flag???
> 
> A translation lookaside buffer (TLB) is not the same as page tables (PT).
> The TLB serves as a cache of recently used address translations, while
> the PT serves as the source of translation information.  Reference
> (page used) and dirty (page modified) flags belong in the PT.
> 
> Stu Friedberg  {seismo, allegra}!rochester!stuart  stuart@cs.rochester.edu

Actually, the referenced and changed bits are for use by the page replacement
algorithm, and are associated with physical addresses.  The PTs, on the other
hand, are (usually) searched using virtual addresses.  Unless you use an
inverted page table (IPT) structure, the R & C bits should be placed in a
separate structure which can be "searched" with physical addresses.

The "best" place for the referenced and changed bits, however, are in an 
external memory array, which "watches" the bus and automatically updates the
R & C bits.  This array can also be read from or written to via I/O space
to read or clear the bits.

Benefits:

	1) Speed -- R & C bits do not need to explicitly be written to memory,
	   nor do they need to be periodically cleared from the TLB.

	2) single copy -- R & C bits exist in only one place and are always
	   up-to-date.  If they were to exist in the TLB, they would have to
	   be "flushed" from the TLB into the correct memory locations every
	   time the page replacement algorithm runs.  This would *really* be
	   a headache for multiprocessor systems which use shared memory.
	   Works with I/O, too.

	3) Fairly inexepensive & easy solution (heck, even the IBM RT-PC does
	   it this way!)

If you *really* want to keep the R & C bits in a software structure in main
memory, it can be done using the standard tricks.  EXERCISE FOR READER:

given a tlb entry which holds the following information:

	VTAG	-- virtual address for this translation
	  UR	-- page has user read permission
	  UW	-- page has user write permission
	  UE	-- page has user execute permission
	 RPN	-- real (physical) page number
	 PGM	-- two user-programmable bits (which also appear on the pins)
	   F	-- a user-programmable bit (doesn't appear on the pins)

devise a method to collect page reference and change statistics.


	-- Tim Olson
	Advanced Micro Devices
	Processor Strategic Development
	(tim@amdcad.AMD.COM)