Linked by Norman Feske on Thu 15th Aug 2013 22:47 UTC
OSNews, Generic OSes The just released version 13.08 of Genode marks the 5th anniversary of the framework for building component-based OSes with an emphasis on microkernel-based systems. The new version makes Qt version 5.1 available on the entirety of supported kernels, adds tracing capabilities, and vastly improves multi-processor support.
Permalink for comment 569781
To read all comments associated with this story, please click here.
RE[2]: Comment by jayrulez
by Alfman on Fri 16th Aug 2013 16:15 UTC in reply to "RE: Comment by jayrulez"
Member since:


"For example, Fiasco.OC uses one kernel thread per user thread wheras NOVA uses a single-stack model for the kernel. This relieves the kernel from holding large state (a stack per user thread) and makes the kernel more easy to reason about."

I'm a big fan of this asynchronous state machine kind of approach versus having a thread-per-request! Does this asynchronous interface transcend into the userspace API?

This brings up memories for me because I wrote an asynchronous library for linux, it's a subject I'm fairly passionate about! I'm disappointed with the state of async in linux. It doesn't support async file IO at all. It ignores O_NONBLOCK and causes processes to block never-the-less. This is bad because it makes most network daemons become serialized around the file system and block continually waiting for disk platter rotations and network file systems for data that isn't cached.

True async libraries such as mine and posix are forced to spawn userspace threads serving no purpose other than to avoid kernel blocking. My library uses async linux socket IO since it abstracts network connections differently than files, but under the posix async library all descriptors are treated generically, and thus it uses blocking threads for all IO including network sockets, thus negating the purpose of async code in the first place to eliminate the need for blocked threads. Another technical problem with threads is how notoriously difficult they are to cancel. But I'm quite off topic by now, getting back to genode...

I really appreciate the analysis of SMP support in your release notes. Its a very interesting technical problem in it's own right. I've found a lot of programmers are not really aware of how expensive SMP synchronization primitives can be. IO-bound code rarely benefits from SMP. Highly multithreaded designs often have hidden bottlenecks due to the implicit serialization required by CPUs maintaining cache coherency, which is the basis for synchronization primitives.

SMP is great for running unrelated workloads on different cores because they really do run in parallel. The question is how should a scheduler distribute the threads? Those with high IPC should be on the same core. If a CPU is at 100%, one should probably try to identify threads with the least IPC and move them to other cores. But then you have to have accounting for such things, which as you've mentioned already is much more complicated than a static approach. A dynamic processor affinity solution without IPC accounting (whether it's implemented in the kernel or in userspace) basically has to resort to guessing which threads should run on which core, it can never be optimal without accounting. But then how much complexity and overhead can be justified to optimize processor affinity?

Anyways, fascinating stuff! I really enjoy technical discussions.

Reply Parent Score: 2