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

[Haplo]

No offense taken, this is good to know.
1.I really didn't think that would be the case. Massalin's claims  
wouldn't lead one to believe that, but in that case I have to  
completely agree.
This point is a real slap in the face to Linus only because of how  
true it is ^^.

2-3.These are the points I was concerned with. It seems that the  
worst case has played out on his concept, so the brute of it is no  
longer applicable.
Oh well, just means coyotos is at a good point already.

4.Well, with points 1-3, 4 is kinda moot. If there's no benefit to  
doing so then there's no real point to worry about the consequences  
either. I suppose it was good to point out anyway, though. I see  
since run-time variables are used in the code generation that it,  
like currying, would be unverifiable. Guess I should have thought a  
bit harder about that one :P.

It doesn't necessarily mean ALL of the ideas are not worthwhile  
though. There are a few points of interest you didn't address.

A: Software feedback based scheduling. This seems like a good idea to  
me. Priority based scheduling is just too limiting, and in the end it  
all ends up "best guess" or the more common case is that most non-OS  
associated apps are all given the same priority. Even if the  user  
can modify priorities, as is the case on most *nix systems, it's a  
difficult process and automated solutions just end up reducing  
multitasking performance, or worse starve processes it depends on for  
resources. It also works VERY badly for real time multimedia  
applications - games, media players, audio/video editing tools, where  
the applications are very time and throughput sensitive. It simply  
doesn't take into account that an application's resource needs WILL  
vary at run-time, and doesn't account for services they depend on at  
all.

B:Executable data structures. This has limited use but could still  
provide improvement. In this case it would be more like instantiating  
an object than dynamically generating code. The most specific example  
of where this might be useful - that I can give at least - would be  
capability register pages. If a page can only hold a certain number  
of indices, then in-lined code that "knows" about the capabilities  
it's managing could traverse them quickly and return the capability  
at the selected index. Also, it could be used to link capability  
pages together that are owned by the same process. For example a  
process wants to invoke capability index x, so a retrieval request is  
sent to capability page 1, which holds indices 0-y. If x <= y, the  
index can be retrieved through a simple algorithm. If x > y, then the  
request is modified to x = x-y, then passed onto the linked page,  
which holds y+1 - y*2 (at maximum anyway). In this way each  
capability executable page can have the same code, while allowing  
efficient traversal. Again, I can't really determine that myself, but  
it does seem like a good idea.

C:Something not really synthesis related that I didn't mention  
earlier for various reasons. A self-healing layer like in Minix-3. It  
seems like a good idea in any case, since according to the docs  
almost all invocations can be resent anyway. The main difference is  
that periodic pinging would be superfluous in coyotos, since coyotos  
can detect abnormal timeouts already. This way it would simply invoke  
the healing layer to resolve what ACTUALLY happened. Appropriate  
action can be taken from there - either resend the request or restart  
the driver THEN resend the request. In the rare outside case the  
dependent process would still crash, but oh well? That's no better or  
worse than not having it, but in the case of MOST processes it's an  
improvement. Furthermore, the healing layer could also be made to  
collect details about a driver crash in that event, which could be  
sent to the developers so that they can fix it. I really don't see  
any downsides to this.

On Jul 12, 2006, at 8:02 AM, Jonathan S. Shapiro wrote:

> 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
>
>
>
> coyotos-dev mailing list
> coyotos-dev at smtp.coyotos.org
> http://www.coyotos.org/mailman/listinfo/coyotos-dev