Mico-kernel vs monolithic - context switch

[Tapti]

Hi all!

I have a question regarding the performance of micro-kernels and monolithic kernels.

I heard from a certain source that micro-kernels are not really worse in terms of performance, compared to monolithic kernels. The reason stated was this - The service, (drivers, etc) are in the Layer 1/2 (on Intel architecture), the applications do not need to do a context switch to invoke the drivers. The communication between the applications can be done through IPC mechanism, whereas a context switch is needed for the same on a monolithic kernel.

But, my question is this - doesn't the driver have to communicate with the kernel (which is in Layer 0 and needs a context-switch)? So, in effect, the context-switch is still very much there, and we have IPC mechanism on top of it. So, shouldn't the performance of micro-kernels be worse than monolithics?

Sorry if I am missing anything fundamental - am quite new to the operating systems design. Any help would be very much appreciated

[Solar]

In a "classic" monolithic kernel, kernel and drivers are in "supervisor" mode (ring 0 on Intel). No context switching, no IPC. No protection.

In a "classic" microkernel, the kernel is in "supervisor" mode, drivers are in "user" mode (ring 3 on Intel). The kernel is protected from faults in the drivers, but you have to go through context switches / IPC for communication.

As for ring 1 and 2... not all features of the Intel CPU distinguish between all four possible rings. Page protection, for example, knows only "user" (ring 3) and "super" (ring 0, 1, and 2). I am not even sure if it is possible to get a good, non-leaking protection of ring 0 code from ring 1/2 code. I know that I got the impression the answer is "no" when I last read the Intel docs (which is about 10 years since...), because I never bothered with ring 1 / 2 again.

I might have been wrong, though.

In any case, and no matter how you twist it, a context switch is the price you pay for hardware protection.

[Combuster]

It appears that the OP's source seems to be misinformed. And Solar beat me to half of the story.

Monolithic kernels require no context switches as all drivers are present in all address spaces.

Microkernels impose isolation between all drivers, which means they can't touch each other and can't directly mess up the system. This is often implemented by removing the distinction between drivers and application and making them both processes. You then incur the context switch when you are changing from an application to a driver or vice-versa since a different program gets executed. Due to x86 design, ring1/ring2 use requires a segmentation-aware OS (for reasons Solar mentioned), which is not a standard practice.

Switching from rings is not necessarily considered a context switch, as the application is still present and available to the kernel and other programs in the higher rings. At any rate, the effort to change from one ring to another is the same: if changing to ring 0 is worth mentioning a penalty, so must be a change to ring 1. In fact 3-0 and 0-3 transitions are faster than anything with ring1/2 because they are more common and chip designers special cased them: the exact opposite of what your source suggests.

With good design, a call to a driver does not always need a context switch: you can stack requests and have them executed altogether when the application would be scheduled anyway. On multicore systems you can have the driver run on one core while the using application runs on the other, effectively meaning zero context switches.

In the end microkernels only lose to monolithics due to the overhead of the extra protection. Monolithics then lose to micros for a lack of stability. Hybrid designs are consequently formed from the case where you only drop the protection when you need the speed. Both Desktop Linux and modern Windows systems are technically hybrids to various extents even though they have roots as a monolithic kernels.

There's also modular kernels (which are just monolithics done differently and not really relevant to the discussion) and exokernels (which are a completely ortoghonal concept, but interesting nevertheless)