blaine at mac.com
Sat Feb 15 03:30:05 CET 2014
>> 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.
> 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.
> 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
>> 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!
More information about the l4-hackers