Path: utzoo!attcan!uunet!tut.cis.ohio-state.edu!pt.cs.cmu.edu!spice.cs.cmu.edu!af
From: af@spice.cs.cmu.edu (Alessandro Forin)
Newsgroups: comp.os.mach
Subject: Re: External Pager Questions
Message-ID: <8483@pt.cs.cmu.edu>
Date: 19 Mar 90 15:33:21 GMT
References: <821@sirius.ucs.adelaide.edu.au>
Organization: Carnegie-Mellon University, CS/RI
Lines: 91

In article <821@sirius.ucs.adelaide.edu.au>, francis@sirius.ucs.adelaide.edu.au (Francis Vaughan) writes:
> 
> A few people have recently requested info,or better, examples of external
> pagers. I would second that request.

The Mach Netmemoryserver is included in the 2.5 tape, and it is a 
good, working example of an external memory manager providing 
coherent distributed shared memory objects to its clients.

> Is there any inherent reason why it cannot be a thread within the same 
> task as the client for the externally paged memory object? 

None.  I have used this myself in toy programs and works fine.
Only caveat: while debugging the program I got stung by inadvertedly
looking at that memory while, of course, the program was blocked.  Ouch!

> The memory_object_lock_request call allows one to lock a section of a
> memory object.

Weeelll, lock is used here not in the classical mutual exclusion
sense, but rather in the lock-against-read/write access sense.

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

The manual says "This must be page aligned", meaning the kernel will
get upset otherwise and give you a bad reply.

> 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? 

Vm_protect applies to an _individual_ task's view (mapping)
of the memory object and has nothing to do with the memory manager
locking policy.  In other words, the vm_protect protection is checked first
on a fault and only if this is ok does the kernel request the page (if 
missing from its cache).

> Is memory_object_lock_request (when used to protect memory) just shorthand 
> for vm_protect applied to all client tasks?

No, there is no trace whatsoever in Mach of VM management for groups of tasks.
And for very good reasons: just think at the embarassement you'll have 
defining a precise semantics in the distributed case.  [Atomicity ? Arumph..]
The external memory management interface is, in a sense, just how memory looks
"from the other side of the world" :-)).  

> 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? 

No, it will get an exception message.  External memory managers only 
understand KERNELS and their caches, they have no idea that tasks even exist.
[This is indeed the most common misunderstanding I have observed
 while explaining this subject to people.]

> (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.)

No problem at all: set the EXCEPTION_PORT of the specific task you want to
control to some port of yours and be prepared to handle all exception
messages for all threads in that task.  You will indeed be able to
excercise the kind of control you envision by proper use of vm_protect.
Note that the exception message will tell you exactly the address the thread 
faulted on, a much finer grain information.

> 
> I need to catch accesses to pages of memory to build a coherent distributed
> persistent data space. ....

Once again, I would advise to look carefully in the Netmemoryserver,
which should provide you with most of the functionality you
need.  Adding persistency will not be difficult, I think.
A good description of the server is in the CMU techrep CMU-CS-88-165,
reading it will certainly help you clarify your ideas and your design.

> PS. A while ago I posted some questions about the use of the inode pager
> and its relative merits. To date I have not seen a word in reply. Surely
> someone has got something to say, I'll repost the questions if anyone
> wants.

That's an internal component of the 2.5 kernels which noone (hopefully)
ever indicated as examplar use of the _external_ memory management interface.
As a matter of fact, Richard Draves recently rewrote it from scratch
to turn it into a multi-threaded server [this might not be in the 2.5
tape, I think it was about version X115].
For Mach3.0 we have completely different and crazy plans ;-)

sandro-