Slashdot Mirror

← Back to Stories (view on slashdot.org)

KernelTrap Talks WIth GNU/Hurd Developer Neal Walfield

Posted by timothy on from the hird-about-this-one-yet dept.

An Anonymous Coward writes: "One of the GNU/Hurd developers, Neal Walfield, was recently interviewed by KernelTrap. Nice read."

15 of 218 comments (clear)

  1. Re:Interesting by Anonymous Coward · · Score: 1, Insightful

    Any sort of microkernel architecture has very little
    chance of surviving on any Intel-based
    architectures, as context switching is just too
    damn expensive (well over 500 cycles to do it
    properly). If drivers and other speed-critical code
    can't live all within the same context, there's no
    way you can get viable performance out of it.

  2. microkernel == too slow on x86 by Anonymous Coward · · Score: 1, Insightful

    Any sort of microkernel architecture has very little
    chance of surviving on any Intel-based
    architectures, as context switching is just too
    damn expensive (well over 500 cycles to do it
    properly). If drivers and other speed-critical code
    can't live all within the same context, there's no
    way you can get viable performance out of it.

    1. Re:microkernel == too slow on x86 by Pseudonym · · Score: 4, Insightful

      My first comment is that "performance" means different things to different people. To some it means "throughput", that is, the amount of work that the system can do just prior to being overloaded. To some it means how well it can handle overload. To some it means low latency, that is, that the system can respond to an important event quickly. Which one is important for you depends on what you're doing.

      Secondly, you're basing your assumptions on "microkernels" like Mach, which dates from around the same era as the original Windows NT. That's an "old style" microkernel. Back then, we thought that the only advantage of using microkernels was flexibility, so kernels didn't have to be very "micro".

      Nowadays we know that merely reducing the kernel's domain of influence doesn't buy you much. You also need to simplify your kernel to realise performance gains. You do lose something (cost of context switch etc) but you also gain lots too, so it's not so much of a penalty, but rather it's a tradeoff.

      For example, consider this: Linux often has to suspend a task deep inside a system call. If you call read() on a block of disk which is not in the buffer cache, say, you need to suspend until the block is read in from disk. A monolithic kernel may have to do this for a hundred reasons, depending on which modules are loaded. So a context switch consists of dumping registers on the kernel stack then switching stacks.

      Now consider a microkernel. You already know in advance what operations you may have to suspend on, and that number is quite small. (In the read() example, you only suspend on IPC while the server responsible for disk I/O does the hard work.) So you can separate the "front half" of each system call from the "back half". You can come up close to the surface and then context switch if necessary. (Note: You have to do this anyway on a modern system, because a higher priority task may have unblocked during the system call.) Once you've done that, each thread doesn't need its own kernel stack, which makes the context switch a little cheaper, saves memory, makes thread creation cheaper, and the kernel can be made re-entrant, delivering an IRQ in the middle of delivering another IRQ, thus improving latency. It also means you don't need to hack around the problem of signal delivery while suspended. (BSD does this by ensuring that the "front half" of every system call is idempotent, and thus possibly less efficient than it could be.)

      So you can see that focussing on the cost of context switching alone can be misleading.

      Plus, of course, keep this in mind: if raw throughput was our most important criterion, we wouldn't have virtual memory.

      --
      sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
    2. Re:microkernel == too slow on x86 by Sloppy · · Score: 5, Insightful

      "Blahblah is to slow" arguments are lame. Microkernels are too slow. Java is too slow. 3D graphics are too slow. GUIs are too slow. Virtual memory is too slow. Accessing files over a network is too slow. Calling the OS instead of directly banging the hardware is too slow. *yawn*

      Upgrade your 386SX to a new Athlon, dude. (Or better yet, a dual Athlon -- one less context switch ;-). Then nothing is too slow anymore. You can run CPU-bound stuff continuously at 87.5% utilization and your computer will still be just as fast as what you had 6 years ago, which was already overkill.

      500 clock cycles, with 2 billion clock cycles per second, that works out to... a good-looking excuse to blame things on the next time you get fragged in Quake.

      What's really funny is that you'd dare to say that something with a slight performance decrease has a "very little chance of surviving on Intel-based architectures." And yet just last week, I saw someone at my office spending way too much time, struggling to copy a bunch of files with MS Windows' explorer shell. I guess Windows has very little chance of surviving too. Unless .. wait .. unless maybe people don't care? Could it be?!?

      --
      As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
  3. Re:Using the HURD in production by Anonymous Coward · · Score: 1, Insightful

    I don't know about you guys, but my Troll Detector is going haywire right about now.

  4. I am not a kernel hacker ... by PoiBoy · · Score: 3, Insightful
    but I play one on Slashdot. :-)

    Seriously, having read the interview it seems like Hurd does some interesting stuff removing features that are part of the kernel in other unix systems and moving them into userspace.

    The real question, though, is whether we need an entirely new operating system to gain these features or whether they could instead be implemented into the standard Linux kernel. Unless they can really get a large group of people starting to develop and use it, it may go the way of the buffalo. By working on getting their changes into Linux, however, they would have a much larger userbase to start from.

    --
    Sig (appended to the end of comments you post, 120 chars)
  5. Re:Using the HURD in production by Anonymous Coward · · Score: 1, Insightful

    %80 of the /. public seems to think that troll==anything they don't like. In this case, that might have been posting for karma or lying. But, upon cursory examination of Will's account, it seems unlikely that he'd do either.

    And even so, karma or lying, he wouldn't be a troll.

  6. Re:Using the HURD in production by Hitokage_Nishino · · Score: 2, Insightful

    The problem being that Linux is largely monolithic in design while HURD is almost completely modular.

    Besides, Linus hates the HURD design.

  7. Re:Oh Lord, How Long? by rubberducky · · Score: 2, Insightful

    I don't know what you gathered from the interview, but if y'd ask me, I think I was might impressed by the ideas in the interview. Hurd, to me, seems like an excellent idea.

    As far as GNU's ability to deliver is concered, what about that editor you use (emacs). What about tools like make, flex, yacc, et all? Get real, GNU has done delivered too much to the computing community; and for free.

    Honestly, getting the hurd up 'n running has been not as important since we already have Linux. After Linux, there was no urgent need for a Free OS (what GNU was really all about at that time).
    As far as having a robust OS is concerned, we already have Linux. Whatever Hurd is going to be, it is going to be well thought out and based on good and new ideas that markedly better than conventional UNIX. Hurd is not there to replace Linux, but the project exist solely to get a new kind of OS out.

    Read the interview. It's good.

  8. Difference in philosophy by Pseudonym · · Score: 5, Insightful

    Nope. The Linux developers are hell-bent on sticking to their monolithic design. Even if you could develop the Hurd as a set of patches, they would never make it into the "standard Linux kernel". (Curious use of the word "standard", BTW.)

    The rift of Hurd vs Linux is like vi vs emacs. Vi and Hurd are meant to be a small tools designed to work in conjunction with other small specialised tools, the whole being greater than the sum of the parts. Emacs and Linux are meant to be "all features under one roof".

    Actually, that's a good way of looking at your question. Asking "can't you just implement these features in Linux?" is like asking "why do you need all those POSIX commands like diff(1); can't you just implement that in Emacs?" The answer is "yes", but would you want to?

    --
    sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
  9. Re:Hurd Speed by aheitner · · Score: 4, Insightful

    (caveat: I think microkernels are silly firewalls in code that should be correct and trusted)

    There are going to be speed problems with any microkernel-based OS -- OS X is not necessarily exempt either.

    Basically, if you spend a lot of time copying data between address spaces of different chunks of the kernel, you're going to pay for it. If you have to switch address spaces to switch kernel tasks, you're going to pay for it (in cache misses).

    Even in a monolithic-kernel OS (which will always be superior, if you assume the parts of the kernel are well-enough written that they can be trusted by other parts of the kernel), you have some cost moving data from userspace to kernel space. You can get around that in clever cases -- Linux does this with zerocopy networking, passing sets of (physical) pages around and dumping them directly to the card driver.

    As Linus once said "Mantra: `Everything is a stream of bytes'. Repeat until enlightened." In other words, any obsessiveness that gets in the way of moving streams of bytes around extremely efficiently is not good architecture. Message passing (and separate address spaces for kernel "server" modules) fall into this category.

  10. define "superior" by Anonymous Coward · · Score: 0, Insightful
    Is "superior" just "faster" to you? If so, why not just say "faster"?

    Microkernel gets you two benefits: flexibility and security. The first one is obvious: if I'm a student at Lame U (Go-o-o Lamers!), I don't have to wait for the sysadmin to install things like filesystems; I can install them myself.

    Security is more interesting, and Neal did get into this a bit. Consider your favourite insecure FTP daemon (I've come to the conclusion that ALL FTP daemons are horribly insecure -- what is it about FTP daemon coders that they can't figure out buffers?). Under monolithic kernel, FTP daemon is run as "root" and then transforms to luser. Under microkernel, FTP daemon is run as "nobody" and then transforms to luser. When Joe 15-y34r-0ld cr4x your box, he is going to end up as either "root" (under Linux) or "nobody" (under Hurd). I know which one I'd choose.

    Anyway, long post short -- faster != superior.

  11. So Linus doesn't like microkernels... by nadador · · Score: 5, Insightful

    therefore they are bad.

    Right, right.

    As others have noted, there's no way for a microkernel to be as speedy at flipping bits around as a monolithic kernel, copying between address spaces and everything. Apple attempts to mitigate some of those costs by keeping all their Mach threads in one address space, IIRC, but even with that speed up there's still some overhead.

    But that doesn't mean that microkernels suck.

    Apache doesn't serve static pages as fast as other web servers. It doesn't serve dynamic content as fast as some servers. But people use Apache for other reasons, things like configurability, extensibility, and support. And because the only thing you *can't* do with an Apache module is make babies.

    Microkernels are interesting to computer scientists because they allow abstraction in the kernel, and God only knows that there's no word that computer scientists like more than "abstraction". Microkernels, for all there faults, are just plain prettier. And as research continues into microkernels and how to mitigate their many flaws, there might come a time when the extra processing they require might be worth it. Maybe all the abstraction and objectiness will be worth it to some system designer in the future.

    At some point, there may be people who will be willing to trade some latency and throughput for extensibility and configurability in their kernels. They might be willing to trade some clock cycles for the ease with which they can implement different security policies, ala HURD. The point is that not everyone needs the same kernel, and not everyone needs the same kind of kernel.

    And competition is good for them both. The HURD developers are incouraged to speed up the kernel, thanks to Linux. Linux kernel hackers will eventually desire some of the design niceties of the HURD kernel, they just won't admit it on the LKML.

    --

    Outside of a dog, a book is a man's best friend. Inside a dog, its too dark to read.
  12. Re:Hurd Speed by Pseudonym · · Score: 3, Insightful

    Mach is an old-style microkernel. It comes from the same era as Windows NT.

    QNX/Neutrino is a modern microkernel which comes from the same era as BeOS.

    There's no comparison. Mach is big and tries to do too much, even for a microkernel. But it comes from an era when we throught that the most important advantage of microkernels was flexibility. We now know that by making them very "micro" they can give performance too.

    You won't find hard real-time in Hurd any time soon. Not as long as they're using Mach and allow use of Linux device drivers, anyway. Hard real-time needs to be designed in everywhere, from the driver to the kernel to the application.

    The world does need a free real-time general-purpose OS, you're right. Real-time is becoming ever more important even in server applications (e.g. ATM routing, streaming media). You won't find it in the Hurd, but there are one or two projects happening in relative secrecy at the moment. Watch this space.

    --
    sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
  13. But Linus *does* like microkernels! by kinnunen · · Score: 3, Insightful
    Read the Linus vs. Tanenbaum thread. While it is a comparison of Linux and Minix, it gives you a pretty good indication of how Linus feels (or felt at the time) about microkernels in general. Here is one quote (my bold): "True, linux is monolithic, and I agree that microkernels are nicer. With a less argumentative subject, I'd probably have agreed with most of what you said. From a theoretical (and aesthetical) standpoint linux looses." --Linus

    The thing is, Linus does care about speed difference. A lot.