FSDN: ˇ Savannah ˇ FSF Europe ˇ GNU Art ˇ FSF
[GNU-Friends] Sections: Front Page ˇ News ˇ Interviews ˇ GNU-Friends ˇ Diaries
Menu: About ˇ Submit Story ˇ FAQ ˇ Donate ˇ Search
This page brought to you by: Jonas Öberg, just another GNU friend.
The Microkernel Experiment is Going On
By wolfgangj, Section GNU-Friends
Posted on Sun Jun 2nd, 2002 at 21:13:15 GMT

by and

This article is a response to an earlier article by Miles Nordin in Linux Journal, where he expressed his personal feelings about microkernels and monolithic kernels. We will try do present a different point of view. Of course, we are also biased, as we are both young hackers who try to turn the GNU Hurd into a software useful for everyday-work; for those who don't know it (yes, we're abusing this article as an advertisement): The Hurd is a collection of Daemons, currently running on top of the Mach microkernel and providing a replacement for the Unix kernel together with the GNU C Library.

Miles Nordin claimed that microkernels are dead already. But this is not completely true. The first generation of microkernels, which were in fact no real microkernels, are dead. But there is a new generation, which uses a radically different strategy than the original (so-called) microkernels. Thus, microkernels are still a research topic, and today they look more promising than ever before. By now, this is just something we claim, but read on, and you'll find out why we do so.

 

Out of our own experience, we can confirm that the first generation microkernel Mach is quite slow, but being microkernel independent is one of the goals of the Hurd and people are already working on porting the Hurd from Mach to the second generation microkernel L4. Those new second generation kernels aren't as slow as Mach and we think that one should not talk about the performance of microkernel based systems without having read at least some of the papers on L4. The L4 people did some interesting benchmarks, which indicate that one can get a lot of performance by making a microkernel really small. How is this supposed to work? Well, the microkernel provides very primitive, highly optimized operations, and applications use them to implement whichever way of interprocess communication is apropriate for them in an efficient way. By deciding this on a per-case basis, you get optimal performance for all applications.

But L4 takes this even further. For example, you can have schedulers in userspace. Therefore you can use a scheduler which is optimized for the specific tasks your system performs. With the kernel Linux, you can choose between different schedulers with a different source tree only, you can't switch at run-time and/or have different schedulers for different groups of processes.

Of course, microkernels still have some problems, mainly because we are bound to today's technology, and current processors have not been designed with microkernels in mind. On a processor that is not optimized for systems with monolithic kernels, where the currently still problematic overhead of context switches would vanish, microkernels would get another performance boost. This sounds like an excuse, but it is intended as a reminder about the fact that the problem is not the general concept of microkernels. However, the L4 people have done a lot of good hacks to work around all this and have reached reasonable performance already.

All this could be discussed in arbitrary detail, but we won't do that now, as we have more urgent things to do than reacting on FUD about microkernels. So we will conclude by saying that it is too easy to claim that one design is fast and the other one is slow, but everything depends on how exactly a system is designed and implemented. Maybe microkernels will eventually turn out to be slower in almost any case; we doubt that, but who knows? But even then, a microkernel based system will offer enough other advantages so that people will prefer to use it in some cases. But on the other hand, history has shown that new concepts seldom replace old ones completely, but rather establish themselfes in addition to the old ones, therefore we will have the opportunity to argue about which concept is best at least for another couple of years.. or decades?

If you are interested in research about the performance of microkernel based systems, visit http://www.l4ka.org and http://os.inf.tu-dresden.de/L4.

< Red Hat and Software Patents (0 comments) | A novel approach to real-time Free Software (0 comments) >
Login
Make a new account
Username:
Password:

View: Display: Sort:
The Microkernel Experiment is Going On | 12 comments (12 topical, editorial) | Post A Comment
[new] Debate between u- and monolithic kernels (#1)
by sjl (#345) () on Mon Jun 3rd, 2002 at 08:33:53 GMT
(User Info)

I'd bet my 5 cents (0.05 euro, that is) that we are still discussing this speed issue after _several_ decades. Personally I couldn't care less, because microkernel research is not one of the means to an end, but an end itself, as this is definitely more interesting than anything else on operating system domain at the moment.

Oh. And first post.:-D

[ Reply to This ]


 
[new] Some thoughts (#2)
by jmallett (#392) on Mon Jun 3rd, 2002 at 23:44:27 GMT
(User Info)

The new generation of microkernels doesn't quite qualify L4. L4 has been around. I think if you talk about a new generation, you'd be talking about a lot of the very user-oriented projects that have come about, such as NewOS. Microkernel independence has been shown to be not worth the benefeits. You end up favouring one over the other or resisting features because it'd mean you would favour one over the other. Unless you have two identical microkernels (in many ways), you make tradeoffs and cuts to play nice, and you gain absolutely nothing.

The user, in general, won't care what microkernel they're running on, unless they're an embedded developer and care about the license, or something.

If the microkernel "sucks", you can make it suck less. Nothing stops GNU people from making Mach better, but nobody wants to abandon Mach as it's the only place where HURD works, so instead they go for "independence".

I don't know that that will be the most beneficial arrangement.

And as an aside, I question if people in general can say "Mach is slow". Using Mach improperly will cause the overall system to seem slow, or using Mach that is not tuned for your hardware, of course. If you make everything work together well, and do the Machine-Dependent bits in an efficient way, then you don't necessarily lose. Most people see the effects of the above not being done properly, and blame Mach. This is not always accurate (though of course sometimes it is).

[ Reply to This ]


[new] Look at the long term picture (#3)
by a member of the hurd (#-1) on Tue Jun 4th, 2002 at 01:48:54 GMT

Even if the Hurd ended up being very slow it would still be very useful in high security and safety-critical applications and other areas where there is tremendous benefit to be gained by separating different parts of the system. Linux does a damn good job doing whatever we use it for at the moment. I don't think the Hurd guys are trying to create a rival to Linux, they're doing something different.

[ Reply to This ]


 
[new] embedded (#4)
by a member of the hurd (#-1) on Tue Jun 4th, 2002 at 02:44:00 GMT

I know nothing about microkernels (or monolithic ones for that matter) but I have a question. The name micro to me sounds like the kernel is very small (I know only a genius would associate micro with small). So would a microkernel do well on embedded systems with limitted memory and specific tasks?

[ Reply to This ]


[new] Disappointment (#9)
by a member of the hurd (#-1) on Tue Jun 4th, 2002 at 20:33:24 GMT

As someone who is favorably inclined toward microkernels, but not directly engaged, I was disappointed in this response. Two reactions:



(1) It seems likely that microkernels will always result in some performance penalty. The additional context switches that occur in a microkernel architecture should always result in some additional overhead. One of the papers on the L4 site claimed an additional overhead in the 5% to 10% range, which is greater than zero but certainly acceptable provided I get some benefit in exchange. Which leads me to my next point ...



(2) The original article (troll) in Linux Journal attempted to argue that microkernels don't enhance reliability or security (by arguing that the system can't recover from failures of critical user space servers). The response here didn't attempt to address this but seemed to assume that these benefits were a given.



This leads me to some questions I would like to see addressed:



(1) Does a microkernel really provided significant additional benefit in terms of reliability or security? Do we have any (hard) evidence that it does? (In this context I don't consider informed engineering judgement as hard evidence since my personal informed engineering judgement says that they should.)



(2) Assuming, as stated in the article, that microkernels are not for everyone (see my additional comment below), what engineering tradeoffs are there that would lead me to choose either a microkernel or a monolithic one?



Finally, I would note that this argument reminds me of the arguments surrounding virtual memory in the 70s. Ultimately, this argument was decided in favor of virtual memory. That is, that the 5-10% additional overhead versus (well designed) explicitly managed overlays was worth the reduction in development time and effort associated with that extra managment.





[ Reply to This ]


[new] This is amazing !... (#11)
by a member of the hurd (#-1) on Wed Jun 5th, 2002 at 16:13:35 GMT

Hi,

Following the flame war on debian-devel about the Hurd,
I installed it to get an opinion by myself, as I don't have prior
experience about micro-kernels.

So, I managed to install it alright, ... but I can't boot it !!!

The statement by Linus 10 years back is still valid. What
the purpose to have a new design, a micro-kernel and
whatever if it is not even remotely useable ? Developpers
have managed to compile half of Debian packages, but
they did not even think to provide a way to boot it !

Installation of Grub is not even available from the CD.
And once installed from Linux, I can boot Linux with
Grub, so Grub by itself is OK.

I have tried quite a lot of Linux distributions (probably
more than 30 different flavours, altogether), however
I didn't ever see anything as bad as this. And you say
that development of the Hurd started in the 80s ?
Pffff ! Even my first RedHat was better that this.

A bit of thinking about that would be great from the
Hurd people.

Cheers,
Yann


[ Reply to This ]


The Microkernel Experiment is Going On | 12 comments (12 topical, editorial) | Post A Comment
View: Display: Sort:

Verbatim copying and distribution of this article is permitted in any medium, provided this notice is preserved. Images of gnu:s in the logo are © Free Software Foundation, Inc and distributed under the GNU General Public License. Comments are copyright by thir respective owner. All other material are © 2002 .