Naive question about grant/map
jtl at ira.uka.de
Fri Dec 5 18:34:20 CET 2003
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.
> 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,
More information about the l4-hackers