Re: self-paging

[Jonathan S. Shapiro]

On reflection, There may be a way to give Bas what he seems to want.

We've agreed that notification is a separate problem, so I'm not talking
about that right now.

W.r.t. residency pools, we can potentially separate two things:

   1. Specifying the group of pages that compete with each other. 
      This is the part that the EROS frame pool deals with well.

   2. Specifying which page to shoot down when the pool is full and 
      a new page must come in.

I provisionally believe that if we want to use any sort of LRU, the
gathering of age data must be performed by the kernel. Since the kernel
needs to collect this data anyway, I think that *one* of the policies we
should have is "LRU w.r.t. the rest of the pool" and that this should be
directly implemented by the kernel.

But it is also possible to have a protocol in which the kernel turns to
a "keeper" associated with the pool. Basically, the kernel upcalls the
keeper (very much like fault handling) and says "make some room in this
pool".

The keeper can then shoot down member frames explicitly by naming their
virtual address, using a call of the form

        pool->unbind(va);

One part of this differs from what Bas seems to be proposing: we want to
be able to associate pools with regions of the virtual space as opposed
to the entire space. The issue is that we may want to manage the
residency of shared objects on some collective basis, and to do this, we
need to be able to associate pools with memory objects. The second issue
is that I haven't thought through how to go about getting *inbound*
information to the pool keeper. Does the keeper need to know about the
order of page inserts?

shap