Microkernel kernel address space

[FlashBurn]

I´m writing on a microkernel and now I have to decide how important is the kernel address space. I mean how important is it that I have enough of it?

So what should go into the kernel and what are the resources which resides in the kernel? I´m asking because I use an avl tree to track the free address ranges of every process and this could be at worst 6MB. I just come up with the idea to reserve a 8mb region of my kernel address space for every process (at a fixed address). So that I would have at worst 8MB lost of my kernel address space, but not "6MB*number of processes". The thing is that it complicates my code, but what would I get of it. Do I need so much kernel address space that it is worth it?

Without this I could have ca. 300 processes (if every process would be a worst case), with it ca. 100k processes.

So until now I have the process strucs, thread strucs and fpu strucs in my kernel. Could the esp0 stacks go into user space or should they be in kernel space? What else should be/is in kernel space?

[AndrewAPrice]

Are you targeting a 32-bit or 64-bit architecture?

For 32-bit, you could map your kernel from 0xF000 0000 to 0xFFFF FFFF, giving you 250MB for your kernel and 3.75GB for user applications. 250MB should be more than enough for a microkernel unless you are doing some major caching or buffering of messages. This is just an example which gives you ample room to grow. I'm sure in a typical microkernel with tens of thousands of active processes all continuously involved in messaging and mapping/unmapping memory you may only require 16MB or less.

Also, what you set doesn't mean it's going to stay that way. That's one of the advantages of higher-half kernels. You can change the kernel's virtual base from 3.9GB to 3.5GB even down to 2GB as simple as changing a preprocessor definition, and all your programs (which are operating near the beginning of the virtual address space) won't ever know the difference.

If you're dealing with 64-bit, then you have 2^64 avaliable which is "equivalent to approximately 17.2 billion gigabytes, 16.8 million terabytes, or 16 exabytes of RAM." [*][/url]. So basically you can allocate an entire terabyte to your kernel from 0xFFFF FEFF FFFF FFFF to 0xFFFF FFFF FFFF FFFF, still leaving 16,777,215 terabytes free for your applications!

[NickJohnson]

Although current 64-bit processors actually have 48-bit addressing, so it's considerably less than that - only the upper and lower 2^47 bytes of the full address space can actually be used. You might as well use the entire higher 2^47 bytes for the kernel - 128 terabytes is probably enough for user processes.

[FlashBurn]

I´m writing for x86 (32bit) and I have totally forgotten the msgs. If I have 100k processes I also need minimal 100k msg ports and I will save the msgs in kernel space. So I think I will go with an extra region for tracking the free addresses of every process.

How would you do the msgs part? At the moment I plan to have msg ports and I will have fixed size msgs only and they will be saved in the kernel space.

[Owen]

I'd have synchronous rendezvous messages. Then I just need N pages of address space reserved, where N is the upper bound on the length of messages allowed to be copied.

[FlashBurn]

I just thought about the way I want to design my device manager and I think it will be a server (userprocess) and I will have busmanagers as addons for it.

The problem I have right now is, it would be important that I 1st load the pci busmanager, but how could I do that w/o knowing the filename of the addon? And what is about the VFS, I would also do it as a server, is the performance hit so big that it would be better to have it in the kernel?

[AndrewAPrice]

And what is about the VFS, I would also do it as a server, is the performance hit so big that it would be better to have it in the kernel?

And thus the debate of microkernels vs monolithic kernels begins!

To summarise; yes it's slower, but it depends on how you implement it and the speed of your IPC. Of course, you could do a hybrid kernel with the VFS and it's extensions as loadable modules that run in kernel space. It combines the microkernel flexibility and monolithic performance at the sacrifice of microkernel security. It all depends on your priorities.