If so what are you guys doing to cut back on context switching overhead with your MPI? Using syscall/sysenter?
syscall/sysenter only help to reduce the direct costs of a context switch but not the those caused by an increased number of TLB misses due to the the flush. In order to solve this problem a concept called 'address-space multiplexing' (which was originally designed by Jochen Liedtke, the founder of L4) is often used.
The basic idea is to divide the 4GB address-space into many smaller address-spaces using segmentation. That way, when a context switch occures, only some descriptors have to be reloaded which is much cheaper.
Another way to decrease context switch costs is to improve the performance of the IPC system which causes most switches. L4, which only supports non-buffered and synchronious messaging, has proven that the performance of IPC messaging can be increases dramatically compared to first generation microkernels like mach - not to mention monolithic kernels which basically suck at IPC performance.
For further details you might want to have a look at the official L4 website:
http://l4ka.org/
My main concern is understanding how hardware drivers are used and developed for a micro kernel environment, considering a few constructs I've seen do not have a "Hardware Manager" as part of their basic setup. This is baffling me.
Every operation system must have some sort of 'Hardware Manager' but there's no reason why it should be put into the kernel.
Device drivers need 2 ressources:
* IRQs
They are converted to IPC messages by the kernel which were sent by
'device tasks'. When an IRQ occures a messages is sent to all the driver
that have requested to be notified. The driver can then process the IRQ
and return to the kernel by sending a message. It's the kernel's job to
release the IRQ line.
* Address-space (memory mapped I/O, Ports)
L4 supports 3 primitives to deal with address-space management:
- task A can allow task B to access one of its page (map)
- task A can take away the access right it has given to task B (unmap)
- task A can give (away) one of its pages to task B (grant)
Memory is protected using paging, ports using the I/O bitmap in the TSS
A 'hardware-manager' should be implemented as a normal user-space task which was given the access right to all IRQs, all Ports, and all memory needed for I/O. The hardware manager can now load a device driver and pass on the neccessary access-rights to it.
This is much more flexible than using a built-in 'hardware manager' because the kernel doesn't have to know anything about drivers at all - it just manages some access-rights.
The basic idea in any microkernel is to only offer mechanisms but leave the policies to user-managers. With this concept even typical kernel tasks like memory managent or scheduling can be done in user-space.
regards,
gaf
but I may redesign or jump on board a new project to go micro kernel