Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!gatech!hubcap!ncrcae!ncr-sd!hp-sdd!ucsdhub!sdcsvax!darrell From: avie@wb1.cs.cmu.edu (Avadis Tevanian) Newsgroups: comp.os.research Subject: Re: Life with TLB and no PT Message-ID: <3128@sdcsvax.UCSD.EDU> Date: Sat, 9-May-87 01:09:56 EDT Article-I.D.: sdcsvax.3128 Posted: Sat May 9 01:09:56 1987 Date-Received: Sun, 10-May-87 06:06:10 EDT Sender: darrell@sdcsvax.UCSD.EDU Organization: Carnegie-Mellon University, CS/RI Lines: 54 Approved: mod-os@sdcsvax.uucp In article <3106@sdcsvax.UCSD.EDU> lamaster@pioneer.arpa (Hugh LaMaster) writes: >In article <3100@sdcsvax.UCSD.EDU> I write: > >> >>Now, back to the main point... since Mach treats an MMU as a TLB it becomes >>possible to start doing interesting things. For example, I just wrote a >>program that sparsely used 256 megabytes of VM and ran it on my MicroVAX >>which has only 6 megabytes of physical memory. [Try *that* on Unix]. The >>reason this is no problem is that since the VAX page tables are just a cache >>of virtual to physical mappings ... the module that manages the VAX page >>tables simply throws away mappings at will. In fact, the way we have >>implemented it is to allocate a fixed pool of "page table memory" which is > >I don't follow this part. Are you saying that pages within a segment can be >mapped sparsely? Doesn't 4.x BSD allow this? I confess my ignorance here, >but MANY virtual memory operating systems allow this... > I don't think I completely understand this question. 4.x BSD stores important information in VAX page table entries. For example, a page that was to be zero filled when touched would be indicated by a pte with such an indication. What this means is that if I wanted to allocate 256 meg of VM, a stock BSD system would grab 2 meg of page tables and place the zero fill indication in each of the 1/2 million ptes. [ Actually, it wouldn't have even got this far unless there was 256 meg of swap space available somewhere.] In Mach, if I allocate 256 meg of VM, the kernel makes a simple notation of this - no page tables are created/destroyed/modified. When I actually start touching memory, the machine independent part of the kernel zero fills pages and requests the machine dependent part to validate the appropriate addresses. On the VAX, we dynamically allocate virtual address space out of the kernel's address space for the user page tables. Then we back the user page tables with physical memory out of the page table memory pool. If I start mapping so many pages that the page table memory pool becomes depleted we just removing pages in use in an LRU fashion. Now, consider that on a 6 meg system, if there is no sharing of memory, you can have at most 6 meg of resident memory, hence you need to be able to map 6 meg of memory. On a Vax, each page table byte maps 128 bytes (4 bytes per 512 byte page). So, to map all of memory takes a little less than 1% of physical memory. We use 2% in the page table memory pool to allow for sharing and rarely need to forcibly reclaim that memory. Do you have some specific examples of virtual memory operating systems that do this (especially examples that are not closely tied to a particular MMU)? Note that in my example, I am allocating (virtually) every page in the 256 meg range and can touch any page in that range. I do not depend on segment registers or any other MMU-specific feature to handle the sparseness. More food for thought: the Common Lisp hackers around here like to use the high address bits as tags. Their RT version of Common Lisp (running under Mach) allocates 2.38 GIGABYTES. Runs fine so long as they have enough physical memory for the normal working set (6-10 meg) and enough free disk space to hold the infrequently used (paged out) Lisp things (a few more meg). Avie