Article View: comp.arch
Article #13486Re: AM29000 memory management (was flame)
From: Tim Olson
Date: Thu, 23 Apr 1987 15:48
Date: Thu, 23 Apr 1987 15:48
60 lines
3353 bytes
3353 bytes
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)
Technical Details
Message-ID:
<16331@amdcad.AMD.COM>Path:
arc1-ca.pugleaf.net!utzoo!mnetor!seismo!gatech!amdcad!timReferences:
<67@bernina.UUCP> <27207@rochester.ARPA>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!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...