OSDev.org

Hello all

I have a simple question, if a kernel is not mapped to address space of every process and kernel itself is run as daemon does it make it a MicroKernel or MonoLithic?

AFAIK, that makes it a Micro-kernel.

I may be wrong,though.

P.S: I think this is in the wrong forum.It should be under 'OS Design & Theory'.

Raven wrote:Hello all

I have a simple question, if a kernel is not mapped to address space of every process and kernel itself is run as daemon does it make it a MicroKernel or MonoLithic?

According to Andrew Tanenbaum a kernel is only micro if it has it's filesystem running in userspace... but that's not the only criterion, so I'm not sure.

I can't resist saying a few words about microkernels. A microkernel is a very small kernel. If the file system runs inside the kernel, it is NOT a microkernel. The microkernel should handle low-level process management, scheduling, interprocess communication, interrupt handling, and the basics of memory management and little else. The core microkernel of MINIX 1.0 was under 1400 lines of C and assembler. To that you have to add the headers and device drivers, but the totality of everything that ran in kernel mode was under 5000 lines. Microsoft claimed that Windows NT 3.51 was a microkernel. It wasn't. It wasn't even close. Even they dropped the claim with NT 4.0. Some microkernels have been quite successful, such as QNX and L4. I can't for the life of me see why people object to the 20% performance hit a microkernel might give you when they program in languages like Java and Perl where you often get a factor 20x performance hit. What's the big deal about turning a 3.0 GHz PC into a 2.4 GHz PC due to a microkernel? Surely you once bought a machine appreciably slower than 2.4 GHz and were very happy with it. I would easily give up 20% in performance for a system that was robust, reliable, and wasn't susceptible to many of the ills we see in today's massive operating systems.

If I may be so bold as to say Mr. Tanenbaum is wrong,I'll explain..

• First of all,a FS is core,as a lot of drivers depend on it
  
  Secondly, why give up 0.6 GHz when it is in your processor?
  
  Thirdly, that 20% can be a huge difference when running something like, say, Quake 4, Blender, or some other graphically intensive application.

Raven wrote:Hello all

I have a simple question, if a kernel is not mapped to address space of every process and kernel itself is run as daemon does it make it a MicroKernel or MonoLithic?

In this case, there will be nothing that controls transfer between applications and the kernel, so the system can't work. This design is neither microkernel nor monolithic, its bogus

First of all,a FS is core,as a lot of drivers depend on it

Actually, its bottom feeder. It depends on all disk and I/O drivers, but virtually no driver requires the FS during operation.

KotuxGuy wrote:If I may be so bold as to say Mr. Tanenbaum is wrong,I'll explain..

You may

• First of all,a FS is core,as a lot of drivers depend on it
  
  Secondly, why give up 0.6 GHz when it is in your processor?
  
  Thirdly, that 20% can be a huge difference when running something like, say, Quake 4, Blender, or some other graphically intensive application.

I suppose 20% is a large performance hit; but I think it could still be argued that microkernels have their uses even here: how will you feel when you reach the final level on some really difficult game and the video card driver dies, causing the whole system to come down? Minix has what Tanenbaum calls a "reincarnation server" which detects driver crashes and restarts the offending driver. On a monolithic kernel, you could be just coming across the last boss when the whole system goes "Uh-oh" and halts. On a microkernel, you'd probably just get a short pause before the driver was restarted or replaced...

Raven wrote:I have a simple question, if a kernel is not mapped to address space of every process and kernel itself is run as daemon does it make it a MicroKernel or MonoLithic?

First off, it's impossible not to have the kernel (or at least a significant part of the kernel) mapped in every address space. You need to have something that handles interrupts and at least redirects control for things like scheduling and memory management, even with a microkernel. The thing you are describing cannot exist.

The thing that makes a microkernel a microkernel is the displacement of drivers, and optionally, memory management and scheduling, out of kernelspace. You still have to have an actual kernel in a microkernel system, running in kernelspace, even though it will be many times smaller than a monolithic kernel. Non-"essential" pieces, like the filesystem and console/block/network/etc. drivers always run as processes, instead of pieces of code in the kernel.

KotuxGuy wrote:If I may be so bold as to say Mr. Tanenbaum is wrong,I'll explain..

• First of all,a FS is core,as a lot of drivers depend on it
  
  Secondly, why give up 0.6 GHz when it is in your processor?
  
  Thirdly, that 20% can be a huge difference when running something like, say, Quake 4, Blender, or some other graphically intensive application.

I think 2 and 3 are the same thing...

That 20% overhead mentioned is mostly due to moving scheduling and memory management out of the kernel; this is generally accepted as being optional to the definition of a microkernel (but I'm sure I'll be corrected by any purists). So, there is usually not much of an overhead at all to having a microkernel, as long as drivers don't have to jump through hoops to access resources and the message passing system doesn't have lots of costly checks (like in Mach). I, having a functional microkernel, can assure you that it can easily be snappy on Bochs emulating a 5MHz i486.

Synon wrote:

KotuxGuy wrote:If I may be so bold as to say Mr. Tanenbaum is wrong,I'll explain..

You may

I suppose 20% is a large performance hit; but I think it could still be argued that microkernels have their uses even here: how will you feel when you reach the final level on some really difficult game and the video card driver dies, causing the whole system to come down? Minix has what Tanenbaum calls a "reincarnation server" which detects driver crashes and restarts the offending driver. On a monolithic kernel, you could be just coming across the last boss when the whole system goes "Uh-oh" and halts. On a microkernel, you'd probably just get a short pause before the driver was restarted or replaced...

Since when do video card drivers die?
Plus,I think you are talking about a pure Monolithic kernel. On a Hybrid, like Linux, such a thing wouldn't happen..

Troll?

Combuster wrote:Troll?

Me? A troll?

I was the first guy to answer Raven's question!

KotuxGuy wrote:Since when do video card drivers die?

I get over 21 million results for "graphics driver crash" on Google, and about 31 million of "video driver crash."

Plus,I think you are talking about a pure Monolithic kernel. On a Hybrid, like Linux, such a thing wouldn't happen..

Au contraire. On Linux (I'm on Arch right now) last year I had numerous problems with NVIDIA's video card drivers... I had to use the generic X windows drivers
It's not that big of a deal, but it was annoying.

I had the same problem on windows vista which I believe is a hybrid kernel.

Hi,

NickJohnson wrote:

Raven wrote:I have a simple question, if a kernel is not mapped to address space of every process and kernel itself is run as daemon does it make it a MicroKernel or MonoLithic?

First off, it's impossible not to have the kernel (or at least a significant part of the kernel) mapped in every address space. You need to have something that handles interrupts and at least redirects control for things like scheduling and memory management, even with a microkernel. The thing you are describing cannot exist.

The absolute minimum that must be in each address space is: an IDT with 13 entries and interrupt handling stubs for those 13 entries, a GDT with 3 entries (although the first GDT entry is the "NULL" entry and can overlap something else) and a stack capable of storing at least 16 dwords. It'd probably be possible to do it in 256 bytes without much problem.

If different protection levels are being used, then you'd need 3 more GDT entries and a TSS - maybe 512 bytes (but you'd probably round it up to 4 KiB).

The reason you need 13 IDT entries is that you have to have an entry for the general protection fault handler. For example, if someone does "int 0x80" then it'd be higher than the IDT limit, and you'd get a general protection fault. The general protection fault "stub" would switch to a different address space (the kernel) then the real general protection fault handler can examine the error code that the CPU put on the stack to find out which IDT entry caused the general protection fault, and then pass control to an "int 0x80" interrupt handler (while still in the kernel's address space). Basically, with only 13 IDT entries you can still have 256 interrupt handlers.

Of course this would be insanely slow (huge amount of overhead caused by constantly switching address spaces and flushing TLBs, combined with the inability to use "global" pages to prevent the kernel's TLB entries being flushed). The only reason to do something like this is to maximise the amount of space that a process can use (e.g. a process could use almost 4 GiB of the virtual address space); but, the number of processes that need more than 3 GiB of space but are happy with 4 GiB space is almost zero.

However, even in this case the kernel could still be monolithic or a micro-kernel.

NickJohnson wrote:That 20% overhead mentioned is mostly due to moving scheduling and memory management out of the kernel; this is generally accepted as being optional to the definition of a microkernel (but I'm sure I'll be corrected by any purists). So, there is usually not much of an overhead at all to having a microkernel, as long as drivers don't have to jump through hoops to access resources and the message passing system doesn't have lots of costly checks (like in Mach). I, having a functional microkernel, can assure you that it can easily be snappy on Bochs emulating a 5MHz i486.

I can't agree more.

The other thing I'd mention is that the biggest mistake (made by far too many micro-kernel projects), is to slap a POSIX layer on top of the micro-kernel and then compare the performance of POSIX processes when running on "micro-kernel + POSIX layer" to the same processes running on "designed for POSIX monolithic". It'd be equally stupid to slap a "micro-kernel emulation layer" on top of a monolithic kernel and then compare processes designed for the micro-kernel running on the micro-kernel to the same processes running on "monolithic + micro-kernel emulation layer".

Also, nobody wants "20% slower", and nobody wants "20% higher chance of kernel panics". It's easy to do benchmarks to compare performance, and hard to do any tests to measure "ability to withstand bugs", so people complain about the performance and ignore the other side of things.


Cheers,

Brendan

To each his own.

Brendan wrote:The other thing I'd mention is that the biggest mistake (made by far too many micro-kernel projects), is to slap a POSIX layer on top of the micro-kernel and then compare the performance of POSIX processes when running on "micro-kernel + POSIX layer" to the same processes running on "designed for POSIX monolithic". It'd be equally stupid to slap a "micro-kernel emulation layer" on top of a monolithic kernel and then compare processes designed for the micro-kernel running on the micro-kernel to the same processes running on "monolithic + micro-kernel emulation layer".

I'd want to know more about these mistakes, maybe I'm wrong too.
Can you give me some examples?

Hi,

andreaorru wrote:

Brendan wrote:The other thing I'd mention is that the biggest mistake (made by far too many micro-kernel projects), is to slap a POSIX layer on top of the micro-kernel and then compare the performance of POSIX processes when running on "micro-kernel + POSIX layer" to the same processes running on "designed for POSIX monolithic". It'd be equally stupid to slap a "micro-kernel emulation layer" on top of a monolithic kernel and then compare processes designed for the micro-kernel running on the micro-kernel to the same processes running on "monolithic + micro-kernel emulation layer".

I'd want to know more about these mistakes, maybe I'm wrong too.
Can you give me some examples?

Here's an example, titled The Performance of u-Kernel-Based Systems. It's more of a presentation/summary (rather than a research paper), but it will do to illustrate what I'm talking about. They compare L4Linux to Linux itself. Here's some (selected) quotes:

"the penalty for using a pure µ-kernel can be kept between 5% and 10%"

"syscalls are over twice as slow in L4 compared to native, however MkLinux is close to 10 times as slow, even when co-located"

"under AIM benchmark, L4 Linux is 8% slower than native linux on average"

"L4 Linux incurs a 5% to 10% penalty ”in a practical scenario”"

Now, think about this for a minute. Is this a sane way to compare micro-kernel performance with monolithic? I don't think so. They're comparing a micro-kernel with a monolithic kernel ported on top of it to a monolithic kernel.

What if we compare the performance of an application specifically designed for Windows running on Windows, to the performance of the same Windows application running on top of Wine on top of Linux? Would it be fair to say Linux performance is worse than Windows performance if this application's performance is worse on Linux? What if we do the reverse, and compare an application designed for Linux running on Linux to the same application running on Windows inside some sort of compatibility layer? Imagine a DOS game running on a 64-bit Linux machine inside Bochs - would you decide that Linux is a lot slower than DOS from this?

All of these comparisons are flawed. They compare "X + Y" to "Z" and decide that "X" is slower than "Z" and forget about "Y". For a fair test of performance, you'd want to compare an application designed specifically for L4 (with no compatibility layer) to an equivalent application specifically designed for Linux (also with no compatibility layer).


Cheers,

Brendan