[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: A comment about changing kernels
From: |
Bernhard Kauer |
Subject: |
Re: A comment about changing kernels |
Date: |
Tue, 1 Nov 2005 01:22:33 +0100 |
User-agent: |
Mutt/1.5.9i |
On Mon, Oct 31, 2005 at 10:05:33AM -0500, Jonathan S. Shapiro wrote:
> In order to implement a sessionless RPC protocol, every CALL (the first
> IPC) must transmit an endpoint capability. This endpoint capability will
> later be used by the server to perform a RETURN (the 2nd IPC).
...
> First question: is this set of statements consistent with your
> assumptions about how sessionless RPC would work?
Yes, I assume that a return endpoint has to be send with every CALL.
> we may safely conclude that these CALL/RETURN patterns
> describe the overwhelming majority of IPCs -- all of the other patterns
> taken together accounted in EROS for less than 1% of all dynamic IPCs.
Is the CALL/RETURN pattern used for capability delegation (giving an cap
to another party) or only for usage of these capabilities?
> As we considered the session/sessionless issue in Coyotos, I became
> convinced that using the protected payload as a session ID would not
> scale well, and also presents certain challenges for bootstrapping and
> isolation.
Interesting. What are the scalability and isolation problems with badges?
> We have therefore concluded that Coyotos needs to support capability
> registers in addition to C-spaces, and that in the normal case the send
> and receive endpoints will live in these registers.
Ok, thats a valid optimization.
> It involves a cache-aligned four-word move from one process to the other,
> using a scaled index addressing mode using the respective process structure
> pointers as base pointers.
This is a cache miss and perhaps a TLB miss since you have to touch the process
structure (I assume a thread/task split like in L4).
But don't you allow the revocation of this capability later?
> I am *guessing* that this is significantly lower than the cost that you
> anticipate for the MAP operation.
>
> Second question: do you agree that this difference in designs would
> largely explain our differing views about the costs of a sessionless
> protocol?
Yes, but up to now I am not convinced that you can build a revocable copy
with just a single cache miss.
> If the kernel does not support the sessionless protocol, then the server
> must execute the lookups necessary to map from session identifiers to the
> appropriate endpoint capabilities. The cache and TLB misses associated
> with this activity must be accounted as part of the IPC costs in order
> to make an accurate comparison.
The session-id -> return-endpoint lookup in user-level could be the identity
function, since the server is free to manage the badges. The following
capability-space lookup could be more expensive, but this is optimizable
with capability registers...
> And in fact, if you look at the EROS window system, you will discover
> that it is sessionless. So is our current ethernet driver (though this
> one needs to change).
Both components are session based in DROPS.
Thanks,
Bernhard
- Re: A comment about changing kernels, (continued)
- Re: A comment about changing kernels, Neal H. Walfield, 2005/10/28
- Re: A comment about changing kernels, Bernhard Kauer, 2005/10/28
- Re: A comment about changing kernels, Jonathan S. Shapiro, 2005/10/28
- Re: A comment about changing kernels, Jonathan S. Shapiro, 2005/10/28
- Re: A comment about changing kernels, Bernhard Kauer, 2005/10/29
- Re: A comment about changing kernels, Jonathan S. Shapiro, 2005/10/29
- Re: A comment about changing kernels, Bernhard Kauer, 2005/10/29
- Re: A comment about changing kernels, Jonathan S. Shapiro, 2005/10/30
- Re: A comment about changing kernels, Bernhard Kauer, 2005/10/30
- Re: A comment about changing kernels, Jonathan S. Shapiro, 2005/10/31
- Re: A comment about changing kernels,
Bernhard Kauer <=
- Re: A comment about changing kernels, Jonathan S. Shapiro, 2005/10/31
- Re: A comment about changing kernels, Espen Skoglund, 2005/10/31
- Re: A comment about changing kernels, Jonathan S. Shapiro, 2005/10/31
- Re: A comment about changing kernels, Bernhard Kauer, 2005/10/31
- Re: A comment about changing kernels, Jonathan S. Shapiro, 2005/10/31
- Re: A comment about changing kernels, Neal H. Walfield, 2005/10/28
- Re: A comment about changing kernels, Bernhard Kauer, 2005/10/29
- Re: A comment about changing kernels, Matthieu Lemerre, 2005/10/29
- Re: A comment about changing kernels, Marcus Brinkmann, 2005/10/30
- Re: A comment about changing kernels, Jonathan S. Shapiro, 2005/10/30