[coyotos-dev] Capability copying
Jonathan S. Shapiro
shap at eros-os.org
Thu May 11 09:51:50 EDT 2006
Charlie may be right that fabricating and destroying resume capabilities
probably does not introduce a cache miss. I am not convinced about this.
The resume capability being formed points to the currently running
process, and at the time of formation the object header of that process
(to which the link pointers point) is not yet in cache. However, let us
assume that I am incorrect.
The unlinking and voiding of resume capabilities works the same way in
EROS that it did in CapROS and KeyKOS. Coyotos is not using a link chain
at all, and works very differently.
It is still the case that the capability slot being *overwritten* tends
to be prepared and stale, and that this causes cache misses. It is also
the case that the capability copy loop in the invocation path must make
a data-dependent control flow decision that about this that is mostly
predicted wrong.
HOWEVER
This is only half the story. It remains to be determined whether the
Coyotos approach will, in practice, reduce the total number of cache
misses.
I suppose that we will have to see.
On Wed, 2006-05-10 at 20:01 -0700, Charles Landau wrote:
> I question the analysis of capability copying at
> http://coyotos.org/docs/misc/eros-comparison.html#7, which says:
>
>
> * Most copied capabilities are prepared, and are therefore members of a list.
> * Most overwritten capabilities are prepared.
> * Capability copy therefore requires unlinking the target capability
> (two cache misses) and then re-linking the copy (one additional
> cache miss). This proves to be a major cost in invocations that
> transfer capabilities.
> * 50% of all invocations transfer at least one capability, which is
> that descriptor to which the reply should be transmitted.
>
> Taking the last point first, there is almost never more than one copy
> of the reply capability. Thus in that case the list consists of just
> the header in the process, and the single capability (which is
> necessarily in the cache).
>
> I don't know about Coyotos, but in KeyKOS and CapROS, the reply
> capability is unlinked (and voided) when it is invoked. In this case
> the invoked process is necessarily in the cache, so unlinking the
> reply capability should not cause any cache misses.
>
> In KeyKOS and CapROS, the reply capability is created (on a Call
> invocation) not copied, so there should be no cache misses on the
> creation either.
>
> I would also guess that in many instances of capability copying, the
> chain of the copied capability is short, and there is a likelihood
> that instead of cache missing on an unrelated capability in the
> chain, you are referencing the header in the object.
>
> I grant that overwritten capabilities (other than reply capabilities)
> are likely to be stale and unlinking them could involve up to two
> cache misses.
> _______________________________________________
> coyotos-dev mailing list
> coyotos-dev at www.coyotos.org
> http://www.coyotos.org/mailman/listinfo/coyotos-dev
More information about the coyotos-dev
mailing list