VMM

[Neal H. Walfield]

> I don't know what the plans are, nor what Neal did this summer
> in Karlsruhe. Since I also started work on porting UVM to L4
> environment, it would be nice to exchange some ideas...

I also took a look at UVM along with some other VMM implementations.
Most, however, seem inappropriate for a multiserver as they all make
assumptions about the centralized nature of the resources.  As the VMM
is one of the most critical pieces of a system--it is everywhere--we
need to take a careful look and determine the exact set of
requirements that we require.

My proposal is to design the VMM in the same way we have designed the
other components of the Hurd, that is, in a distributed fashion.  I
have come up with a model where there is a central physical memory
server and swap server (however, they can be stacked: it is only a
question of a server providing an appropriate interface).  All
processes compete for the memory on the system and enter in to
different types of contracts with the physical memory server.  They
can then use the memory anyway they like but when the contract runs
our, they must return the memory if asked.  If a server ignores these
request, the memory server can revoke all of its mappings and
effectively kill the client.

As tasks must manage their own memory, they must make page eviction
decisions, etc.  But this is generally a good thing: we would prefer
that the client make the decisions as it knows the most about its
memory usage patterns and what it will and will not be using in the
near term.  It may even be able to decide to just drop temporary
scratch buffers.  This type of decision would be using a monolithic
system.  Instead, the monolithic VMM would be forced to swap the data
to disk.  The same holds true at allocation time: the task knows what
the memory will be used for, as such, it can ask for certain page
sizes or not worry about zero filling memory.  The end result is a lot
less guessing and better utilization of memory.  Well, at least in
theory.

Another mitigating factor in the design is avoiding having servers
provide resources to clients.  That is, servers provide services and
nothing more; clients should provide any required resources.  In the
case of a reading from a file, for instance, this would entail
providing memory to the server which could fill it with appropriate
data.  Memory "containers" allow memory to be passed around logically
and also permits memory to be locked by untrusted servers without the
client losing control over it.  Other mechanisms allow the tasks to
make logical copies of memory.  This would be useful in the case of a
file system's page cache.

I did a small presentation at LSM this past July, you can find the
slides on line at[1] to get a more concrete idea of what I am
thinking.  Feel free to ask exact questions.


[1] 
http://web.walfield.org/papers/gnu-virtual-memory-management-system-lsm-2002-07-14/html/