[coyotos-dev] Hi + some stuff I found researching

[Jonathan S. Shapiro]

Haplo, Sandro, all:

First, welcome to Haplo, and thanks for your interest.

Concerning synthesis, there are four overriding reasons NOT to do what
the Synthesis kernel did:

1. Code complexity. The size of the Synthesis runtime compiler exceeds
the total size of the Coyotos kernel. Bugs scale with lines of code, and
compilers are complex code. We simply cannot afford the negative
reliability consequences of this approach.

2. Performance. The synthesis numbers were collected before later work
on microkernels became known. Having done the IA-32 optimization of the
EROS IPC path myself, I can tell you that dynamic optimization just
won't help -- pretty much every cycle there has been hand optimized. The
other cases in the kernel are low frequency paths, and using this kind
of hammer on them isn't justified -- they aren't slow now, and in any
case they are paths that never run.

3. Fault Isolation. If you go back and look at the Synthesis papers as a
total work, you will see that the fundamental source of optimization was
combining things across layering boundaries in the software. The hidden
cost of this is that you lose abstraction and isolation, which reduces
robustness. The real victory of Synthesis, in its day, was network
performance. Many things have changed since then:

  a) Network cards now have DMA and large FIFOs
  b) TCP/IP implementations have introduced zero copy ideas and
     have generally become better tuned
  c) Interrupt behavior associated with network cards has changed

In today's conventional implementations -- even on EROS -- the limiting
factor in network performance is either the main memory speed or the PCI
transfer rate. Both are very close to the theoretical wire speed limit.
Dynamic compilation simply won't help here.

4. Verification. It is just *barely* possible to verify something like
the Coyotos kernel with enough work, but only because the code being
executed is fixed. Introducing dynamic compilation would push us beyond
what is possible (in principle) for any currently known verification
technology.


So in summary: it's complicated, it won't help, and it will reduce
robustness.

But please do not misunderstand! The Synthesis kernel was a brilliant
exploration of ideas at a time when none of these outcomes were known.
There are many *other* places in a system where these ideas are very
appropriate.


shap


On Tue, 2006-07-11 at 16:13 -0400, Haplo wrote:
> Well, firstly, the links you posted were the ones I tended to ignore  
> (as they weren't really helpful or complete, the citeseer stuff sucked).
> It was actually
> This:
> http://www.cs.princeton.edu/courses/archive/fall03/cs518/papers/ 
> synthesis.pdf
> and later this:
> http://web.cecs.pdx.edu/~walpole/papers/ogicse9307.pdf
> 
> which I found to be extremely helpful. It seems that dynamic code  
> generation itself is not necessarily the 'holy grail' of micro-kernel  
> performance, but when combined with supporting techniques produces  
> undeniable results. One of the things I found particularly  
> interesting was the use of software feedback oriented scheduling. The  
> suggested possible implementations of that seem like they would be  
> extremely efficient for real-time applications. On the other hand it  
> might also create problems in dealing with DoS, but no more or less  
> so than the issues already being addressed in coyotos.
> 
> I think your security concern is definitely valid. However, it seems  
> like a problem with the implementation, not the -concept-. The  
> difficulty arises because the concept hasn't really been explored all  
> that well, let alone in a security context. The same could be said  
> for capabilities based OSs as well though. Either way I'm almost  
> certain now that it's something worth pursuing, if only on an  
> experimental basis.
> _______________________________________________
> coyotos-dev mailing list
> coyotos-dev at smtp.coyotos.org
> http://www.coyotos.org/mailman/listinfo/coyotos-dev