Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!swrinde!emory!hubcap!ncrcae!ncr-sd!iss-rb!ivory!martins
From: martins@ivory.SanDiego.NCR.COM (Martin Sandman)
Newsgroups: comp.arch
Subject: Re: Paging page tables
Message-ID: <620@iss-rb.SanDiego.NCR.COM>
Date: 29 Jun 90 16:40:44 GMT
References: <3300142@m.cs.uiuc.edu> <1990Jun28.182303.8352@zoo.toronto.edu>
Sender: news@iss-rb.SanDiego.NCR.COM
Reply-To: martins@ivory.SanDiego.NCR.COM (Martin Sandman)
Organization: NCR Corporation, Rancho Bernardo
Lines: 27

>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 described in H&P I don't understand how this could work either.
However, I am familar with a combination segment/page scheme where it works
very well.  The eight high order bits of the address select one of 256
page tables.  Each page table can have up to 128 entries.  The segment table
entry specifies the number of valid entries in each page table and whether
the page table is in memory or not.  If the page table in not in real memory,
a special fault is taken when the segment table entry is referenced.  (A
segment table _is_ nailed to real memory.)  When this special segment table
fault occurs the paging supervisor builds a page table "on the fly" in real
memory and restarts the instruction.  This time it results in an "ordinary"
page fault because the page table is in memory but the page itself is not.
This technique clearly saves lots of real memory that could be potentially
lost to seldom used page tables.  On the other hand, it _seems_ to require
an additional memory access to resolve a virtual to real translation.  It does
but not very often.  99+% of all v-to-r happens in the translation lookaside
buffer so the two-stage memory access does not really happen offen.

Since the page tables are built on the fly, really just allocated, they don't
have to be swapped in.
     ______________________________________________________________________
     = UUCP:   sdcsvax!ncr-sd!fiddler!martins      Martin D. Sandman      =
     = NCR:    Martin.Sandman@SanDiego.NCR.COM     NCR Corporation        =
     = Phone:  (619) 485-3554                      16550 West Bernardo Dr.=