Xref: utzoo comp.arch:7465 comp.unix.questions:10505
Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ames!lll-lcc!unisoft!mtxinu!taniwha!paul
From: paul@taniwha.UUCP (Paul Campbell)
Newsgroups: comp.arch,comp.unix.questions
Subject: Re: 88K table walk
Message-ID: <229@taniwha.UUCP>
Date: 5 Dec 88 05:45:01 GMT
References: <415@ncr-sd.SanDiego.NCR.COM> <1583@nud.UUCP>
Reply-To: paul@taniwha.UUCP (Paul Campbell)
Organization: Taniwha Systems Design, Oakland
Lines: 30

In article <1583@nud.UUCP> tom@nud.UUCP (Tom Armistead) writes:
>In article <415@ncr-sd.SanDiego.NCR.COM> jml@ivory.SanDiego.NCR.COM (Michael Lodman) writes:
>>According to Motorola, the 88200 CMMU does not cache the page and
>>segment descriptors it fetches during a table walk. This would seem
>
>    Wrong! The 88200 does cache page descriptors.  Up to 56 page descriptors
>(each descriptor maps 4K of virtual space) can be cached in each CMMU.  The

I think what he is really asking is 'does the 88200 cache the segment table
entries used to read page table entries with?'. 

I've often thought about whether this is worth while or not, it probably is for
'medium' to 'large' size programs ('small' ones only need a few entries and fit
in the TLB cache, 'large' to 'huge' ones may thrash). I think that simulation
is probably the only way to find out and of course your mileage may vary for
different architectures and different job mixes.

Of course systems that do software TLB misses like the 29K and the MIPS chips
take advantage of any data cache the system has since they treat both segment
table entry accesses and page table entry accesses like any other access. (This
helps you particularly for VERY large programs that are thrashing in the TLB
cache because the data cache speeds up TLB refills)

	Paul

-- 
Paul Campbell			..!{unisoft|mtxinu}!taniwha!paul (415)420-8179
Taniwha Systems Design, Oakland CA

 	"Read my lips .... no GNU taxes"