Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!sdd.hp.com!hplabs!hpcc05!hpcc01!culberts
From: culberts@hpcc01.HP.COM (Bruce Culbertson)
Newsgroups: comp.os.minix
Subject: Re: Virtual memory Minix
Message-ID: <1530001@hpcc01.HP.COM>
Date: 8 Nov 90 23:08:07 GMT
References: <1990Nov6.071459@ecn.purdue.edu>
Organization: HP Corp Computing & Services
Lines: 49

> I have been thinking of a way to implement a paging Minix system that
> would not alter much in the MM process...
>
> Why not just implement a large virtual memory space for Minix and handle
> paging at very low level, in the kernel tasks for example.

My Minix port to the National 32000 implements some aspects of VM and
does it in approximately the manner you have described.  I posted a
fairly detailed description of the port when I finished it in June 1989.

The system task in my Minix port provides memory management services to
MM.  MM can request that a memory space be created, freed or enlarged
(for the break system call).  MM does not need to know how the system
task implements these services.  For example, the system task could use
the allocation algorithm which is currently used in standard Minix.
However, I chose to use the 32000's paging MMU to assemble user memory
spaces from noncontiguous pages of physical memory.

Code and data/bss are loaded at the low end of the user's virtual
address space and the stack is placed at the top.  Break calls and page
faults due to stack growth cause pages to be added to user spaces.  User
spaces can grow until physical memory is exhausted.  Chmem is not used.

MM can also request the system task to fork a process.  I have
implemented copy-on-write forking.  This creates the illusion that a
memory space has been copied when, in fact, only a new page table is
created.  Forked processes share pages until a process tries to write a
shared page.  At that time, a page fault causes the shared page to be
duplicated, providing the writer with a private copy.

Because of copy-on-write forking, it is possible for the sum of the
virtual spaces on my computer to exceed the size of physical memory.
However, pages are never swapped to a disk.  Paging to disk would be a
very nice addition to my Minix port.

A very desirable virtual memory feature is the ability to "fault in" a
process from its a.out file.  This allows a process to start running as
soon as its first text page is loaded.  This is somewhat difficult to
implement efficiently in Minix because the fault handler, which should
be low level and fast, needs to know the organization of the file
system.  My solution to this problem, which I have not implemented, is
to have FS, as part of its exec call, assemble an array of disk block
numbers for the a.out file blocks.  Creating this array would be
considerably faster than actually loading the blocks.  Once the array
was passed to the system task, the a.out file could be faulted in
without consulting FS.

Bruce Culbertson
culberts@hplabs.hp.com