On Feb 14, 2014, at 9:46 PM, Daniel Potts <[email protected]> wrote:
> > > On 15 Feb 2014, at 2:04 pm, "Blaine Garst" <[email protected]> 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 _______________________________________________ l4-hackers mailing list [email protected] http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
