Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!know!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!uflorida!mephisto!bbn.com!lkaplan
From: lkaplan@bbn.com (Larry Kaplan)
Newsgroups: comp.arch
Subject: Re: Paging page tables
Message-ID: <58001@bbn.BBN.COM>
Date: 5 Jul 90 21:04:01 GMT
References: <3300142@m.cs.uiuc.edu> <9758@pt.cs.cmu.edu> <PCG.90Jun30230310@odin.cs.aber.ac.uk>
Sender: news@bbn.com
Reply-To: lkaplan@BBN.COM (Larry Kaplan)
Organization: Bolt Beranek and Newman Inc., Cambridge MA
Lines: 53

In article <PCG.90Jun30230310@odin.cs.aber.ac.uk> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes:
>In article <9758@pt.cs.cmu.edu> lindsay@MATHOM.GANDALF.CS.CMU.EDU
>>(Donald Lindsay) writes:
>>	[ ... on paging page tables ... ]
>>   The OS designer balances memory demands and  swap speed against swap
>>   frequency.  Note that a 16 byte table entry per 512 byte page is
>>   only a 3% overhead. Most designs run leaner.

I believe the 88k is about 4 bytes per 4k page.

>Actually this 3% overhead can be mostly obviated, as the need of paging
>page tables. The clear win is to have reverse page map tables for the
>paging itself, whose size is only proportional to the size of real
>memory, and segment map tables for the description of valid stretches
>of address space. In this way you have the best of all worlds, because
>you can have a very large address space with only locally dense data
>space mappings, and a very low overhead.

This reverse scheme fails to save you much on machines with large physical
memories which are becomming more and more common.  We build UNIX machines
that regularly have 1 or more gigabytes of real physical memory.
Allocating segment tables on demand is certainly helpful, though.

>I am quite sure that Don Lindsay could expound on the advantages of
>this approach from direct observation, as the Mach portable virtual
>memory code uses exactly this approach (well, the MACH people actually
>bitch about the reverse map MMU in the IBM RISCs, because they abuse
>copy-on-write, and reverse map makes it difficult, but this is just
>because they use the wrong virtual memory model, i.e. copy-on-write).

Wrong virtual model?  This sounds like a religious comment.  My understanding
is that UNIX has wanted to have true copy-on-write semantics for a while but
just never got around to it.  Witness the vfork() hack in BSD which was
suppose to disappear when "proper sharing semantics" were implemented.
The system we build has MACH ancestry (though a totally rewritten VM system)
and therefore allowed us to make vfork() the same as fork().

As far as paging the page tables, our page fault handler is always prepared 
to allocate page table space.  The only problem would be to clean the system's
TLBs since we put page tables into the kernel's virtual address space.

In our multiprocessor systems, my feeling is that it is a win to be able to 
page your page tables to prevent some process from consumming lots of local
page table memory in order to reference alot of system wide memory.  Other
small local processes (or even user allocations from the same process) would 
then get very starved for memory on the local node.

#include <std_disclaimer>
_______________________________________________________________________________
				 ____ \ / ____
Laurence S. Kaplan		|    \ 0 /    |		BBN Advanced Computers
lkaplan@bbn.com			 \____|||____/		10 Fawcett St.
(617) 873-2431			  /__/ | \__\		Cambridge, MA  02238