Microkernel IO caching and demand paging models

[OSwhatever]

IO caching in monolithic kernels kan be made quite easily since every cached page is owned by the kernel. The kernel is fully aware of available cached pages and if a cached page needs to be used for other purposes, the kernel can easily be updated.

With a microkernel the kernel doesn't necessarily own any pages at all. Usually paging is done by paging servers, file IO caching is done by the file system server one way or another. What happens if the system gets low on pages and wants some more taking some pages used for IO caching? The pages that works as IO cache is now owned by various servers, file system server for example. What should the memory manager do? Ask nicely the other processes if it can have some pages?

You can make it possible for a pager process to also have the right to remove pages from another process. Then the memory manager, the original owner can unmap pages right under the nose of any process. That it will yield an exception, that will reload the page that was taken if it is being read again. However it is still difficult since the server process has no idea what pages that are acutally taken and cannot really make any decisions based of it. If it decides to unmap some cached pages, some of them might be already taken and so on.

In short, how can we snatch pages from other processes without causing havok?

[gravaera]

Why does your I/O manager/FS layer, or whatever have knowledge of/have to consider/have to know about/have to interfere with page layout? Shouldn't the memory manager have the sole right to know about the composition of every address space? If so, then why can't the memory manager decide what to do when frames are low? (Swap, sleep processes, etc). Based on your description, it seems you delegate a certain amount of memory management to the various subsystems, no doubt as a remedy to the problem of having to have other services call on the memory manager service which is in its own address space.

If you think about it, though, what stops you from having a microkernel, but leaving the memory manager in kernel space? You can then have all other service modules call on the memory manager with one uniform set of code in kernel space, and no latency. The rest of your kernel may be partitioned as you see fit.

You can make it possible for a pager process to also have the right to remove pages from another process. Then the memory manager, the original owner can unmap pages

The memory manager usually handles paging, and also, page swapping, where some privileged code is allowed to tamper with other processes' page tables (the memory management code) is quite conventional.

--All the best
gravaera

[OSwhatever]

Why does your I/O manager/FS layer, or whatever have knowledge of/have to consider/have to know about/have to interfere with page layout? Shouldn't the memory manager have the sole right to know about the composition of every address space? If so, then why can't the memory manager decide what to do when frames are low? (Swap, sleep processes, etc). Based on your description, it seems you delegate a certain amount of memory management to the various subsystems, no doubt as a remedy to the problem of having to have other services call on the memory manager service which is in its own address space.

If you think about it, though, what stops you from having a microkernel, but leaving the memory manager in kernel space? You can then have all other service modules call on the memory manager with one uniform set of code in kernel space, and no latency. The rest of your kernel may be partitioned as you see fit.

You can make it possible for a pager process to also have the right to remove pages from another process. Then the memory manager, the original owner can unmap pages

The memory manager usually handles paging, and also, page swapping, where some privileged code is allowed to tamper with other processes' page tables (the memory management code) is quite conventional.

--All the best
gravaera

Regardless if you have the memory manager in kernel space or not, it's the caching in user space that is the main issue.

With a monolithic kernel it easy since you basically have a structure that gives you what file and block corresponds to a physical page. You don't even have to have all the cached pages mapped in the kernel if you don't want to.

With a file system server, the page cache is in virtual space and that space has to be managed somehow. Stealing pages from a user space creates holes in virtual space for the server and the server has no idea where they are. Due to this, the server will not have the same information to decide which cached files and blocks that it is going to evict in virtual space. So this is a little bit of a two layered problem, in monolithic kernel you deal with physical pages more directly, in user mode you have to think about virtual mappings as well.

Maybe you are right, physical caching and the management of the virtual address space of a server can be totally independent and the loss of the information of page stealing from a user process isn't that bad in reality.

[Owen]

Provide a method for the process to indicate pages are caches; probably your OS' equivalent to POSIX mprotect. Whenever that page is accessed and the memory manager has freed it to reclaim the RAM, raise an exception which will unwind the accessing thread. Said thread is responsible for then reallocating the page and refilling it with data.

(This assumes you have some sort of exception model in your OS, of course)