After the Why I like microkernels article, I thought it'd be useful to have a view from the "other side" of this endless war. While some of the reasons given by microkernel fans are true, the big picture is somewhat different and it's what I think it keeps traditional-style kernels in the top. Note: please take note that the author is not a native English speaker, so forgive any grammar or spelling mistakes.
Post a Comment
Member since:
2005-09-28
Fans: 0
This is not meant to be offensive, but I'm tired of the disclaimer "the author is not a native speaker of English; please excuse grammatical mistakes." This is what editors are for! Can't authors find a native English speaker to proofread their work? Since this article is an OSNews "exclusive," can't someone at OSNews do a little light editing? That would be the procedure at a print magazine.
And yes, I will happily proofread for anyone who asks me to ;-)
Member since:2005-04-01
Fans: 15
We don't do that. First of all, our articles are often meant to be a community collection. Secondly, it's often very hard to edit these articles for clarity without injecting any bias. As such, we made the editorial decision - long before Thom even - that editing would be minimal.
Member since:2005-06-29
Fans: 19
As such, we made the editorial decision - long before Thom even - that editing would be minimal.
Exactly. The article is NOT off of my hand, and as such, I cannot edit it freely. All we do is remove the really obvious errors, and I personally have an obsession with punctuation. It helps that I study English at university, by the way.
In any case, please discuss the actual article. Posts concerning the English are off topic and will be set to -5. Just so you know.
Member since:2005-09-28
Fans: 0
Member since:
2006-03-08
Fans: 1
But It reminds me debate like RISC vs CISC or procedural vs OO programming.
While I agree with the article, I'd like to emphazise on the fact that well designed micro-kernel are easier to maintain, that developping such kernel in a collaborative way is easier if good interface are provided.
I think it's a question af choice since both micro-kernel and monolithic kernel have pros and cons.
Member since:
2005-07-06
Fans: 0
It is a shame you even have to put a disclaimer in about the writer being non English speaking in the post. If someone has to tear down an article based on the writers command of English then it just means they really have nothing to offer in the way of a rebuttal. Perhaps you should just put the article there in the writers native language. That would at least weed out those who were just there to deride someone else's lack of total command of the English language.
For those who get upset because someone can't write perfect English: I have news for you, you can't either so get over it. English speakers as a primary language are in the minority in this world. At least the writer is making an attempt to communicate with you in your language. I will now get down off my soapbox, but I have been wanting to say this for some time now. And yes, I speak English as a native tongue, (though I am sure the readers in the UK would beg to differ with that statement).
Member since:2006-03-17
Fans: 3
I agree. This was a good article, and as far as I saw there were only one or two grammatical mistakes. When you're writing technical articles, most intelligent people will see past the typos - the ignorant ones will get stuck on petty details. President Bush can't even pronouce most words properly, should we hang people who can't spell? And for that matter, do Americans actually speak English? Its been butchered so bad, I doubt its proper to insult Britian "wit aor wustirn akzent".
Back to the article, I agree with just about everything written. I do (just for bias's sake) prefer the microkernel design simply because I've had very pleasant experiences with those systems (BeOS, Amiga, QNX) and for their time and place they performed quite responsively (moreso than any flavor of Linux I've used to date) and while they could (and did) crash, it was most often the result of trying to do something awful to the system.
But as the author pointed out, this is mostly irrelevant - software is software. APIs get broken and whether the changes are made in smaller modules or not, change happens all the time - so the weakness of the microkernel is that significant changes weave their way through the whole system. And in cases like the three OS's I mentioned above - the resources simply weren't there (QNX may be the exception) to rewrite all the affected parts of the system (BeOS's BONE network kit comes to mind).
Member since:2005-07-06
Fans: 1
-BeOS is considered an hybrid kernel not microkernel, but I agree that it's responsiveness was good.
-QNX is a microkernel, I don't remember it's responsiveness: it didn't have enough application when I tried it.
-AmigaOS didn't have memory protection if memory serves, that's a fundamental flaw which makes any performance/responsivness measure irrelevant IMHO.
That said, DragonFly has been somewhat inspired by AmigaOS, but I would be very surprised if application ported to it will be more responsive on DragonFly.
Member since:2006-03-17
Fans: 3
True, I've heard the BeOS-is-a-hybrid comment before - and that's probably accurate. I would debate that it's hard to specifically define what is the exact size and nature of an 'authentic' microkernel - but that's not really constructive. Of the very few muKs out there, in my gut I feel Be still qualifies - as it was one of Be Inc.'s major marketing buzzwords (but I know marketing's not worth much).
As for 'responsiveness', I'm not sure if you're referring to raw speed or interface performance (responsive has many meanings in computer terms). I've not used (or heard of) DragonFly, I'll give that one a googling - but my use of 'responsive' is mostly in terms of the interface.
ie: When you click or type, does something happen?
The application isn't as liable for this as the underlying OS is, in the case of Be - you almost (almost is key) never have a system lockup caused by one thread/app gobbling up time. I've experienced it once in the case of 'Cortex' - some silly media controller - and it was probably because I did something radically dumb that may have caused a hardware issue. I've used QNX's live desktop disc (seems to not be available anymore) but it was almost as responsive - much more so than XP or Lin/*nix. The scheduling nature of QNX is quite odd, but like a good muK it responded rapidly to user input (from the GUI/input perspective). I'm sure there is a significant performance penalty in swapping between kernel/user spaces, but in the world of Ghz machines this isn't really life-threatening.
I didn't know Amiga didn't have memory protection, that's sad. It was probably sacrificed for performance. I do believe the latest AROS does, I've never used it but it's good to see a 'dead' OS walking.... maybe a 'zombie'?
Member since:2006-04-24
Fans: 0
I didn't know Amiga didn't have memory protection, that's sad. It was probably sacrificed for performance.
Ever heard of a memory protected OS on 68000 CPU? So I thought.
However, the reason it wasn't added later when MMU-enabled 68k CPUs (68030 & onwards) became available was that Commodore had already stepped down the development efforts considerably. And I think it would have needed quite a radical re-architecturing to boot.
Member since:2005-07-06
Fans: 0
I didn't know Amiga didn't have memory protection, that's sad. It was probably sacrificed for performance.
I'm not sure about memory protection, but a lot of things in the AmigaOS were sacrificed for deadlines. Originally, a different operating system was in the works -- I definitely recall that it would implement resource tracking -- but CAOS (Commodore Amiga Operating System) fell so far behind that MetaComCo was called in to port TripOS, an OS written in BCPL.
http://www.amigau.com/aig/caos.html
http://www.thule.no/haynie/caos.html
(Second article suggests there was some memory management.)
Member since:
2006-03-13
Fans: 0
I think "u" looks more like the Greek symbol, so that's what I use when indicating microseconds or whatever.
I have no problem with other people using crash-proof operating systems, but when I'm programming at home, I like having available such instructions as CLI and STI for enabling or disabling interrupts in user programs. I also like being able to access my parallel port directly. In professional environments, fancy operating systems with security and protection are appropriate, but I think hobbiests programmers at home might prefer full access to their computers. That's why I've written LoseThos, a multitasking operating system with everything running in kernel mode. For a typical computer game on a home computer, the whole machine is available.
I get tired of people suggesting one-size fits all and applying rules for professional computing at home.
Member since:2005-07-21
Fans: 0
Member since:
2005-11-18
Fans: 0
I'm going to actually talk about the content of the article and not the grammer 
First off, the author doesn't really say anything in the article beyond a few thoughts. Non of which are really developed with examples.
I think the big problem with heavily abstracted micro kernels is that they're easy to create early on, but they don't evolve easily. There always seems to be some point down the line with development where you realize, oops I didn't think about this. And then you have to fiddle with a whole chain of modules and whatnot to pass info from module A to module Q and back again. Making such wholesale changes is somewhat easier in a macrokernel since you don't have as many abstracted data passing structures to mess with. Abstraction can sometimes = obfuscation. With microkernels, once you get it working you're job STILL isn't done, because the thing will probably be dog slow and you'll need to then rearrange stuff so it's faster.
Obviously, working, good microkernels can and have been done. I just think macrokernels have a real development time advantage.
All that being said, I think Linus should think about spinning off some of the driver parts into userspace. Say USB for example. If all the USB drivers were maintained outside the kernel with several entry points being made available to the USB subsystem. I think it would allow USB to move more quickly and save Linus the hassle of working with all those little changes. I bet there are complicating factors for this. Anyone know what they are?
Member since:2006-03-17
Fans: 3
Mostly, I agree; except for the 'dog slow' issue.
The stability of the overall system (to me) is more important than snagging every last possible compute cycle out of the processor. Considering that a system crash (related to the kernel) will result in a need to reboot, I'd rather sacrifice a clock or two instead...
And having mentioned rebooting, I do think this is one spot where microkernels have traditionally held the advantage (except for maybe DOS) in boot/reboot downtime. From the muKs I've mucked with, boot-time is snappy as heck - probably because the kernel isn't concerned with destroying itself as much as a macrokernel is. During the boot sequence, the structure of a large(er) kernel (I'm using Linux as an example here) relies on time-expensive checking of its loading resources and cycling one-step-at-a-time through all the initilization. muKs, on the other hand, generally seem to have a leaner and more cost-effective management of starting processes and services. Since the kernel itself (in a micro) doesn't have all of the dangerous extra modules, it can just keep doing what it does - and worry less about verifying its integrity.
But since I don't code kernel stuff and I'm just a long-time programmer, this may not actually be the case; it's just the 'vibe' I get from the PC...
Member since:
2005-07-06
Fans: 4
The ability to migrate processes also reduces the need for hot patching a running OS. OpenVZ and Xen can both migrate processes over a network with millisecond level disruptions in process response time. Migrate the processes off the box, install a new kernel and reboot. To me that is safer that trying to suspend everything using a device, hot patch and restart the device, and then resume use of it. I'm always afraid the microcode on the device will get messed up.
Any system trying to achieve 100% up-time should have the redundant resources needed to allow the migrations.
PS, my belief is that TLB thrashing dooms muK's from the start,
Member since:2005-07-06
Fans: 1
Member since:2005-07-06
Fans: 4
What kind of CPU is L4 running on, does it have TLBs? Microcontroller class CPUs don't have them.
Add up the overhead, one of the the most expensive things a CPU can do is mess with the TLB. Linux maps the kernel using minimal TLB entries. With a muK OS every little driver and sub-system is going to need one or more TLB entries since they each get their own address space. Now the OS is using a lot of TLB entries, this pushes out the user space ones. Now things start to thrash.
Linux is actually faster when compiled -Os than with all of the gcc 'speed' optimizations. The speed optimizations make the code larger. Larger code takes more TLB entries. Thrashing the TLB entries is so inefficient that it more than offsets the gains from the gcc speed optimizations. So it is better to make the kernel as small as possible and minimize TLB usage.
Related to this is why Linux tries to keep a copy of itself in the process' address space. Check the top 1G of a process on a normal x86 box, there is a copy of the kernel up there.
Member since:2005-07-06
Fans: 1
> What kind of CPU is L4 running on, does it have TLBs? Microcontroller class CPUs don't have them.
*Sigh* too lazy to google?
L4 is a research muK which runs on x86, Alpha, etc..
And I remember research paper showing that it did have very good performances.
Unless you can show otherwise ie for example show that their research paper is no good, your theoretical reasons why muK can't perform are just hot air.
Member since:2005-07-06
Fans: 4
I checked my "hot air" in Google for a couple of hits and found this in a presentation.
Microkernel: Con
Performance
Requires more context switches
Each "system call" must switch to the kernel and then to another user level process
Context switches are expensive
State must be saved and restored
TLB is flushed
Google on "l4 tlb" and you'll get 137,000 hits. Most of them are trying to deal with the TLB problem.
Member since:2005-07-06
Fans: 0
Member since:2005-07-06
Fans: 4
Member since:2005-07-06
Fans: 0
Member since:2005-07-06
Fans: 4
so in theory, if things go bad, one can always have the kernel "reboot" itself without rebooting the hardware?
that is, as long as its a software failure?
The purpose of the feature is to allow security updates on high availability systems.
If things have gone bad enough to take down the kernel, the processes are likely corrupt too. Most memory corruption errors start scattering writes at random into memory. It may take thousands of corrupt writes before hitting something critical so by the time you detect it a lot of damage has been done.
Member since:2005-07-08
Fans: 4
so in theory, if things go bad, one can allways have the kernel "reboot" itself without rebooting the hardware?
<a href="http://www-128.ibm.com/developerworks/linux/library/l-kexec.html"&g...
In fact, Linux is using that (rebooting the kernel automatically when it oopses) to implement a memory dump facility: Reboot to a "know safe" zone of memory, and save the memory to a file, ie: the kernel dump
Member since:2005-11-16
Fans: 2
PS, my belief is that TLB thrashing dooms muK's from the start,
This depends on the kernel design and some other factors.
For example, on 32 bit 80x86 (AFAIK) L4 uses segmentation to pack several processes into the same address space so that it can switch between these processes without any TLB flushing.
There are other techniques - like using buffered IPC, where messages are put into the receiver's message queue and no address space switch is done as part of sending the message (it's done later, when the scheduler decides the task has had enough CPU time anyway).
Member since:
2005-08-10
Fans: 0
What author saying is muk does not simplify kernel design, and is less efficient than monolithic kernel etc.
1st point is simply not true. In monolithic kernels, the traditional way to support SMP is a big-f--king-lock. This means only 1 CPU at a time can be in kernel mode, and of cause this is highly inefficient. Modern linux kernel implements complex locking and synchronization mechanism to ensure multiple kernel pathways can run in parallel on multiple CPUs. To make kernel reentrant things can order of magnitude more complex and still it is very hard to eliminate all deadlocks and race conditions.
On microkernel's, SMP is supported naturally. Locking and reentrance are none issue as most functions are scheduled in userspace. There are no needs to preempt kernel to meet real time constraint as minimal amount of time is spent in kernel mode anyway.
2nd point is true to some extent. Context switching is the main cause of inefficiencies in muk. However, 1) L4 has shown that well designed microkernel can be 98% as efficient as monolithic kernel on single cpu system. 2) World is moving towards multicore/SMP. One of the core can always be in kernel mode, thus eliminating those extra context switches in compare with single cpu mode.
IMO muk/hybrid muk is the way for the multicore future, though I am not a hardcore muk zealot that believe everything including memory management and scheduler should be push into userspace 
Member since:2005-07-06
Fans: 1
I don't know about your first point: to get good performance you need to use correctly the parallelism, that's is to say: put related elements on the same CPU, otherwise inter-CPU communication will kill you.
So scheduling could become an issue, are these theoretical arguments of why muK are better than monolithic kernel at SMP backed by figures?
Member since:2005-07-08
Fans: 4
1st point is simply not true. In monolithic kernels, the traditional way to support SMP is a big-f--king-lock
What makes you think that?
What you call "traditional way to support SMP in monolithic kernels is the method that most of monolithic kernels have used to evolve from a UP, nonreentrant model kernel to a SMP, reentrant one. Most of the monolithic kernels we're using today were UP one day, then they ere evolved. The big kernel lock is a just a method to make such kernels evolve. There's no reason why you can't write a monolithic kernel from scratch optimized for SMP, with no "big kernel lock"
On microkernel's, SMP is supported naturally. Locking and reentrance are none issue as most functions are scheduled in userspace
Sorry but this is just plain wrong. In order to make microkernels perform well, server processes need to be multithreaded and then they get just as hairy as monolhitic kernels. Things don't perform well in SMP by default, no matter what kernel model you use.
Take for example the filesystem process. A process tries to read a file, so it asks for data to the filesystem process. Unless the filesystem process is multithreaded, other processes asking for data to that same filesystem process will have to wait (ie: a "big kernel lock")
Microkernels are not going to scale to multicore CPUs magically. We're facing that same problem with the rest of userspace programs, and microkernels can avoid it magically? Duh. The reality here is that most of microkernels are not optimized heavily for SMP, but linux is...
Edited 2006-04-24 19:29
Member since:2005-07-06
Fans: 4
Member since:2005-08-10
Fans: 0
""What you call "traditional way to support SMP in monolithic kernels is the method that most of monolithic kernels have used to evolve from a UP, nonreentrant model kernel to a SMP, reentrant one.""
Exactly, and I did say modern monolithic kernel are fine grained and didn't suffer from this.
""Most of the monolithic kernels we're using today were UP one day, then they ere evolved. The big kernel lock is a just a method to make such kernels evolve. There's no reason why you can't write a monolithic kernel from scratch optimized for SMP, with no "big kernel lock"""
Sure one can optimize a monolithic kernel from scratch. Problem is relative complexity. To make monolithic kernel fine grained, a lot of locks and check points are necessary. Reentrance and kernel preemption just make the complexity worse.
""Sorry but this is just plain wrong. In order to make microkernels perform well, server processes need to be multithreaded and then they get just as hairy as monolhitic kernels. Things don't perform well in SMP by default, no matter what kernel model you use.""
Scheduling in userspace is still easier even it is multithreaded/multitasked.
1)kernel save all states when doing context switches, and can provides mechanism for atomicity.
2)Kernel can reorder all those tasks and make sure they execute in right order
3)Messages can be order as well.
4)Explicit share memory or IPC are required for those userspace tasks to talk, those accidental corruption of kernel data by reentrance/preemption cannot happens.
Of cause, signaling and synchronization are still needed in userspace. But atomicity, guaranteed /execution message ordering make writing those task servers can be far simpler in muk environment.
In comparison, monolithic kernel k_threads and tasklets have to be fully aware of all hazards cause by parallelism, making kernel development far more complex than muk.
""Microkernels are not going to scale to multicore CPUs magically. We're facing that same problem with the rest of userspace programs, and microkernels can avoid it magically? Duh. The reality here is that most of microkernels are not optimized heavily for SMP, but linux is...""
Sigh. Monolithic kernel is popular and well understood, this is not surprising that a lot of human effort are put into them to make SMP happens. This doesn't mean they are easier/better from design point of view. OpenBSD is still suffering from big-O-lock, while FreeBSD and Linux are only getting fine grained in pass 2 years, these tell you all.
Few people understanding muk and even fewer implements it correctly. Only microkernel that are heavily used these days are aimed at niche market like embedded or multimedia (e.g. QNX, BeOS), and none of them are focused on smp throughput.
Thus does the current situation implies monolithic is better than muk in smp by design? No.
Member since:
2006-03-29
Fans: 0
Member since:
2005-08-10
Fans: 0
In monolithic kernel, there are some "mini-me"s (think austin powers) call kernel threads and interput handles. they can be scheduled more or less independently on different cores in parallel. all those mini-mes share address space with the mother kernel. when current execution are disrupted by interputs/schedule-time-out etc, mini-mes can left share data in a inconsistent state. So complex locking mechanism are written to make sure this will never happen. typical kernel can have dozen of mini-mes running, and you can get the picture how quickly these multibody interactions get complicated.
"So scheduling could become an issue, are these theoretical arguments of why muK are better than monolithic kernel at SMP backed by figures?"
You are misunderstanding my point. Current Linux and FreeBSD does not suffer from big-lock inefficiencies. They have complex mechanism to make kernel code running parallel on all cores. Problem is design complexity now.
Member since:
2006-01-31
Fans: 0
In the most recent article by Robert Cringely (http://www.pbs.org/cringely/pulpit/pulpit20060420.html) he states that Apple will be getting a new kernel. More precisely, he states that it would be a monolithic kernel due to speed increases in integer calculations.
What does this say about microkernels? I mean, if Apple finds this change to be in their best interest (Cringely states the microkernel is hindering the adoption of xServe), does this reflect upon all microkernels, or just Mach microkernel?
I'm not trying to start a flame war of any type, but I would think real world experience (in this case, Apple) would lend credence to the fact that microkernels still need work to compete with monolithic kernels.
Edited 2006-04-24 19:06
Member since:2005-07-06
Fans: 0
This article says nothing about microkernels and all about Cringely not having a clue:
"Quite simply, a monolithic kernel like the one used in Linux or most of the other Open Source Unix clones is inherently two to three times faster for integer calculations than the Mach microkernel presently used in OS X 10.4."
The kernel has nothing to do with the speed of integer calculations whatsoever. And if he even dared to do a bit of research about the Xserve, he'd have noticed that they're not spelled "xServe".
Member since:2006-03-14
Fans: 1
The kernel has nothing to do with the speed of integer calculations whatsoever. And if he even dared to do a bit of research about the Xserve, he'd have noticed that they're not spelled "xServe".
Granted Cringely didn't offer any proof of the kernel's involvement with integer calculations, I woldn't dismiss it right away...
Think back to the open letter posted by Mac games developer/porter Aspyr. They discussed why OpenGL/game performance is lower in Mac OSX as opposed to Windows. One key reason for game performance issues is that the OSX kernel doesn't give any one single process full CPU time. In Windows, if a rouge process gets itself stuck in an endless loop (I'm guilty of making such apps myself, oops) you'll see 100% CPU utilization and the system is unresponsive. Then it becomes an arguement of speed or stability.
So with that in mind, it's possible to say that the kernel is to blame for lower calculations in a given app.
When you read "integer calculations" you also have to consider that it might mean more than just simple add, sub, mul, div CPU instructions. If a math library was used, many complex equations might wind up in C-style functions. To use those, the process has to set up a stack frame, request memory, call the function, etc.
So unless you're writing a really tight program in assembly and you're addressing hardware directly, your compiled code and app will interface the system in some way.
Member since:2005-06-29
Fans: 19
does this reflect upon all microkernels, or just Mach microkernel?
1) Forget Cringely. We link to him and people like him (i.e. Dvorak) just for the fun of it (hey we as staff like a laugh too every now and then, we're actually real people, you know), and because the things they come up with while imitating the Oracle of Delphi are usually provocative enough to discuss. But for real arguments, forget 'm.
2) Apple's kernel is no longer a muK. It's a hybrid just like the NT kernel. Saying, 'OSX is slow, so it must be that its muK is slow' is nonsense because the kernel probably has little to do with the user experience of speed and responsiveness, and because OSX' kernel is not a muK.
If you want to get a real idea of what a muK can do, download QNX. QNX's Neutrino kernel is a true muK, not a hybrid like OSX's or NT's. And what makes QNX even more interesting, is that the windoing engine it uses, PhotonUI, is designed exactly like a muK. To understand more about QNX, read my article on it:
http://www.osnews.com/story.php?news_id=8911
It's from before I became public piss post-- err, managing editor at OSN.
And on a final note, it's quite obvious I personally don't agree with everything said in this article. However, since this article is a direct reply to one of mine, I'll leave a 'formal' response to a future article, to be fair.
/boast mode
This whole muK vs. monolithic debate on OSNews does show why OSN is so popular: unbiased news, and even articles which are a direct contradiction to one of the main editor's views are publicised. I don't think many editors of other sites can say the same.
/end boast mode
Member since:
2005-07-06
Fans: 0
"CPUs are fast these days, performance is not a critical factor" myth. Imagine a process which takes X cycles to do something and another which takes Y=X+1. The faster a given CPU executes that process, the more cycles you're losing with Y.
Not correct. If process X takes 200 cycles and process Y takes 250 to do the same stuff then process Y does not magically take MORE than 250 cycles on a faster CPU. The only way you waste more cycles is if you use a faster CPU to execute process Y more times (but this was not stated) and then you still have gained something. A faster CPU makes a process execute in faster time (unless the execution depends on other factors like slow memory etc and then lower latency can still help so that a process Y does not loose as much time sitting idle waiting for the memory reads/writes to complete) which is the complete opposite of your argumentation
A fast CPU doesn't help to execute slow things faster, it could even help to make slow things even slower in some cases.
Not sure what you are smoking here (no offence) but this is not correct.
A microkernel can protect you against a software bug, but there're hardware bugs that software can't fix in any reasonable way, except by working around them.
All the more reasons to use a microkernel on buggy hardware or when dealing with buggy drivers. If they run in userspace they can not bring down the kernel. Mikrokernels are not immune but a damn lot more robust towards both buggy hardware and buggy drivers. This is one of the biggest advantages of myK and one of the stronger arguments against monoK. Again as always the hybrids try to strike a balance where the more performance sensitive subsystems like storage IO etc are running in kernel mode and other drivers run in user space. On Vista for instance, the sound drivers are going to be running in userspace compared to XP (which will probably yield better latency performance for audio apps also due to not having the sound mixer etc context switching into kernel mode)
Edited 2006-04-24 22:14
Member since:2005-07-08
Fans: 4
Not correct. If process X takes 200 cycles and process Y takes 250 to do the same stuff then process Y does not magically take MORE than 250 cycles on a faster CPU
I never said it does.
What I say is that you buy a CPU which is ej: 200x faster (just a number to make calculations easier), X takes one cycle and Y takes more than one cycle, 1 + 1/4 in fact.
Now a better cpu comes, 400x faster. Surprise, X takes 2 cycles to run, Y takes... 2 + 1/4. Except that the "1/4" no means 100 cycles and keeps growing as the CPU gets faster.
And that's what I wanted to prove: saying "fast cpus make microkernels more feasible" doesn't fix the problem. Sure, the microkernel will run faster. The problem is that the monolithic kernel will continue being even faster
On Vista for instance, the sound drivers are going to be running in userspace compared to XP
Not at all. Drivers will keep running in kernel space. It's the "sound core" (sound mixing etc, lots of crap that they never should have put in the kernel) what they're moving to userspace - I don't understand why people keeps spreading those false rumours about vista's sound subsystem. They're doing what linux does: Keep the core driver in the kernel, the rest of the stuff in userspace. Windows had too much crap in kernel, they're just fixing it.
Member since:2005-07-06
Fans: 0
I never said it does...
Now a better cpu comes, 400x faster. Surprise, X takes 2 cycles to run, Y takes... 2 + 1/4. Except that the "1/4" no means 100 cycles and keeps growing as the CPU gets faster.
No you just said it again unless you have your own very specific defenition of what a cycle means in terms of CPUs.
Just to clarify. Cycle => power cycle or "tick", measured in hz. A faster processor completes more cycles per timeunit (seconds). Processes usually (unless they depend on "outside" factors) takes a specified number of instructions to complete. Your process just doubled up on the amount of work required to complete on a twice as fast CPU. How is that? And what "magic" is that automatically makes the same process blow up like that. Please explain your logic because to most of us it sure does not make any sense.
Member since:
2006-04-21
Fans: 0
During the 20th century CPUs were busy doing calculation and I/O. DMA became the norm to minimize the impact of I/O and caching was added to address the poor main memory performance. Memory protection became mainstream and multiprocessor designs were added. All this was designed with monolithic kernels in mind. Enough history :-)
My point is that talking about the performance of microkernels is not totally fair. Now, I'm not convinced that microkernels is the right way to go, but the discussion should be about wether the microkernel design is good. Performance wise I think it already has proved itself on todays hardware to some extend.
Example: The TLB issue is always mentioned in these discussions and it's a good example of how the CPU design matters. On x86 the way to deal with context switches has been to flush it. This gives an advantages to monolithic kernels. A tagged TLB (This is part of the virtual machine extentions to x86) solves this, given that monolithic and microkernels have an equal sized working set (please tell me if you know).
Times are changing. Virtualization is one of these changes and it has a lot in common with microkernels. Another is the amount of I/O. Today networking bandwidth has come very close to main memory bandwidth and this creates problems for the monolithic design (also for others). Memory copying has become an overhead while it is still the fastest way to move data between protection boundaries. There are many discussions about this on LKML: "If we could just move this page to another address space we could avoid copying and then we will become heroes"... "don't do it! It's slow". The Singularity project has gone back to the days of software based protection to avoid the MMU all together.
The Linux FUSE project is a prof that microkernels has something good. If not for performance then at least for functionality.
To sum it up. A lot has happend and we really should try to be open to new ideas and not just be monolithic in our thinking. These are exciting times...
Member since:2006-02-15
Fans: 9
Well,
The 20th century saw a lot of system architecturs, and wasn't until the PC commodity production that cache based systems came to dominate.
The Cray 2, for example, could move a 64-bit (8 byte) memory word every cycle on a machine with a 2.5ns clock, in 1985, with no caches. *per processor*, and it had four. that's 8 gB / second. You may have access to a 64 gbit/sec network, but I sure don't, and that's a 20 year old machine.
Virtualization, especially at the hardware level, isn't particularly new, IBM introduced it on the 360/370 architecture in 1972, and a lot of machines have had it over the years. What is new is that it has come to commodity hardware, and the commodity folk are reinventing the state of the art.
There were machines designed specifically to support microkernels. Mach, after all, comes out of the same research program as CM* and accent.
In the end, the current VM model won for no other reason than the sheer weight of popularity.
[edit: fixed mbit->gbit typo]
Edited 2006-04-24 23:13