_Arthur (Arthur_@sympatico.ca) on 5/9/06 wrote:
---------------------------
>I found that distinction between microkernels and "monolithic" kernels useful:
>With microkernels, when you call a system service, a "message" is generated to
>be handled by the kernel *task*, to be dispatched to the proper handler (task).
>There is likely to be at least 2 levels of task-switching (and ring-level switching) in a microkernel call.
>
>With a monokernel call, the call is identical to a library function call. Theres
>an implicit priority level change when you call the kernel, but it is still your
>user-level process running, exactly as if it was a library call.

That's almost right.
In a normal monolithic kernel it requires one call into the kernel to access a kernel-level function. This call changes processor mode and is often relatively expensive. Once inside the kernel the user process calling it is not still running - though it's stack may still be used. It is restarted afterwards by the return from kernel code.

A microkernel though may require 2 or more calls to do the same thing.

>Changes of priority levels used to be a very expensive operation, 150+ clocks for
>the CALL gate instruction alone, on a 386. In current processors such priority level switch costs are greatly reduced.
>
>With a monolithic kernel, there will be the priority level switch, but then no
>additional cost other than the normal code to service your call.
>
>With a micro-kernel, you have to fill a message structure, context switch to activate
>the kernel task, dispatch the call, context-switch to the proper handler task again,
>who then do the required system service, but which may entail further message-passing
>for ancillary system calls to other handlers, like requesting a memory buffer. You
>can then return to the caller process with a completion of its request.
>
>So the machinery to handle system calls tends to be significantly heavier for Microkernels.
>This is balanced by a much smaller kernel proper (less likely to contain bugs),
>and the capacity to keep on running if a handler (driver) fails.

Yes. It's worth mentioning that many microkernel had performance problems not because of the overhead implied in doing all this stuff, but rather because they were badly designed and required much more of it than necessary.