OSNews

I am surely not expert in the OS internals area, but here's some possible parameters to consider:

1) "monolithic kernel sucks" is general attitude of many ppl, myself included, and you can't do anything about it :-) (you know, Amigan, message based system)

2) now really - what was interesting, was back then, when Amiga under the Gateway wings, was supposed to use QNX as a base for new OS. I remember when Linus joined the message board, with some claims, and as fast as he joined he left, because real gurus were there - with QNX. You could see many ppl claiming, that QNX had some 20-30 (micro?) sec latency, whereas Linux, at that time, some 600? Well, it was in 1997/8? I do remember Dave Haynie (one of Amiga designers) stating something like Linux was not at all usable for things like multimedia, e.g. sound, like BeOS was at that time - just because of latency. So - why had it so bad latency, while being monolithic? I suppose nowadays, the issue with latency is gone, and who knows, maybe my understanding of the issue is not correct anyway ...

haha, that whole gateway/amiga deal was one of the things i was going ot reference. but being as it is now so far out of date i didn't bother. you are right though about the events that transpired. glad i am not the only person who remembered that/took part in it.

you could implement message based IPC in a macrokernel too ;-)


preface: i prefer the word "macrokernel" because "monolithic" is really the opposite of "structured", as in a system that enforces logical data / function separation between components, and defines boundaries and communication interfaces for them, be they in the same address space or not
actually the microkernel / macrokernel difference depends on the amount of abstractions the kernel supports via its facilities, and is orthogonal to the monolithic / structured one... but anyway
so, the word "monolithic" or "macrokernel" says something about the way a kernel appears when it has been loaded into memory (i.e. what its binary image contain, from a functional point of view - i.e. it may contain device support code - drivers - it may contain VFS node handling code - filesystems - etc)
if one doesnt take the above digression into account, reading "monolithic" may also denote the way the kernel has been organized, code- and structure wise (that is, implemented with global data structures instead of per -subsystem private ones and access APIs )

but it says nothing about the implementation details of those data structures, and the algorithmic efficiency of code that manupilates them
in practice, one can have a kernel with an internal FS layer and drivers performing, or appearing to perform (that is, depending on the use case and the evaluation metric) worse than a system in which they're external - for some applications global throughput is far more important than latency, for others the converse is true

the problem with latency mainly lies in the cost of resource sharing across processes and now threads
on unix and operating systems derived and inspired from unix, the kernel completely virtualizes the underlying system, and then *is* the system, for all intents and purposes of applications, that can only access the HW via kernel calls
thus the kernel itself is a shared resource, on older kernels this translated into a global mutual exclusion lock, that ensured only one process at a time could be running inside the kernel (meaning, could be waiting on an impending syscall while the kernel executes its part)
this ensured the rest of the kernel code could be lean for the sake of (relative) simplicity, but it also made it not very scaleable
on the other hand, a similar mutual exclusion was introduced by the "hardware layer" of the kernel - when executing some privileged HW operation on a bus or device, HW interrupts were disabled to be reenabled when the operation is completed - this effectively means the systems does not react to user input during that timeframe, since mouse or keyboards events are ignored

what time brought to linux and bsd, was incremental algorithmic updates that pushed locking "down" to individual data structures, making resource contention more granular and increasing scalability at the cost of some added complexity - and, with preemption points, a reduction (yet no complete elimination) of the inactive interrupt window - which yielded higher than before responsiveness and lower *innterrupt* latency (which, it maust be noted, is a separae thing from syscall latency - the time taken by system calls to execute vary greatly across types of calls and with the size of the working sets - thus a worst case value, is usually accounted)

OTOH, other systems developed from scratch have been able to tackle the above problems earlier and more effectively by taking a different design right from the start
many if not all modern microkernels have a couple things in common - one is a fast, usually message based IPC, necessary to achieve adequate throughput while retaining user space servers
another is their claiming to be "fully preemptable" (a new operation may be submitted to the kernel at any time, and the kernel is nearly always ready on interrupts - so the nominal latency becomes the latency of an interrupt serve)
since there are always some lowest level pivileged operations that cannot be preempted, the kernel cannot really be preempted at *any* time, but since these are usually extremely short (orders of magnitude shorter than the normal kernel code path), atomic operations, they might become the actual granularity unit without imposing noticeable overhead

the third is one that partly derives from the former: if you have userland services and a message based IPC system, chance is you'll implement a flexible and so-not-old-unix transaction dispatch mechanism

one interesting side effect is that, if versatile enough, the dispatch mechanism may go as far as to support both user and in kernel servers
then one may build primary services back into the kernel for performance reasons
but because of that dispatch mechanism and because of what is "at heart", it probably won't be a monolithic kernel, rather a structured extended kernel based on a microkernel

you'll have effectively reinvented NT ^_^

Edited 2008-11-12 16:57 UTC

"Also, while it's good that you have benchmarked it, a total lack of data aswell as how you've benchmarked them makes the statement pretty pointless and lumps it together with all the other subjective 'it feels faster' nonsense scattered across the web."

by "prompted me to do a benchmark, it means i havent done one officialy yet but due to this I will be doing on, and it will be fairly extensive. I will likely do it this weekend when i get time.