3 ms·
I'm misunderstanding something. I interpret "Latency is where µkernels have historically fallen down." as implying that µkernels have historically been worse t
by corysama 9y ago
I'm misunderstanding something. I interpret "Latency is where µkernels have historically fallen down." as implying that µkernels have historically been worse than Linux. But, that table shows them historically being sub-microsecond.
- mcguire 9y agoI'm unable to find references, so I'm reconstructing this from memory and the paper (http://sigops.org/sosp/sosp13/papers/p133-elphinstone.pdf http://sigops.org/sosp/sosp13/papers/p133-elphinstone.pdf). I have never had any experiences with L4 or any of its relatives; all of mine were with Mach and its derivatives, along with reading about the Scout microkernel (http://www2.cs.arizona.edu/projects/scout/ http://www2.cs.arizona.edu/projects/scout/). As I recall, the problem is that raw IPC costs are a red herring. It's possible to get the IPC costs almost arbitrarily small, if you're not actually toting any data or if you don't have memory protection domains separating the components (as in Scout). If you are toting data around, such as reading or writing to a filesystem server, you have three options: * Copy it. That's kind of expensive. * Share it. Copy-on-write magic, for example. Unfortunately, that requires fiddling with the VM system, to set up a mapping between user-space and filesystem-server-space, for example. Fiddling with the VM system can be surprisingly expensive, too. * Pre-establish a shared-memory buffer. This is what L4 does(?), if I'm reading section 3.2.2 correctly. It may be much better than the other options, I have no experience there. (Excellent paper, by the way. I'm hoping to get to do something with L4 at some point; microkernels are neat and it seems like it doesn't suck.)