>> 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. > 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 [email protected] http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
