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"