OSDev.org

Could it be possible to implement microkernel IPC/task switching like so:

-Process 1 enters IPC_Receive() and It's status changes from running to waiting for IPC.
-Process 2 send message to process 1 using IPC_Send() and IPC_Send() performs task switching to process 1.
-Process 1's status changes to running and it continues to run.
-Task switch ignores process if its status is waiting for IPC.

Could this work? At least I think this could speed up UI response with microkernels on slow systems.

JuEeHa wrote:Could it be possible to implement microkernel IPC/task switching like so:

-Process 1 enters IPC_Receive() and It's status changes from running to waiting for IPC.
-Process 2 send message to process 1 using IPC_Send() and IPC_Send() performs task switching to process 1.
-Process 1's status changes to running and it continues to run.
-Task switch ignores process if its status is waiting for IPC.

Could this work? At least I think this could speed up UI response with microkernels on slow systems.

I don't understand the last bullet. What you describe sounds pretty much vanilla microkernel to me. Please elaborate your method and explain why it would do UI more responsive.

In normal microkernel IPC_Send() just sends message and doesn't task switch. And becouse drivers are implemented as processes if IPC_Send() task switches driver does the requested job instantly, not after scheduler/task switcher gets to it.

JuEeHa wrote:In normal microkernel IPC_Send() just sends message and doesn't task switch. And becouse drivers are implemented as processes if IPC_Send() task switches driver does the requested job instantly, not after scheduler/task switcher gets to it.

A normal mikrokernel does a task swtich in IPC_Send() if the target process/thread has a higher priority than the sender process. In practice if you want a more responsive system, that can be done by playing with priorities of the threads.

Also many times a send is followed by a receive. If you merge these two in one system call, you can avoid a few unnecessary task switches.

Hi,

JuEeHa wrote:In normal microkernel IPC_Send() just sends message and doesn't task switch. And becouse drivers are implemented as processes if IPC_Send() task switches driver does the requested job instantly, not after scheduler/task switcher gets to it.

What you described is called "rendezvous messaging" and a lot of existing micro-kernels use it. With this style of messaging you can't avoid task switches, and therefore task switches need to be very fast. The other problem is that it's messy when there's multiple CPUs (the IPC causes tasks to block/wait a lot, which makes it hard to keep CPUs busy doing useful work, unless you spawn lots of threads, which means you end up with lots of locks/mutexes and have to deal with the complexity and problems of those locks/mutexes). The advantage is that it behaves like a function call (which is easier for programmer's to deal with).

The alternative is using message buffers/queues. In this case you can avoid (postpone) task switches, but that doesn't mean task switches must be avoided/postponed. For example, when a low priority task sends a message to a high priority task, then it's natural for the high priority task to pre-empt the low priority task. Things like device drivers would be "very high priority". This method adds the overhead of managing message queues, but avoids the overhead of some task switches. It can also be a much more elegant way of handling multiple CPUs - because tasks don't need to block when sending messages or waiting to receive messages, they can continue doing useful work (and you don't need lots of threads and the hassles they cause). The disadvantage is that it doesn't behave like a function calls (it takes a different style of software design).

In general, for small systems (e.g. embedded systems) where there's typically only one CPU and there's very little state to save/load during task switches, rendezvous messaging can be very good. For larger systems (like modern 80x86, Itanium, etc) where there's typically multiple CPUs and there's lots of state to save/load during task switches (e.g. FPU/MMX/SSE/AVX, paging structures, etc), rendezvous messaging can be very bad (but some people still use it anyway, because it behaves like a function call and is easier for programmer's to deal with).


Cheers,

Brendan

Brendan wrote:In general, for small systems (e.g. embedded systems) where there's typically only one CPU and there's very little state to save/load during task switches, rendezvous messaging can be very good. For larger systems (like modern 80x86, Itanium, etc) where there's typically multiple CPUs and there's lots of state to save/load during task switches (e.g. FPU/MMX/SSE/AVX, paging structures, etc), rendezvous messaging can be very bad (but some people still use it anyway, because it behaves like a function call and is easier for programmer's to deal with).

I haven't experienced that synchronous messaging causes more task switches than asynchronous, rather the other way around. This depends how you use it though. A system that only provides asynchronous messaging can actually cause more unnecessary tasks switches than a system providing only synchronous or both methods. A majority of IPC messages are of type send/response RPC type calls and asynchronous messaging is usually far worse in this case. I guess this is why Mach kernel merged the send/receive system call which basically a way to implement synchronous messaging with asynchronous primitives.

I haven't experienced that synchronous messaging causes more task switches than asynchronous.

If messages can be sent asynchronously a client can send many messages during its time-slice (Many messages per context switch). If the send primitive is blocking, then only a single message may be sent per context switch.

Hi,

gerryg400 wrote:

I haven't experienced that synchronous messaging causes more task switches than asynchronous.

If messages can be sent asynchronously a client can send many messages during its time-slice (Many messages per context switch). If the send primitive is blocking, then only a single message may be sent per context switch.

Yes. In addition, if tasks can be run on different CPUs then they could sends millions of messages to each other with no task switches at all.

It's more complex than that though.

To begin with, you only really get the full benefit when tasks have work to do. If a task has nothing to do, then receives a message and handles it, then has nothing to do; then you're going to get task switches. If a task is busy (either handling lots of messages or doing other work while it waits for messages) then those task switches can be avoided.

It also depends on how the OS does task priorities and scheduling. For example, for my last kernel, a higher priority task would only pre-empt a lower priority task if the difference between priorities is "enough". This helps to reduce the number of task switches (if higher priority tasks always pre-empt, even when they're only slightly higher priority, then you'd get more task switches).

The other thing to consider (for multi-CPU systems) is who gets pre-empted. For example, if a medium priority task sends a message to a high priority task (causing that high priority task to unblock); then the high priority task may pre-empt a low priority task on a different CPU, and the medium priority task may continue running with no task switches. The overhead of task switches tends to be shifted to where it matters less.


Cheers,

Brendan

I see no reason why all syscalls needs to go through an IPC-interface. It seems so wasteful. I determine per-syscall what is needed for synchronization. Often, a simple "binary mutex" is enough. Sometimes no synchronization at all is needed (private resources). Sometimes synchronous IPC (rendevous with a server thread) is needed, and then can be efficiently implemented with my "Signal" / "WaitForSignal" interface.