CS/DS/SS/ES are from the 16-bit time. (and btw, they were a bad idea then, so doing something like that again is bad now too). When processors were 16-bit, they had a lot less memory than they have now. Today, those couple of registers are not going to be enough.
Did you notice that for each definable segment, there is a separate register? That is because only registers are fast enough.
Adding stack (memory!) operations to each function call slows down things a lot too.
"while at the same time an access check is performed"
What you're missing is that calls are all over the code, at many different addresses, so to do an 'access check' requires an add an a subtract for each possible active segment. That is a lot of operations.
Seems to me that everything you're talking about is best done completely in software.
"The point of the microkernel is that it compartmentalizes each driver and the kernel into their own address spaces with strictly enforced boundaries."
I don't think you read what Linus posted.
"_BUT_ at the same time on a different computer you can check the correctness of the drivers in parallel it would still take about the same time if you have as many computers as you have drivers."
Nope, because in order to know the system is correct you have to look at the system, not just the parts. Not each perfectly fine (correct) tire will work on each perfectly fine (correct) car, even when they both use a perfectly fine (correct) mounting mechanism to communicate with each other.
You're just theoretically thinking that it's better because you've found a paradigm that lets you ignore the important things. That's what a microkernel does, it makes you think you're doing it right.
"Perhaps they are putting distinctive scent markers in the packaging?"
Since they are trying to find counterfeit DVD's, wouldn't they first need to find the counterfeit DVD's before they could add "distinctive scent markers in the packaging".
"If a 32-bit address falls within the current segment, then the instruction is executed, otherwise a new segment is loaded from the address and a security check is performed."
checking "falls within" for each memory access? That is not a simple operation in hardware. The data structures for the segments are also likely to be pretty large.
That would take quite a lot of registers and logic to make that run at 3GHz (cache doesn't run that fast, so all data would have to be in registers). Be prepared to have to accept significantly higher power consumption and prices for processors that do that.
"The point is, proving correctness is possible in a microkernel, but next to impossible in a large monolithic kernel. It's a problem that increases exponentially, not linearly, with the amount of code you have to analyze."
So yes, you can prove correctness of the kernel after you take lots of functionality out of it to make it a 'microkernel'.
But if you wish to prove correctness of your OS including the functionality that you took out of the kernel, you still have to prove correctness of the complete system including the lines of code now 'outside' of the kernel. And since you still have a lot complex interactions between those in and out-kernel parts, your effort for proving of correctness still grows exponentially including the lines of code now outside of the kernel. Inside or outside of the kernel does not make its interactions simpler. Actually, crossing the kernel boundary more often makes its interactions more complex, ergo more difficult to prove. Did you read Linus' post? He is pretty clear about that.
"Every function added to a monolithic kernel could possibly alter the behavior of every other function, because they all share the same address space. This is not true of a microkernel."
You really didn't read what Linus wrote, did you? Hint: 'access space'.
"because some idiot wrote if(a=1) instead of if(a==1)"
btw, gcc outputs a compiler warning on that first if(), ergo the driver is actually 'proven incorrect' and even though 'proven correct' is so important to you, you still choose to use it?
The 'proven correct' argument about microkernels is only of theoretical use.
Building the habit of typing the constants to the left prevents a lot of those problems too.
"You don't have to prove it, as long as the microkernel will be able to put the system into a predetermined state,"
Ok, so: A filesystem driver bug corrupts all data on disk. Try putting the system in a predetermined state other than 'useless'.
Or: In the middle of talking with the UPS, the OS decides it needs to reload the serial port driver. Due to that reload, the signals output on the serial port, to the UPS are like morse code for 'turn yourself off'... How did that 'proven microkernel' prove stability of your system there?
There are a billion fault cases like that that are simply ignored by the 'microkernel people'. Microkernels don't solve those, they just make it easier to ignore them and pretend they don't exist.
"the ability to prove (even mathematically) that the kernel is correct. " "That is why critical real-time OSes are often based on a microkernel which is only about 4000-8000 lines of code. Even at that size is might take years to prove it does what it is supposed to do."
That doesn't help you. What you're saying is: strip off all drivers from the kernel, so you can prove the kernel is correct.
So what if a filesystem driver corrupts the data when the microkernel schedules it in a certain way compared to the block device driver and the swap/pager? You still have to prove all the driver, and you still have the same complicated real-life the driverkernel interactions as without a microkernel.
"critical real-time OSes" make things more reliable by not allowing the system to do many complex (and therefore potentially dangerous) things in parallel. Single tasks running in sequence, programmed to execute with guaranteed run-times can be extremely predictable (thus reliable). That can reduce the number of fault cases, but it's not guaranteed that allowing the complexs situations to occur adds fault cases (that is a likely possibility, but not a guarantee), but what is guaranteed is that the microkernel approach takes away performance.
"Today hardware is lot faster (roughtly Moore's law), so context switches will be alright on a 3GHz Pentium IV machines while it would not be doable on a 33Mhz machines."
You're assuming a certain load. Yes, if you use the 3GHz P4 to control the rudder sticks, then the context switch doesn't matter, but there are many loads that you can use that 3GHz P4 for where context switches do matter.
"Theoretically you are right. But in practice Linux 2.6 is 6 million lines of code and a typical microkernel is less than 10k."
Those 6M lines include all drivers. Add drivers to your microkernel and you'll end up around the same number of lines if not more. And if you need the drivers to work for the system to work, you'll have to prove their correctness too, all 6M lines of them. The microkernel is not going to fix that broken 'serial port' driver unless you've proven that stopping and reloading the 'serial port' driver at any possible time is correct (and likely, if the 'serial port' is connected to the rudder servo/motor, even 'just' reloading the driver may get you in serious trouble if it happens at the wrong time. And if you don't want the filesystem to corrupt the data because of a bug, a 'proven correct' kernel without also proving the filesystem driver is not going to guarantee you anything on that front besides misplaced, false hope.
"Besides, as Linus pointed out, when data is going one way microkernels are easy. And in the case of file systems that is really the case. Sure multiple processes can access it at once, but the time scale on handling the incoming signals is extremely fast compared to waiting for data from disk."
You're forgetting what happens on SMP and multicore systems: multiple processes will be accessing the filesystem at exactly the same time. And the filesystem in its turn will be accessing the block devices, and there will be multiple filesystems on each block device. Plus, the block device will be accesses by the pager/swap.
"make sure you get credit" "I don't know how you'd go about this, to be honest."
How about this: Publish everything that you would eventually publish right away, but encrypt it (encrypt it well (!!) with well-generated large keys). Make sure it's noticed/logged with the date that you published it right then and there.
Then, if/when the time comes to make it public, publish the decryption key.
IANAL, but I'd say that technically, that would be a good way to prove to people at what time you had certain knowledge, and actually disclose it only when or if needed.
"How do you get from there to criminal prosecution for pointing out security flaws?"
When I see an open door anywhere that I think should be closed, and get the urge to say "Hey, shouldn't that door be closed?", should I now worry and try not to say that?
Or is it now a crime to say to somebody "You forgot to lock your car sir!"?
"You are making two incorrect assumptions. First you assume that operating systems with no buggy drivers are a realistic expectation - they aren't."
I'm not expecting drivers with no bugs.
My 'assumption' is not what you call an 'expectation' but my experience.
It is realistic to expect that certain drivers are rock-solid in a monolythic kernel, meaning: they never cause any crashes or downtime during the lifetime of the hardware. Many drivers in Linux are like that.
It would be foolish to slow those drivers down, and a microkernel slows everything down, including those drivers.
That is what is a bad idea about a microkernel, it's not discriminatory.
"it allows a stupid mistake to result in an exception that can be handled (and easily logged & debugged) rather than a hard crash."
In real life that means that the logfiles will mostly be ignored and you'll end-up with a system with buggy drivers that sorta seems to work, but a bit slower and sometimes it's busy reloading stuff.
Sounds like the 'windows' approach to me. I prefer rock-solid and fast over stumbling and hickups.
"I am not sure why 6-16% overhead (or for that matter 50% overhead) is an issue when the system is idle. After all, 6-16% of an idle system (utilized at, say, 10% is less than 2 % of the overall system capacity)."
It matters because the overhead doesn't happen during idle cycles (there is nothing to do during idle cycles, let alone something that can be slowed down by the kernel), it only happens during activity...
"The only case where you would pay the full penalty of a microkernel is when you are bottlenceked on the CPU or when you are bottlnecked on the bus which is quite rare."
If the bus bottleneck rarely occurred, there wouldn't be a push for faster FSB from Intel and faster HTT and memory interfaces, would there?
"I might be so bold to suggest that the cases where windows has higher performance than Linux are greater than where Linux has higher performance than a Micrkernel. So, by your logic, from a performance standpoint, Windows might be the best choice."
That is your statement (about windows being faster than Linux) and your logic, not mine.
"when one phase is discharging, the nearby wire is charging at the same rate, which reduces the total losses."
Aha. That makes it clear. That probably will work to save a lot of power. Neat. I hope many chipmanufacturers (AMD, Xilinx, etc) will be able to successfully use it.
"But there are those of us, like myself, who are perfectly content at 50MPH anyway, so we wouldn't miss the extra speed. But we would like the extra peace of mind that comes from a more robust design."
You think this is insurance? It more resembles racketeering: You're perfectly welcome to switch to Tanenbaum's nonexistent slower microkernel that supposedly will crash less than Linux...
"I guess ideally Linux could come with a configuration option that lets the user specify whether to run drivers in user space or kernel space, then the people who need more efficiency can have it, and the people who want more robustness can have that."
Now, on a per driver basis, that is a feature I would applaud. I'd be interested to learn how exacly that would be done without too many driver modifications too...
As far as microkernels to make systems more reliable or secure, I'll put that in the 'buying extended warranty from the retail shop' category: In most cases not worth the cost.
Looks interesting. I wonder what they mean with 'taps', and if they calculated their power savings right (would each register need its own tap, or if not, is the buffer needed to boost the power from the loop included in the clock system power?)
"For your case, it sounds like performance is more important than security."
I'm actually convinced that microkernels won't give any additional security, nor reliability (unless you have hardware that has flaky drivers that can 'fix' themselves by being restarted/reloaded and which go either out of bounds, or for which rmmod/insmod doesn't work... but in that case the real solution is to fix the driver or ditch the hardware, not a microkernel).
"Correct is absolutely more important than fast in this case."
'Correct' is not what a microkernel does, the reason why people like them is because they think it will help protect against 'incorrect' in drivers.
A microkernel-based OS will end up littered with buggy drivers that nobody cares to fix, so a microkernel-based OS will have a lot of 'incorrect' in there.
A microkernel's usefullness is similar to that of a 'virusscanner'. It's not the cure, it only treats symptoms, and it does so badly and costly.
"But if I had the choice of sacrificing 6-14% and getting in return an OS that never crashes, even in the presence of some buggy drivers, then sure, I would do it."
Never crashes doesn't exist. Mainboards burning out (remember the incomplete stolen capacitoy formula), harddisks dying if you don't have Raid, Power outages, and overheating if the AC is turned off will not be prevented by microkernels. Besides that, a server that 'runs fine' except that the network card drivers or scsi/ata drivers are not loaded is still completely off-line.
"As I understand it, "moving (potentially) flaky drivers to userspace" is what microkernels are all about."
My point is that, if a driver is found flaky, that may be the only option besides dropping the hardware, but a _lot_ (most) of the drivers in Linux are rock solid, and slowing them down by putting the whole system under a microkernel is the same thing as giving every car a speed limiter at 50MPH in case its driver may cause an accident while speeding.
On desktops, the problem is that the microkernel overhead doesn't take the 6-14% when it's idle, it takes the 6-14% when you're waiting for the program to respond to your input.
On servers it's not unusual to find the disk utilization ('iostat') at 100%. Granted, this is not CPU but spindle activity, but the microkernel makes each I/O slower, and I/O is exactly what is keeping the system 100% busy. I want the job that causes the load to finish as fast as possible, so why let a microkernel waste time there?
On embedded systems, the CPU itself is much heavier loaded. Continously above 75% is not abnormal in our embedded systems (if it were less, then we would switch to a slower, more power efficient version of the cpu).
So no, I don't have 6-14% to spare. That doesn't mean that _you_ can't use a microkernel, but it's not the right thing for me to throw away valuable cycles in return for nothing. None of the fault cases I encounter on the desktop, server, or embedded systems would be solved with a microkernel, and the 'security' it supposedly gives is only a feeling of security and really nothing that security levels (or selinux) doesn't already give you.
"Sure... but having a computer that crashes reduces the value much more quickly. "
Is Linux that unstable for you that you would trade in 6-14% of its speed for something that (when Tanenbaum finally actually makes it), in my prediction, will crash just as often (or more)?
If hardware dies and it locks-up the PCI-bus, no microkernel is going to save you.
If a driver is flakey, it should be fixed or moved to userspace. Putting everything below a microkernel isn't going to give you anything better than that.
Slashdot Mirror
CS/DS/SS/ES are from the 16-bit time. (and btw, they were a bad idea then, so doing something like that again is bad now too). When processors were 16-bit, they had a lot less memory than they have now. Today, those couple of registers are not going to be enough.
Did you notice that for each definable segment, there is a separate register? That is because only registers are fast enough.
Adding stack (memory!) operations to each function call slows down things a lot too.
"while at the same time an access check is performed"
What you're missing is that calls are all over the code, at many different addresses, so to do an 'access check' requires an add an a subtract for each possible active segment. That is a lot of operations.
Seems to me that everything you're talking about is best done completely in software.
"The point of the microkernel is that it compartmentalizes each driver and the kernel into their own address spaces with strictly enforced boundaries."
I don't think you read what Linus posted.
"_BUT_ at the same time on a different computer you can check the correctness of the drivers in parallel it would still take about the same time if you have as many computers as you have drivers."
Nope, because in order to know the system is correct you have to look at the system, not just the parts. Not each perfectly fine (correct) tire will work on each perfectly fine (correct) car, even when they both use a perfectly fine (correct) mounting mechanism to communicate with each other.
You're just theoretically thinking that it's better because you've found a paradigm that lets you ignore the important things. That's what a microkernel does, it makes you think you're doing it right.
"How is that for pulling it out? :-)"
;-)
Worth fifty bonus points. You made it to the next round
"Perhaps they are putting distinctive scent markers in the packaging?"
Since they are trying to find counterfeit DVD's, wouldn't they first need to find the counterfeit DVD's before they could add "distinctive scent markers in the packaging".
Chicken/egg...
"If a 32-bit address falls within the current segment, then the instruction is executed, otherwise a new segment is loaded from the address and a security check is performed."
checking "falls within" for each memory access? That is not a simple operation in hardware. The data structures for the segments are also likely to be pretty large.
That would take quite a lot of registers and logic to make that run at 3GHz (cache doesn't run that fast, so all data would have to be in registers). Be prepared to have to accept significantly higher power consumption and prices for processors that do that.
"Here, it seems, the means justify the ends. Linus basically says "I won't take any challenges"."
Nope, he is making some pretty bold statements that tell the microkernel people 'go ahead, build it and show me wrong'.
"The point is, proving correctness is possible in a microkernel, but next to impossible in a large monolithic kernel. It's a problem that increases exponentially, not linearly, with the amount of code you have to analyze."
So yes, you can prove correctness of the kernel after you take lots of functionality out of it to make it a 'microkernel'.
But if you wish to prove correctness of your OS including the functionality that you took out of the kernel, you still have to prove correctness of the complete system including the lines of code now 'outside' of the kernel. And since you still have a lot complex interactions between those in and out-kernel parts, your effort for proving of correctness still grows exponentially including the lines of code now outside of the kernel. Inside or outside of the kernel does not make its interactions simpler. Actually, crossing the kernel boundary more often makes its interactions more complex, ergo more difficult to prove. Did you read Linus' post? He is pretty clear about that.
"Every function added to a monolithic kernel could possibly alter the behavior of every other function, because they all share the same address space. This is not true of a microkernel."
You really didn't read what Linus wrote, did you? Hint: 'access space'.
"because some idiot wrote if(a=1) instead of if(a==1)"
btw, gcc outputs a compiler warning on that first if(), ergo the driver is actually 'proven incorrect' and even though 'proven correct' is so important to you, you still choose to use it?
The 'proven correct' argument about microkernels is only of theoretical use.
Building the habit of typing the constants to the left prevents a lot of those problems too.
"You don't have to prove it, as long as the microkernel will be able to put the system into a predetermined state,"
Ok, so: A filesystem driver bug corrupts all data on disk. Try putting the system in a predetermined state other than 'useless'.
Or: In the middle of talking with the UPS, the OS decides it needs to reload the serial port driver. Due to that reload, the signals output on the serial port, to the UPS are like morse code for 'turn yourself off'... How did that 'proven microkernel' prove stability of your system there?
There are a billion fault cases like that that are simply ignored by the 'microkernel people'. Microkernels don't solve those, they just make it easier to ignore them and pretend they don't exist.
"the ability to prove (even mathematically) that the kernel is correct. " "That is why critical real-time OSes are often based on a microkernel which is only about 4000-8000 lines of code. Even at that size is might take years to prove it does what it is supposed to do."
That doesn't help you. What you're saying is: strip off all drivers from the kernel, so you can prove the kernel is correct.
So what if a filesystem driver corrupts the data when the microkernel schedules it in a certain way compared to the block device driver and the swap/pager? You still have to prove all the driver, and you still have the same complicated real-life the driverkernel interactions as without a microkernel.
"critical real-time OSes" make things more reliable by not allowing the system to do many complex (and therefore potentially dangerous) things in parallel. Single tasks running in sequence, programmed to execute with guaranteed run-times can be extremely predictable (thus reliable). That can reduce the number of fault cases, but it's not guaranteed that allowing the complexs situations to occur adds fault cases (that is a likely possibility, but not a guarantee), but what is guaranteed is that the microkernel approach takes away performance.
"Today hardware is lot faster (roughtly Moore's law), so context switches will be alright on a 3GHz Pentium IV machines while it would not be doable on a 33Mhz machines."
You're assuming a certain load. Yes, if you use the 3GHz P4 to control the rudder sticks, then the context switch doesn't matter, but there are many loads that you can use that 3GHz P4 for where context switches do matter.
"Theoretically you are right. But in practice Linux 2.6 is 6 million lines of code and a typical microkernel is less than 10k."
Those 6M lines include all drivers. Add drivers to your microkernel and you'll end up around the same number of lines if not more. And if you need the drivers to work for the system to work, you'll have to prove their correctness too, all 6M lines of them. The microkernel is not going to fix that broken 'serial port' driver unless you've proven that stopping and reloading the 'serial port' driver at any possible time is correct (and likely, if the 'serial port' is connected to the rudder servo/motor, even 'just' reloading the driver may get you in serious trouble if it happens at the wrong time. And if you don't want the filesystem to corrupt the data because of a bug, a 'proven correct' kernel without also proving the filesystem driver is not going to guarantee you anything on that front besides misplaced, false hope.
You choose for that filesystem call to wait forever.
/mnt/compy2
/mnt/compy2
Try
mount -o soft compy2:/share
or
mount -o intr compy2:/share
instead
man 8 mount
"Besides, as Linus pointed out, when data is going one way microkernels are easy. And in the case of file systems that is really the case. Sure multiple processes can access it at once, but the time scale on handling the incoming signals is extremely fast compared to waiting for data from disk."
You're forgetting what happens on SMP and multicore systems: multiple processes will be accessing the filesystem at exactly the same time. And the filesystem in its turn will be accessing the block devices, and there will be multiple filesystems on each block device. Plus, the block device will be accesses by the pager/swap.
"make sure you get credit" "I don't know how you'd go about this, to be honest."
How about this: Publish everything that you would eventually publish right away, but encrypt it (encrypt it well (!!) with well-generated large keys). Make sure it's noticed/logged with the date that you published it right then and there.
Then, if/when the time comes to make it public, publish the decryption key.
IANAL, but I'd say that technically, that would be a good way to prove to people at what time you had certain knowledge, and actually disclose it only when or if needed.
"How do you get from there to criminal prosecution for pointing out security flaws?"
When I see an open door anywhere that I think should be closed, and get the urge to say "Hey, shouldn't that door be closed?", should I now worry and try not to say that?
Or is it now a crime to say to somebody "You forgot to lock your car sir!"?
"You are making two incorrect assumptions. First you assume that operating systems with no buggy drivers are a realistic expectation - they aren't."
I'm not expecting drivers with no bugs.
My 'assumption' is not what you call an 'expectation' but my experience.
It is realistic to expect that certain drivers are rock-solid in a monolythic kernel, meaning: they never cause any crashes or downtime during the lifetime of the hardware. Many drivers in Linux are like that.
It would be foolish to slow those drivers down, and a microkernel slows everything down, including those drivers.
That is what is a bad idea about a microkernel, it's not discriminatory.
"it allows a stupid mistake to result in an exception that can be handled (and easily logged & debugged) rather than a hard crash."
In real life that means that the logfiles will mostly be ignored and you'll end-up with a system with buggy drivers that sorta seems to work, but a bit slower and sometimes it's busy reloading stuff.
Sounds like the 'windows' approach to me. I prefer rock-solid and fast over stumbling and hickups.
"I am not sure why 6-16% overhead (or for that matter 50% overhead) is an issue when the system is idle. After all, 6-16% of an idle system (utilized at, say, 10% is less than 2 % of the overall system capacity)."
It matters because the overhead doesn't happen during idle cycles (there is nothing to do during idle cycles, let alone something that can be slowed down by the kernel), it only happens during activity...
"The only case where you would pay the full penalty of a microkernel is when you are bottlenceked on the CPU or when you are bottlnecked on the bus which is quite rare."
If the bus bottleneck rarely occurred, there wouldn't be a push for faster FSB from Intel and faster HTT and memory interfaces, would there?
"I might be so bold to suggest that the cases where windows has higher performance than Linux are greater than where Linux has higher performance than a Micrkernel. So, by your logic, from a performance standpoint, Windows might be the best choice."
That is your statement (about windows being faster than Linux) and your logic, not mine.
"when one phase is discharging, the nearby wire is charging at the same rate, which reduces the total losses."
Aha. That makes it clear. That probably will work to save a lot of power. Neat. I hope many chipmanufacturers (AMD, Xilinx, etc) will be able to successfully use it.
"But there are those of us, like myself, who are perfectly content at 50MPH anyway, so we wouldn't miss the extra speed. But we would like the extra peace of mind that comes from a more robust design."
You think this is insurance? It more resembles racketeering: You're perfectly welcome to switch to Tanenbaum's nonexistent slower microkernel that supposedly will crash less than Linux...
"I guess ideally Linux could come with a configuration option that lets the user specify whether to run drivers in user space or kernel space, then the people who need more efficiency can have it, and the people who want more robustness can have that."
Now, on a per driver basis, that is a feature I would applaud. I'd be interested to learn how exacly that would be done without too many driver modifications too...
As far as microkernels to make systems more reliable or secure, I'll put that in the 'buying extended warranty from the retail shop' category: In most cases not worth the cost.
Better link here
t ml?articleID=187200783
http://www.eetimes.com/news/latest/showArticle.jh
Looks interesting. I wonder what they mean with 'taps', and if they calculated their power savings right (would each register need its own tap, or if not, is the buffer needed to boost the power from the loop included in the clock system power?)
"For your case, it sounds like performance is more important than security."
I'm actually convinced that microkernels won't give any additional security, nor reliability (unless you have hardware that has flaky drivers that can 'fix' themselves by being restarted/reloaded and which go either out of bounds, or for which rmmod/insmod doesn't work... but in that case the real solution is to fix the driver or ditch the hardware, not a microkernel).
"Correct is absolutely more important than fast in this case."
'Correct' is not what a microkernel does, the reason why people like them is because they think it will help protect against 'incorrect' in drivers.
A microkernel-based OS will end up littered with buggy drivers that nobody cares to fix, so a microkernel-based OS will have a lot of 'incorrect' in there.
A microkernel's usefullness is similar to that of a 'virusscanner'. It's not the cure, it only treats symptoms, and it does so badly and costly.
"But if I had the choice of sacrificing 6-14% and getting in return an OS that never crashes, even in the presence of some buggy drivers, then sure, I would do it."
Never crashes doesn't exist. Mainboards burning out (remember the incomplete stolen capacitoy formula), harddisks dying if you don't have Raid, Power outages, and overheating if the AC is turned off will not be prevented by microkernels. Besides that, a server that 'runs fine' except that the network card drivers or scsi/ata drivers are not loaded is still completely off-line.
"As I understand it, "moving (potentially) flaky drivers to userspace" is what microkernels are all about."
My point is that, if a driver is found flaky, that may be the only option besides dropping the hardware, but a _lot_ (most) of the drivers in Linux are rock solid, and slowing them down by putting the whole system under a microkernel is the same thing as giving every car a speed limiter at 50MPH in case its driver may cause an accident while speeding.
On desktops, the problem is that the microkernel overhead doesn't take the 6-14% when it's idle, it takes the 6-14% when you're waiting for the program to respond to your input.
On servers it's not unusual to find the disk utilization ('iostat') at 100%. Granted, this is not CPU but spindle activity, but the microkernel makes each I/O slower, and I/O is exactly what is keeping the system 100% busy. I want the job that causes the load to finish as fast as possible, so why let a microkernel waste time there?
On embedded systems, the CPU itself is much heavier loaded. Continously above 75% is not abnormal in our embedded systems (if it were less, then we would switch to a slower, more power efficient version of the cpu).
So no, I don't have 6-14% to spare. That doesn't mean that _you_ can't use a microkernel, but it's not the right thing for me to throw away valuable cycles in return for nothing. None of the fault cases I encounter on the desktop, server, or embedded systems would be solved with a microkernel, and the 'security' it supposedly gives is only a feeling of security and really nothing that security levels (or selinux) doesn't already give you.
"Sure... but having a computer that crashes reduces the value much more quickly. "
Is Linux that unstable for you that you would trade in 6-14% of its speed for something that (when Tanenbaum finally actually makes it), in my prediction, will crash just as often (or more)?
If hardware dies and it locks-up the PCI-bus, no microkernel is going to save you.
If a driver is flakey, it should be fixed or moved to userspace. Putting everything below a microkernel isn't going to give you anything better than that.