[cap-talk] kernel object knowledge
Jonathan S. Shapiro
shap at eros-os.com
Sun Jun 10 20:32:25 EDT 2007
On Sun, 2007-06-10 at 15:57 -0700, Jed Donnelley wrote:
> In an apples to apples
> comparison I don't see how the microkernel implementation
> can compete on performance.
The literature tells an interesting tale. It depends very much on what
we mean by "compete". L4Linux, for example, is +/- 0.5% percent relative
to native Linux on the AIM application benchmarks. That is well within
the range of variation of normal "native UNIX" vs. "native UNIX"
comparisons. I think that qualifies as directly competitive by almost
> There is a fundamental trade-off
> between performance and integrity/modularity/reliability
> if one achieves the additional integrity/modularity/reliability
> by using additional domain changes.
This is true, as is your subsequent comment that it is often possible to
However, there is something that you do NOT address in your comments (or
at least, not the ones that I have seen -- I have not been tracking
closely) that may offset this.
When a system is modularized, it often turns out that the mere fact of
domain separation removes the need for certain kinds of defensiveness.
For example, splitting a large system into domains may remove the need
for certain locks by removing certain possibilities of interference from
the design space.
Norm Hardy reports that in KeyKOS they often found that domain
separation was performance-neutral, because each domain could operate
under "single threaded" assumptions that the monolithic version of the
application could not safely make.
In short: *structural* improvements to systems often expose
opportunities for performance improvements that did not exist in the
Given this, my sense is that the truth about performance in well
engineered systems lies somewhere in the middle. My experience is that
domain separation is not usually the source of performance cost in and
of itself. The source of added cost is data copies that occur on
high-frequency paths. From the cases I have looked at in detail, it
isn't restructuring that creates performance costs. It's security
isolation across asymmetric trust boundaries, because the known
techniques for this involve copies.
Note that no "apples for apples" comparison need consider these issues,
because successful security isolation isn't (and cannot be) a serious
objective in monolithic (therefore non-isolated) designs. My observation
is that where monolithic designs have attempted to address
considerations of resource isolation, they end up with exactly the same
copy costs as microkernel systems. When these costs are introduced,
their net performance can be worse than microkernel systems because
their dynamic locality properties are less well tuned.
No hard and fast rules or conclusions here. Mainly I'm trying to point
out that the issues here are extremely subtle, and hard to talk about
without considering specific cases.
More information about the cap-talk