Push/Pull

[Jonathan Shapiro]

   ...instead of the pager side saying, "map this page" or "unmap
   this page" and the kernel side saying, "a fault happened here" or "evict
   this page", they should both use a single, symmetrical interface with two
   basic operations: "push" (take THAT!) and "pull" (gimmee gimmee).  Hence I
   call it a push/pull interface; we'll be trying out such an interface in
   the new Mach VM system.

I understand that this is work in progress at Utah, but I'm not too
proud to steal (and credit) good solutions.  I'ld be very interested
to see the spec, and if you send it out to the list you may well get
useful comments.  I'll certainly read it carefully.

The issue, in my view, is permissions, not backing store management.
The backing store problem can be done by defining a canonical data
frame size such that all supported page sizes are an integral multiple
of it.  This provides a unit for external pagers to manipulate.  I
remain reluctant to give up a canonical data frame size, as once you
give that up implementing the page validity logic would seem to be
quite a bit harder.

The catch is permissions.  If permissions are defined by the OS
architecture as implemented at page granularity, then a problem arises
in a segment shared across processors with different page sizes.  Per
our previous discussion, there are bad ambiguities about what to do.
I don't like any of the solutions that have been proposed so far for
how to deal with this.  I have a quasi-cruddy solution for the sake of
binary compatibility with emulated environments, and I detest it
profoundly.

Also, note that there need to be two pull operations from the external
pager side.  One says "give me the data but don't remove it from the
memory object" [MACH memory object!].  The other says 'give me the
data and remove it'.  The former is essential for efficient
implementation of msync.

Actually, one must then consider whether msync should be defined as
atomic w.r.t. all other segment accesses.  I'm not sure that the
atomicity is really required for most cases, and a supporting range
locking protocol permits it to be implemented by those rare apps that
need it.


It appears that we've arrived at substantially similar models.  I'll
plop out a description of what I have in mind later this week
(hopefully).  I just have to stop talking about solutions long enough
to write one down!

   So, does this address the problem you're thinking of, or am I way out in
   left field? :-)

Left field, but it's still a nice approach :-).  



Jonathan