Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!mit-eddie!uw-beaver!tera.com!bob
From: bob@tera.com (Bob Alverson)
Newsgroups: comp.arch
Subject: Re: Paging page tables
Message-ID: <1990Jun29.154940.22762@tera.com>
Date: 29 Jun 90 15:49:40 GMT
References: <3300142@m.cs.uiuc.edu>
Sender: news@tera.com
Reply-To: bob@colossus.tera.com (Bob Alverson)
Organization: Tera Computer Company
Lines: 25

In article <3300142@m.cs.uiuc.edu> march@m.cs.uiuc.edu 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 main justification I see for paging page tables is to keep their
overhead a function of physical memory size, not virtual memory size.
Consider a UNIX process with heap at low addresses going up and stack
at high addresses going down.  Without a paged page table, all the
space in between must have page table entries sitting in physical memory.
That doesn't seem like a smart way to use memory.  To keep things sane,
you probably want to lock in the page containing the page table entries
for virtual address space containing the page table.  With a 4Mb addr
space and 512b pages, you need 8k entries taking (say) 32kb.  You need 64 page
table entries to cover the page table (sounds recursive), which fits
in one page.

Bob