OSDev.org

simeonz wrote:

LtG wrote:I think the main issue with "generic" languages isn't that they're unmanaged, it's pointers. So if you create a language without pointers it should be safe, and have good performance. You may need some unsafe parts (where pointers are allowed), and that part needs to be inspected or JIT'd, but JIT'ing isn't a requirement and neither is managed.

There are quite a few options, come to think of it now. But the effect is the same - performance of a managed language. On the other hand, I agree that manually managing the resource may be more appropriate, considering that this is the only way to guarantee immediate resource reclaiming. So, you are basically right.

I don't think performance is that big of a deal actually. I think performance has historically been an issue because of historical reasons. Basically, if the OS is built like a POSIX OS, then it's not IPC/message heavy and that has influenced the overall design. If you then try to apply "microkernel" philosophy on-top you get performance penalties. The same, I think, applies to managed vs unmanaged, it's a different approach and if you run an OS that has been designed with unmanaged in mind, and then put managed layer between the OS and the app, you'll get performance penalties.

Even with the above, managed doesn't have significant performance penalties for many applications, so imagine if the OS was designed for a single managed language instead, and possibly used a single address space, it might even perform better.

More often than not (practically always), we (people) aren't that great at managing resources, so while the automated management of resources may have some overhead, it balances out due to the big picture complexities and the practical trade-offs people make (aka. C vs asm).

simeonz wrote:

LtG wrote:In general, none of the things you list are micro specific. So some microkernels might allow driver restarts while another won't. Micro really only means that you push everything out to user space (into processes).

You mean that micro-kernels can target convenient development and unified APIs, or something else entirely? Because, the killer features for a micro kernel I believe are uptime and security. Let me put it this way - we don't use forks because we like the taste of metal.

I prefer microkernels because they are simpler, in a way more structured, and I hope I can get it to perform better than a monolithic one.

Of course, it doesn't really matter on what level you erect the security boundaries. You could achieve "microkernel security" with the traditional microkernel way (process isolation and everything is a process), you could do it at language level, etc. It's really all the same, in a way the OS's abstractions (processes for example) are an "extension" of any language.

So what I was trying to say was that microkernel isn't about stability, security or uptime, but rather a design philosophy that hopefully delivers those things. But still each OS/kernel is it's own thing and maybe achieves some of those things. A monolithic kernel written in a "perfect" language may very well be better than a microkernel written in C.

LtG wrote:Abstraction itself doesn't decrease performance, and in fact many times doesn't.

That was indeed badly worded. It's not the abstraction that impacts performance but the isolation. The additional communication (that is necessary because a microkernel separates interacting drivers into different address spaces) is not free

LtG wrote:If it can be done with hardware, it can be done with software, though for the general case the performance would be poor. [...]

I do not get that point. I don't think the question is "can it be done at all?" as the answer to that is obviously yes, you can run everything in an emulator and perfectly separate arbitrary applications even in a single address space. The real question of course is: Is it practically feasible? Your post does not address that.

LtG wrote:I think the point here is that a monolithic (Linux/POSIX) will want epoll, a microkernel would never have epoll, so the two can't be compared fairly.

For instance for microkernel you might only implement memory mapped files, so you have single message sent to VFS to map fileA to procA address space and then you just read memory, if it's not read into memory when memory is accessed then #PF -> read it into memory.

I don't think epoll is an interface that is only necessary in monolithic kernels. You'll want such notification mechanism (e.g. for sockets) in any OS. Otherwise you'll have to fall back to techniques like many concurrent reads which will always be inferior in scalability (asynchronous or not).

I can also talk about memory mapped files: Assume some process memory maps a large file that is not in a page cache. We're talking about a microkernel. The process touches some page and causes a page fault. The kernel switches to the file system driver. It turns out that the FS resides on a USB flash drive. The FS driver switches to the USB HCD driver to fetch the inode. The HCD driver performs some transactions and returns to the FS driver. It returns to the FS driver that parses the inode and locates the file data. The FS driver again invokes the HCD driver to fetch the data pages. That driver finally returns to the application.

Thus, a simple read operation requires the interaction of three different drivers and more than 3 context switches. Current CPUs implement only a few (~two?) bits of the PCID. You've already exhausted 3 of these slots just for the read. An I/O operation that involves another device (e.g. a network card) will most likely require a TLB flush, even when PCIDs are supported. Context switches are not for free, even if they do not copying memory. Shared memory is not for free either.

LtG wrote:I prefer microkernels because they are simpler, in a way more structured, and I hope I can get it to perform better than a monolithic one.

Have you actually written a microkernel or this is just some abstract suggestion? My managarm project is probably one of the more advanced hobby microkernels. I wouldn't describe it as "simple" or claim that it has the potential to beat monolithic kernels performance-wise. Writing a monolithic kernel like Linux is much easier than writing a "good" microkernel.

The previous design used a managed language + a single address space monolithic kernel and writing that (even considering the JIT and garbage collector) was much easier than designing the microkernel.