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