Kernel-mode caching for microkernels

[JJeronimo]

Hello,

People say microkernels are slow, but why shouldn't a good microkernel cache the responses to IPC messages in kernel-mode?
I guess this could be done by presenting to servers an IPC interface sufficiently structured (e.g. object-oriented), and if the servers were written is a way so that they could take advantage of it.
For example, drivers for "block devices" could have an object for each block. Then, when someone read block X, the kernel could cache it for leter requests. File-like objects could use usual caching algorithms for files.
Prefetch schemes could then beimplemented in kernel-mode.

Then, there could be special access flags to disable caching when it was not possible or desirable.

JJ

[wolfram]

First: it won't be microkernel then.
Second: your brain unrecoverable damaged by OOP.

That's all.

[Rusky]

That would require that either 1) the kernel understand what user space servers are, or 2) the kernel include some general caching mechanism that could be configured by servers. Both of these would hamper flexibility, since servers would have to conform to specific semantics or bypass the caching altogether.

It would be better to just do the caching in the server, since anything that can be cached sanely probably wouldn't gain much by doing it in the kernel. In fact, for things like a disk cache, doing it in user space has benefits like giving you an entire address space rather than just the portion allocated to the kernel.

[Combuster]

Technically, the fastest form of IPC is shared memory. The speed reduction in IPC usually comes from context switches, so you want to minimize those.

In the case of a filesystem call, you can dump all cached pages into the receiver's address space when the file gets opened (and permissions have been checked), or some subset of them so that you don't end up with several gigs worth of mapping calls when your file browser starts rendering thumbnails of your movies folder.

Best case that means a single round trip of delay for each file read - and that's pretty much the theoretical minimum.

[JJeronimo]

First: it won't be microkernel then.
Second: your brain unrecoverable damaged by OOP.

First: your brain is damaged by "definition fundamentalism"! The name doesn't really matter for me... What really matters is whether that "microkernel that won't be a microkernel" can benefit form the advantages of micro-kernels (namely memory isolation between drivers, modularity, etc) while at the same time accelerating inter-server calls.
Second: not exactly... Actually, the problem is that I've been looking at ReactOS sources yesterday, so I'm still formatted for object-orientation...

That would require that either 1) the kernel understand what user space servers are, or 2) the kernel include some general caching mechanism that could be configured by servers. Both of these would hamper flexibility, since servers would have to conform to specific semantics or bypass the caching altogether.

I hold that (1) is not necessary. As for the (2), I believe there's a tradeof there.

It would be better to just do the caching in the server, since anything that can be cached sanely probably wouldn't gain much by doing it in the kernel. In fact, for things like a disk cache, doing it in user space has benefits like giving you an entire address space rather than just the portion allocated to the kernel.

Then you would need to make a call through IPC to obtain the cached contents, which sort of disables the original intention of avoiding context-switches for serving system calls... Also, if you use Long Mode (thinking about Intel arch, of course), you have tons of gigabytes to allocate caches (far more than the physical memory in most cases).
However, you make a good point: there isn't that much cacheable stuff for the kernel to help. Network apps would still need to make IPC calls to send or receive a package... Too bad!...

I presume you read J. Liedtke articles and studied L4 sources already, did you?

That's a fair presumption, but I'm not that fair!... I took a glance at the "Hurd critique", and did "Find" on some microkernel-related articles, but nothing more.

Technically, the fastest form of IPC is shared memory. The speed reduction in IPC usually comes from context switches, so you want to minimize those.

Tell me if I'm wrong, but as far as I know shared memory requires synchronisation primitives, and I don't see any reason for a microkernel-based operating system (kernel+servers) not needing them too... The serving process needs to have some way to know that it has to read or write something at someaddress, and that needs a context switch, no matter what... That doesn't mean, of course, that shared memory can't be useful (I guess how-many-tons of research paper I would be throwing to the trash-can if I said something like that, Iu that haven't even read J.Liedtke articles!), but looks like shared memory doesn't resolve the problem that I was talking about. Unless...

In the case of a filesystem call, you can dump all cached pages into the receiver's address space when the file gets opened (and permissions have been checked), or some subset of them so that you don't end up with several gigs worth of mapping calls when your file browser starts rendering thumbnails of your movies folder.

Yes, maybe it does solve part of the problem. One needs to think.

JJ

[gerryg400]

The serving process needs to have some way to know that it has to read or write something at someaddress, and that needs a context switch, no matter what...

Don't forget about SMP. Two processes on different cores can communicate by shared memory without a context switch if their comms is asynchronous, meaning neither has to stop. That's a big win for asynchronous messaging.

[JJeronimo]

The serving process needs to have some way to know that it has to read or write something at someaddress, and that needs a context switch, no matter what...

Don't forget about SMP. Two processes on different cores can communicate by shared memory without a context switch if their comms is asynchronous, meaning neither has to stop. That's a big win for asynchronous messaging.

You are right.

JJ