Hybrid kernel, not NT

By: Linus Torvalds (torvalds.delete@this.osdl.org), May 9, 2006 7:16 am
Room: Moderated Discussions
_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.

I don't think you should focus on implementation details.

For example, the task-switching could be basically hidden
by hardware, and a "ukernel task switch" is not necessarily
the same as a traditional task switch, because you may have
things - hardware or software conventions - that basically
might turn it into something that acts more like a normal
subroutine call.

To make a stupid analogy: a function call is certanly "more
expensive" than a straight jump (because the function call
implies the setup for returning, and the return itself).
But you can optimize certain function calls into plain
jumps - and it's such a common optimization that it has a
name of its own ("tailcall conversion").

In a similar manner, those task switches for the system
call have very specific semantics, so it's possible to do
them as less than "real" task-switches.

So I wouldn't focus on them, since they aren't necessarily
even the biggest performance problem of an ukernel.

The real issue, and it's really fundamental, is the issue
of sharing address spaces. Nothing else really matters.
Everything else ends up flowing from that fundamental
question: do you share the address space with the caller,
or put in slightly different terms: can the callee look at
and change the callers state as if it were its own
(and the other way around)?

Even for a monolithic kernel, the answer is a very emphatic
no when you cross from user space into kernel space.
Obviously the user space program cannot change kernel state,
but it is equally true that the kernel cannot just consider
user space to be equivalent to its own data structures (it
might use the exact same physical instructions, but it
cannot trust the user pointers, which means that in
practice, they are totally different things from kernel

That's another example of where "implementation" doesn't
much matter, this time in the reverse sense. When a kernel
accesses user space, the actual implementation of
that - depending on hw concepts and implementation - may
be exactly the same as when it accesses its own data
structures: a normal "load" or "store". But despite that
identical low-level implementation, there are high-level
issues that radically differ.

And that separation of "access space" is a really big
deal. I say "access space", because it really is something
conceptually different from "address space". The two parts
may even "share" the address space (in a monolithic kernel
they normally do), and that has huge advantages (no TLB
issues etc), but there are issues that means that you end
up having protection differences or simply semantic
differences between the accesses.

(Where one common example of "semantic" difference might be
that one "access space" might take a page fault, while
another one is guaranteed to be pinned down - this has some
really huge issues for locking around the access, and for
dead-lock avoidance etc etc).

So in a traditional kernel, you usually would share the
address space, but you'd have protection issues and some
semantic differences that mean that the kernel and user
space can't access each other freely. And that makes for
some really big issues, but a traditional kernel very much
tries to minimize them. And most importantly, a traditional
kernel shares the access space across all the basic system
calls, so that user/kernel difference is the only
access space boundary.

Now, the real problem with split access spaces is
not the performance issue (which does exist), but the
much higher complexity issue. It's ludicrous how micro-
kernel proponents claim that their system is "simpler" than
a traditional kernel. It's not. It's much much more
complicated, exactly because of the barriers that it has
raised between data structures.

The fundamental result of access space separation is that
you can't share data structures. That means that you can't
share locking, it means that you must copy any shared data,
and that in turn means that you have a much harder time
handling coherency. All your algorithms basically end up
being distributed algorithms.

And anybody who tells you that distributed algorithms
are "simpler" is just so full of sh*t that it's not even

Microkernels are much harder to write and maintain
exactly because of this issue. You can do simple
things easily - and in particular, you can do things where
the information only passes in one direction quite easily,
but anythign else is much much harder, because there is
no "shared state" (by design). And in the absense of shared
state, you have a hell of a lot of problems trying to make
any decision that spans more than one entity in the

And I'm not just saying that. This is a fact. It's a fact
that has been shown in practice over and over again, not
just in kernels. But it's been shown in operating systems
too - and not just once. The whole "microkernels are
simpler" argument is just bull, and it is clearly shown to
be bull by the fact that whenever you compare the speed
of development of a microkernel and a traditional kernel,
the traditional kernel wins. By a huge amount, too.

The whole argument that microkernels are somehow "more
secure" or "more stable" is also total crap. The fact that
each individual piece is simple and secure does not make
the aggregate either simple or secure. And the
argument that you can "just reload" a failed service and
not take the whole system down is equally flawed.

Anybody who has ever done distributed programming should
know by now that when one node goes down, often the rest
comes down too. It's not always true (but neither is it
always true that a crash in a kernel driver would bring
the whole system down for a monolithic kernel), but it's
true enough if there is any kind of mutual dependencies,
and coherency issues.

And in an operating system, there are damn few things that
don't have coherency issues. If there weren't any coherency
issues, it wouldn't be in the kernel in the first place!

(In contrast, if you do distributed physics calculations,
and one node goes down, you can usually just re-assign
another node to do the same calculation over again from
the beginning. That is not true if you have a
really distributed system and you didn't even know where
the data was coming from or where it was going).

As to the whole "hybrid kernel" thing - it's just marketing.
It's "oh, those microkernels had good PR, how can we try
to get good PR for our working kernel? Oh, I know,
let's use a cool name and try to imply that it has all the
PR advantages that that other system has"

< Previous Post in ThreadNext Post in Thread >
TopicPosted ByDate
Hybrid (micro)kernelsTzvetan Mikov2006/05/08 03:41 PM
  Hybrid (micro)kernelsS. Rao2006/05/08 05:14 PM
  Hybrid (micro)kernelsBill Todd2006/05/08 05:16 PM
    Hybrid (micro)kernelsTzvetan Mikov2006/05/08 06:21 PM
      Hybrid (micro)kernelsnick2006/05/08 06:50 PM
      Hybrid (micro)kernelsBill Todd2006/05/09 12:26 AM
        There aren't enough words...Rob Thorpe2006/05/09 01:39 AM
          There aren't enough words...Tzvetan Mikov2006/05/09 02:10 PM
            There aren't enough words...Rob Thorpe2006/05/14 11:25 PM
        Hybrid (micro)kernelsTzvetan Mikov2006/05/09 10:17 AM
          Hybrid (micro)kernelsBill Todd2006/05/09 03:05 PM
  Hybrid (micro)kernelsrwessel2006/05/08 10:23 PM
    Hybrid kernel, not NTRichard Urich2006/05/09 05:03 AM
      Hybrid kernel, not NT_Arthur2006/05/09 06:06 AM
        Hybrid kernel, not NTRob Thorpe2006/05/09 06:40 AM
          Hybrid kernel, not NT_Arthur2006/05/09 07:30 AM
            Hybrid kernel, not NTRob Thorpe2006/05/09 08:07 AM
              Hybrid kernel, not NT_Arthur2006/05/09 08:36 AM
                Linux vs MacOSX peformance, debunked_Arthur2006/05/18 06:30 AM
                  Linux vs MacOSX peformance, debunkedRob Thorpe2006/05/18 07:19 AM
                    Linux vs MacOSX peformance, debunkedAnonymous2006/05/18 11:31 AM
        Hybrid kernel, not NTLinus Torvalds2006/05/09 07:16 AM
          Hybrid kernel, not NTAndi Kleen2006/05/09 01:32 PM
            Hybrid kernel, not NTmyself2006/05/09 02:24 PM
              Hybrid kernel, not NTmyself2006/05/09 02:41 PM
              Hybrid kernel, not NTBrendan2006/05/09 04:26 PM
                Hybrid kernel, not NTLinus Torvalds2006/05/09 07:06 PM
                  Hybrid kernel, not NTBrendan2006/05/13 12:35 AM
                    Hybrid kernel, not NTnick2006/05/13 03:40 AM
                      Hybrid kernel, not NTBrendan2006/05/13 08:48 AM
                        Hybrid kernel, not NTnick2006/05/13 06:41 PM
                          Hybrid kernel, not NTBrendan2006/05/13 08:51 PM
                            Hybrid kernel, not NTnick2006/05/14 04:57 PM
                              Hybrid kernel, not NTBrendan2006/05/14 09:40 PM
                                Hybrid kernel, not NTnick2006/05/14 10:46 PM
                                  Hybrid kernel, not NTBrendan2006/05/15 03:00 AM
                                    Hybrid kernel, not NTrwessel2006/05/15 06:21 AM
                                      Hybrid kernel, not NTBrendan2006/05/15 07:55 AM
                                        Hybrid kernel, not NTLinus Torvalds2006/05/15 08:49 AM
                                          Hybrid kernel, not NTnick2006/05/15 03:41 PM
                                          Hybrid kernel, not NTtony roth2008/01/31 01:20 PM
                                    Hybrid kernel, not NTnick2006/05/15 05:33 PM
                                      Hybrid kernel, not NTBrendan2006/05/16 12:39 AM
                                        Hybrid kernel, not NTnick2006/05/16 01:53 AM
                                          Hybrid kernel, not NTBrendan2006/05/16 04:37 AM
                  Hybrid kernel, not NTAnonymous2008/05/01 09:31 PM
                    Following the structure of the treeMichael S2008/05/02 03:19 AM
                      Following the structure of the treeDean Kent2008/05/02 04:31 AM
                        Following the structure of the treeMichael S2008/05/02 05:02 AM
                        Following the structure of the treeDavid W. Hess2008/05/02 05:48 AM
                          Following the structure of the treeDean Kent2008/05/02 08:14 AM
                            Following the structure of the treeDavid W. Hess2008/05/02 09:05 AM
                              LOL!Dean Kent2008/05/02 09:33 AM
                              Following the structure of the treeanonymous2008/05/02 02:04 PM
                                Following the structure of the treeDean Kent2008/05/02 06:52 PM
                                Following the structure of the treeFoo_2008/05/03 01:01 AM
                                  Following the structure of the treeDavid W. Hess2008/05/03 05:54 AM
                                    Following the structure of the treeDean Kent2008/05/03 09:06 AM
                                      Following the structure of the treeFoo_2008/05/04 12:06 AM
                                        Following the structure of the treeMichael S2008/05/04 12:22 AM
            Hybrid kernel, not NTLinus Torvalds2006/05/09 04:19 PM
              Microkernel Vs Monolithic KernelKernel_Protector2006/05/09 08:41 PM
                Microkernel Vs Monolithic KernelDavid Kanter2006/05/09 09:30 PM
                  Sigh, Stand back, its slashdotting time. (NT)Anonymous2006/05/09 09:44 PM
                  Microkernel Vs Monolithic Kernelblah2006/05/12 07:58 PM
                  Microkernel Vs Monolithic KernelRob Thorpe2006/05/15 12:41 AM
          Hybrid kernel, not NTAnalGuy2006/05/16 02:10 AM
            Theory versus practiceDavid Kanter2006/05/16 11:55 AM
              Distributed algorithmsRob Thorpe2006/05/16 11:53 PM
              Theory versus practiceHoward Chu2006/05/17 01:54 AM
                Theory versus practiceJS2006/05/17 03:29 AM
          Play online poker, blackjack !!! Gamezonex2007/08/16 12:49 PM
  Hybrid (micro)kernelsphilt2006/05/14 08:15 PM
    Hybrid (micro)kernelsLinus Torvalds2006/05/15 07:20 AM
      Hybrid (micro)kernelsLinus Torvalds2006/05/15 10:56 AM
        Hybrid (micro)kernelsRob Thorpe2006/05/16 12:22 AM
          Hybrid (micro)kernelsrwessel2006/05/16 10:23 AM
            Hybrid (micro)kernelsRob Thorpe2006/05/16 11:43 PM
              Hybrid (micro)kernelsrwessel2006/05/17 12:33 AM
                Hybrid (micro)kernelsRob Thorpe2006/05/19 06:51 AM
                  Hybrid (micro)kernelsrwessel2006/05/19 11:27 AM
      Hybrid (micro)kernelstechIperson2006/05/15 12:25 PM
      Hybrid (micro)kernelsmas2006/05/15 04:17 PM
        Hybrid (micro)kernelsLinus Torvalds2006/05/15 04:39 PM
          Hybrid (micro)kernelsColonel Kernel2006/05/15 08:17 PM
            Hybrid (micro)kernelsWink Saville2006/05/15 09:31 PM
              Hybrid (micro)kernelsLinus Torvalds2006/05/16 09:08 AM
                Hybrid (micro)kernelsWink Saville2006/05/16 08:55 PM
          Hybrid (micro)kernelsrwessel2006/05/16 10:31 AM
            Hybrid (micro)kernelsLinus Torvalds2006/05/16 11:00 AM
        Hybrid (micro)kernelsBrendan2006/05/16 12:36 AM
        Hybrid (micro)kernelsPaul Elliott2006/09/03 07:44 AM
          Hybrid (micro)kernelsRob Thorpe2006/09/04 08:25 AM
      Hybrid (micro)kernelsphilt2006/05/15 11:55 PM
        Hybrid (micro)kernelspgerassi2007/08/16 06:41 PM
  Another questionable entry on Wikipedia?Chung Leong2006/05/18 09:33 AM
  Hybrid (micro)kernelsisrael2006/05/20 03:25 AM
    Hybrid (micro)kernelsRob Thorpe2006/05/22 07:35 AM
Reply to this Topic
Body: No Text
How do you spell green?