Re: problems with hierarchy: L4 pagers

[Espen Skoglund]

[Marcus Brinkmann]
> At Tue, 18 Oct 2005 15:25:42 +0200,
> Espen Skoglund wrote:
>> One way to look at the in-kernel mapping database is as a cache for
>> mapping information.  Inserts to and removals from the cache happen by
>> MAP or UNMAP operations.  However, by virtue of being a cache the real
>> mapping information must be stored somewhere else, i.e., in user-level
>> pagers.  If the pagers do not record the mapping information, then
>> yeah, tough luck, you'll have a hard time reconstructing the mappings.

> I have two griefs with this design.  One is purely pragmatic, while
> the other is, as far as I understood it, at the root of at least one
> of Jonathans objections.

> First, a purely pragmatical point: While having the mapping database
> as a cache is a worthwhile concept in the case of memory resources,
> it doesn't seem to make much sense to me for capabilities to
> endpoints.  I am well aware that there are applications
> (persistence, etc) which require to keep the mechanisms for all
> resources in L4 consistent.  However, please also consider this: A
> typical client process will probably have about a couple of dozen
> endpoint capabilities.  A typical server maybe a couple of hundreds.
> From a purely pragmatical point of view, caching of mapping
> information (which _must_ be done in L4 to get a reliable structure)
> seems to be a burden to me, of little utility beyond those imposed
> by the L4 design in the first place.  In other words, there doesn't
> seem to be any "outside" pressure for endpoint capability caching.
> All pressure in this direction seems to be intrinsic in the L4
> design itself.

Well, true, there may not be a requirement for most applications to
have many endpoint capabilities.  Still, some applications probably do
have this requirement.  Further, even though there does not exist many
endpoint mappings, these mappings do consume kernel resources, and it
is necessary to have a mecnahism that allows user-level code to deal
with this.

That said, there's nothing prventing you from constructing a system
where endpoint mappings are defined to be "persistent" (i.e., where
the contract between mapper and mappee says that the mapping will only
disappear if the communication channel really is torn down).  Remember
that faults on endpoints (communication channels) are directed to the
compager of the faulting thread (as opposed to memory pager---I can
already hear Jonathan's teeth grinding at the word "pager" here), and
the compager need not be the same as the memory pager.

> Second, and more importantly.  As you go up the chain of processes
> providing the fault handlers for their clients, you will eventually
> end up at a place where more than one user is served in the same
> process.  There must be, because there can be only a single process
> at the top, and there are many users at the bottom.  So, the user's
> pagers have to be coalesced at some point in between.

> [...]

> Does the problem exist as I described?  Do you recognize it?  And if
> yes, what is your response?  If not, what is your suggested
> solution?

I believe I did answer this question earlier in a separate response to
Jonathan.  Or at least I tried to do so.

        eSk