Re: A comment about changing kernels

[Bernhard Kauer]

On Sun, Oct 30, 2005 at 09:40:18AM -0500, Jonathan S. Shapiro wrote:
> > > My problem with your proposal that a server must hold many endpoint
> > > capabilities is that it has the effect of insisting that *all* servers
> > > undertake this error-prone and complex management task.
> > 
> > If the performance of a session-based protocol is not needed than build
> > easier but slower session-less server. If they are a map() slower for every
> > operation, they should not care whether a copy() takes an IPC more.
> 
> I disagree with this statement. It appears (to me) to involve an error
> of cost estimation and a misleading cost comparison. 

I shorten your long mail to some core sentences. Please correct me, if I
quote you wrong.


> You assume that the difference in cost between (IPC w/map) vs the cost
> of 2(IPC w/map) can be ignored. This is incorrect.

No, I assume that the usage of a capability (IPC w/map) in a session-less
protocol has a significant overhead over a session-based (IPC) protocol and
that the usage happens more often then a copy via 2(IPC w/map).


> However, based on those measurements, I think that the cost of IPC+COPY
> for one capability in 50% of transfers (namely: the reply endpoint,
> which is only passed in the CALL phase of the round-trip RPC) is not
> measurably different from the cost of IPC without any transfer.

L4-IPC paths are today so heavily optimized that the influence of TLB and
even Cache misses are significant. Doing a copy involves at least 2 cache
misses by using capability registers. Capability-spaces add at least 1
additional cache and TLB miss to this number. I do not think that this is 
not measurably.


> Because of this, it would be very unfortunate to demote sessionless
> protocols to second-class status. Sessionless protocols are inherently
> cleaner, and should be preferred whenever possible because they minimize
> the temporal scope of relationships.

You are right, but sessionless protocols seem to be slower.


> But further, you are saying, in effect, that the high-performance case
> (the session-based case) requires complex storage management code in
> each server combined with a multi-party trust relationship to ensure
> cleanup.

The storage management code is needed in a session-based server anyway.
And there will be session-based servers, like the network or a window server,
in a complex system. If you do not trust anybody in this case, you need
to have another way, like a timeout, to do the cleanup.


> Whether the "extensible badge" approach will work well in practice is
> something that only time and usage will permit us to learn.

The current L4.sec specification does not have an "extensible" badge.
Up to now we do not found a usage scenario that needs one.


> My point is only to state that the hierarchy assumption is very deeply
> embedded in the L4.sec design.

I think L4.sec allows to build hierarchic systems, but it does not force
you to do so.


> I suggest that you (or somebody in Dresden) should try to extract them
> into a set of microbenchmarks that can be used to validate or invalidate
> these assertions before a large body of application-level code is written
> on L4.sec.

Jonathan:

A point which is not decidable without the protocols and the user-level
applications is: How often is a capability transfer compared to the usage-case?
Perhaps you can say something to this ratio in EROS.


Thanks,

    Bernhard