Path: utzoo!attcan!uunet!cs.utexas.edu!usc!apple!sun-barr!newstop!sun!amdahl!littauer
From: littauer@uts.amdahl.com (Tom Littauer)
Newsgroups: comp.arch
Subject: Re: Paging page tables
Summary: A couple of examples
Message-ID: <0dwQ02Vzb4UI01@amdahl.uts.amdahl.com>
Date: 29 Jun 90 15:01:18 GMT
References: <3300142@m.cs.uiuc.edu> <1990Jun28.182303.8352@zoo.toronto.edu>
Reply-To: littauer@amdahl.uts.amdahl.com (Tom Littauer)
Organization: Amdahl Corporation, Sunnyvale CA
Lines: 28

In article <1990Jun28.182303.8352@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes:
>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...
>
>Unfortunately, it makes a great deal of sense, because the PTEs for a
>very large process can chew up a lot of memory all by themselves.  All
>it means is that you need a smaller set of PTEs to describe where the
>main PTEs are, layering one address-translation mechanism on top of
>another.  This is done pretty routinely.

Correct. A couple of examples where this is desirable and efficient:

Large but sparse arrays. The programmer needn't worry about special hacks,
but can get on with solving the original problem.

Extremely large arrays combined with programs with good locality of reference.

-- 
UUCP:  littauer@amdahl.amdahl.com
  or:  {sun,decwrl,hplabs,pyramid,ames,uunet}!amdahl!littauer
DDD:   (408) 737-5056
USPS:  Amdahl Corp.  M/S 278,  1250 E. Arques Av,  Sunnyvale, CA 94086

I'll tell you when I'm giving you the party line. The rest of the time
it's my very own ravings (accept no substitutes).