Naive question about grant/map

[Joshua LeVasseur]

On Dec 5, 2003, at 17:21, Jonathan S. Shapiro wrote:

> On Fri, 2003-12-05 at 05:58, Joshua LeVasseur wrote:
>> If you look at the mapping database as a *cache*, then your scenario
>> becomes one which describes the cache behavior, and thus isn't so
>> important in light of the semantics of user-level correctness.  In any
>> cache, it is possible for the entries to disappear, and they must be
>> resupplied when needed later.
>
> Josh:
>
> Thank you. I have always been very confused about this view of the
> mapping cache. It seems tied up with some sharing deficiencies. Would
> you be kind enough to expand a bit on how the cache gets rebuilt after
> some element gets removed?


One can look at the mapping database as providing a mechanism for the 
kernel to handle operations which would be too expensive from user 
level, as long as those operations require no policy decisions.  So the 
mapping database evicts entries when a policy decision might be 
necessary (or if the implementation becomes too hairy).

If a mapping is missing from the kernel's cache, then a policy decision 
is necessary from user-level.  The policy decision can be requested via 
a page fault request; the kernel synthesizes a page fault message to 
the faulting process's pager, and asks for the pager to supply an 
appropriate mapping.  The pager could be the process which provides the 
mapping, or it could be another thread within the process which 
receives the mapping.  In either case, the model can support some type 
of user-level policy which is most appropriate to provide the mappings. 
  For example, the page fault might be delivered to a client of a file 
server.  The page fault indicates to the client that it has hit the 
edge of the file, and must request more data from the file's disk 
backing.  The client can then IPC to the file server and provide 
appropriate performance hints, and ask for the mapping.  Or the page 
fault IPC might be sent directly to the file server (as in L4Linux), 
and the file server then uses prenegotiated information to figure out 
the file mapping (such as the elf headers of an executable).

User apps must maintain enough information to construct on-the-fly 
mapping requests.  They can't drop such information after constructing 
the mapping (a top-level pager may unmap() a deep hierarchy of 
mappings!).  But this information can be highly compressed since it is 
domain specific.  For example, a file server which responds to a 
client's page fault may know that the client maps the file 
contiguously, and so can use offsets to figure out the mapping, without 
using an expensive page table.


Hope my ramblings helped,
Josh