Hello!

[Daniel Potts]

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.

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 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. Another big issue is misuse of IPC..

Perhaps focusing somehow on those would be more interesting. 



>> So I'd assume there's not much to squeeze out further.
>> And yes, it's not only about the good case but also for all the other
>> cases where more handling is needed and thus checks on the way.
> 
> Umm, I was suggesting that one has known-to-need-no-checks
> entries and known-to-need-checks entries.
> 
> For Apple’s generational conservative GC we overloaded the assignment
> operator to call a helper function.  At runtime we page mapped in
> the appropriate helper function, and used a single instruction call.
> 
> For non-GC the implementation was “store; return”.
> 
> So bloody fast we couldn’t measure its cost.
> 
>> I'd
>> suggest to look at the existing kernels to see how they're doing.
>> 
>>> "After disastrous results in the early 90's, the microkernel approach
>>> now seems to be promising, although it still bears a lot of research
>>> risks.”
>>> 
>>> I’m curious as to what “results” were being referenced.
>> 
>> 1st-gen kernels, i.e. Mach.
> 
> I was hired at NeXT on the premise that Mach’s IPC wasn’t fast enough!
> 
>>> 
>>> Not that its multicore (yet), but has anyone in this community been
>>> exploring putting L4 on a Raspberry Pi?
>> 
>> Fiasco/L4Re is also running on the Raspberry.
> 
> Thanks - I’ll peruse its licensing agreement!
> 
> Blaine
> 
> 
> _______________________________________________
> l4-hackers mailing list
> l4-hackers at os.inf.tu-dresden.de
> http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers