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.

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.