Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!samsung!munnari.oz.au!sirius.ucs.adelaide.edu.au!chook.ua.oz!francis
From: francis@chook.ua.oz (Francis Vaughan)
Newsgroups: comp.os.mach
Subject: Re: External Pager Questions
Message-ID: <823@sirius.ucs.adelaide.edu.au>
Date: 20 Mar 90 04:25:16 GMT
Sender: news@ucs.adelaide.edu.au
Reply-To: francis@chook.ua.oz (Francis Vaughan)
Organization: Comp Sci, Uni of Adelaide, Australia
Lines: 120


Michael Young replyed to my origonal posting by email and requested that I
post his reply to comp.os.mach (as he has no posting access). Here it is.

-----------------------------

> A few people have recently requested info,or better, examples of external
> pagers. I would second that request. I didn't see any replys on the net,
> but if there has been some email conversations on the subject I would be
> most grateful if I could get a summary.

I know of two memory managers for which you can get sources:

	Mach NetMemoryServer.  Implements coherent network shared memory.
	       Distributed as part of the Mach release.

	Camelot DiskManager.  Implements recoverable virtual memory.
	       Distributed as part of the Camelot release.  Camelot
	       is a distributed transaction management facility that
	       was developed at CMU.  It makes heavy use of Mach features.

Work at CMU on out-of-kernel operating system (e.g., Unix) environments
makes significant use of the external memory management interface.  I don't
know whether those sources are being distributed yet.

> The Kernel Interface Manual refers to the external pager as a task. Is
> there any inherent reason why it cannot be a thread within the same task as
> the client for the externally paged memory object? (Sure, one would need to
> be careful not to touch the memory object from within the pager to avoid a
> potential infinite recursion.)

There is no restriction on the structure of a user-level memory manager
("external pager"), the entity that implements a memory object.  It will
normally be a separate task, but it might be a thread within the same
task, or it might be several tasks that work together.  The task to
which the documents refer is probably just the one that holds receive rights
to the memory object port.

> The manual says that the kernel will not page align the offset parameter.
> Can this really be true? (or rather, make sense)

Yes, it's both true and sensible.  For example, a file server (a memory
manager whose memory objects represent the contents of a file) might
permit its clients to map portions of a file at unusual offsets.  The
implementation of the Unix "execve" call in the Mach 2.5 system makes
use of this feature -- the text from an "a.out" file (at a Berkeley VM
page offset, meaning 1K, into the file) gets mapped to a page boundary
on the Vax architecture (and perhaps others).

A memory manager that provides one of its memory objects to clients on
more than one node already has to cope with multiple pages sizes.
For example, a NetMemoryServer running on host A with page size 4K
might provide service for a mapping on host B with page size 1K.
Requests for pages coming from host B might fall on any 1K boundary,
which may not be a page boundary on host A.  Hosts A and B may even
be of the same architecture.  In the limit (pagesize(host B) => 1),
this means that it's reasonable for a memory manager to accept *any* offset.

> A memory_object_lock is applied to the cached memory (ie the physical
> memory) and the memory is locked for access from all clients. How does this
> relate to the use of vm_protect? Can I lock access to a section of an
> externally paged memory object with vm_protect from a particular set of
> tasks whilst leaving it at a different level of protection from others? Is
> memory_object_lock_request (when used to protect memory) just shorthand for
> vm_protect applied to all client tasks?

The vm_protect value applies to a virtual address, the memory object
lock applies to physical address, and their result is *combined*.
They are separate mechanisms -- the memory object lock is not a shorthand
for calling vm_protect.  You may use vm_protect as you suggest to
get differential access, but the memory object lock will not help you.

> If I use vm_protect to deny access to part of a memory object from a
> particular task, when that task touched the protected area will a
> memory_object_data_unlock call be made on the external pager? (I can see
> that this could be a problem at present as there is no parameter that
> conveys the identity of the faulting task to the external pager.)

The memory object lock value applies to all tasks, including the task
that receives messages from the memory object port (which as described
above, may not be the task eventually responsible for satisfying the
request).

The memory manager can change the memory by cleaning it.  If your server
doesn't change the values regularly, this may be practical.

> there may be more than one thread running in the faulting task. So far the
> external pager interface seems to just, but not quite have enough
> functionality.

The external memory management interface was intended to provide fast
access to the main memory cache.  Identifying clients in the calls
is impractical.  Providing differential access could be added to the
interface by using additional "related" memory objects.

The interface intentionally avoids mentioning particular clients in the
memory object initialization and request calls.  Having to make a
separate call for each client would be wasteful in the normal case
where fully shared access to the cache is intended.  Identifying the
client would require some naming trickery.  The task/thread port
connotes full rights to abuse that entity.  If that port were used
to identify clients to a memory manager, a client would have to
*completely* trust *every* memory manager with which it does business.

Several people have suggested providing memory objects that are
restricted forms of another memory object.  For example, a file server
may want to provide full access to a memory object (file) to some
clients, but read-only access to others.  Creating a
second memory object that is declared to contain the same data as
the original, but for which all mappings are restricted, would suffice.
In your example, a related memory object for which you could change
the restriction at any time (e.g., change it from full access to
read-only, and then back again) would seem to suffice also.
This would provide 3 orthogonal protection mechanisms (vm_protect,
per-page memory object lock, object-wide memory object lock).
I MUST MAKE IT CLEAR THAT THIS FEATURE IS FICTIONAL -- it is not
provided by Mach 2.5, and probably won't be in Mach 3.0.  At one
point, I strongly opposed such a feature, but I now admit that it
may fulfill a real need.  It would be worth thinking through, but
I'm no longer in a position to do it.