Path: utzoo!attcan!uunet!tut.cis.ohio-state.edu!quanta.eng.ohio-state.edu!kcgl1.eng.ohio-state.edu!JONESD From: JONESD@kcgl1.eng.ohio-state.edu (David Jones) Newsgroups: comp.arch Subject: Re: Paging page tables Message-ID: <5204@quanta.eng.ohio-state.edu> Date: 28 Jun 90 21:35:45 GMT References: <3300142@m.cs.uiuc.edu> Sender: news@quanta.eng.ohio-state.edu Organization: Ohio State University Lines: 30 In article <3300142@m.cs.uiuc.edu>, march@m.cs.uiuc.edu (Steve March) writes: > While reading Hennessey and Patterson (p. 437), they mention the fact > that page tables entries are often paged themselves (with the operative > word being often). Now to me, paging you're means of address translation > makes no sense. As they continue to point out, the cost of this is > appreciable because one has to swap the PTEs back in and then do the > translation. Given this, just how "often" is this used? I suppose > given a translation-lookaside buffer, the hugh cost of swapping page > table entries back in could be offset by some translations being very > fast (via the TLB). The VAX architecture uses pageable page tables for user code. A TLB, even a small one, does a very effective job of reducing the overhead of paged page tables. I once intentionally wrote a pathological program that thrashed the TLB on a MicroVax and it ran 3 times slower than a non-thrashing version. Note that to thrash the TLB entries for the page table pages, you have to separate your memory references by enough to go to another page in the table (64KB in the case of the VAX). Most normal programs would thrash the program page TLB entries more than an order of magnitude more that the page table page TLB entries, so the cost over that of a non-paged page table is small. David L. Jones | Phone: (614) 292-6929 Ohio State Unviversity | Internet: 1971 Neil Ave. Rm. 406 | jonesd@kcgl1.eng.ohio-state.edu Columbus, OH 43210 | jones-d@eng.ohio-state.edu Disclaimer: A repudiation of a claim.