Hello!

[Blaine Garst]

On Feb 14, 2014, at 9:46 PM, Daniel Potts <danielp at ok-labs.com> wrote:

> 
> 
> On 15 Feb 2014, at 2:04 pm, "Blaine Garst" <blaine at mac.com> wrote:
> 
>>>> But what about my suspicion?  Seems like “swap thread registers system
>>>> call” will alone be more expensive in both time (I avoid the need to
>>>> do so) and space (since there are no nano-kernel threads waiting for
>>>> activation).  Anybody have my same hunch?
>>> 
>>> Overall, I think that current kernels do what's architecturally possible
>>> regarding IPC.
>> 
>> Sorry, but I disagree, because the software architecture is wrong.
>> 
>> Change the architecture and more speed is possible.
>> 
> 
> That's quite an assertion. Sure - change the APIs, remove functionality, etc, and you'll get it down maybe. But it won't be an L4 system.

Understood, and regrettable considering all the linux hosting work that has been done.

> 
> You do realize some implementations of L4 IPC are sub 50 cycles with full address space switch?? A lot has happened since 1992!! You've got a lot of reading (papers and code) to do. 

My hunch is that I could make it 30.  More fun to see if its true than reading papers about other people’s experiments.  Its a (validating) proof of concept exercise at this point.

> 
> My two cents: one of the big problems we have today with IPC latency in microkernels is all the nasty errata that production CPUs seem to have making what should be a fast operation orders of magnitude slower.

Yes.  Its not a mistake that the multi-cores are going to simpler earlier designs - less surface area and less errata.

Orders of magnitude? (got a paper I could read? beyond Ousterhout 90) So, I could be completely wrong in that the hardware is swamping what should otherwise be countable instructions and their contention cycles. At the time I was providing IPC at 1 order of magnitude slowdown compared to a more typical 3 orders.  (10 instruction equivalent vs 1000).



> Another big issue is misuse of IPC..
> 
> Perhaps focusing somehow on those would be more interesting. 

Well, correcting “misuses” in a systematic way is actually where I hope to get to!

Thanks for the input.  I’ll see if I can find succor in reading the 2 BSD licensed kernel.

Blaine