OSDev.org

I've added context switch counters to my kernel, and the results got me thinking.

The timer is running at 200 Hz, and in Qemu i get 1000-1500 switches per second.
It's the voluntary preemption.
A driver thread would poll for events, find none and yield.
Services would poll for messages, find none and yield.
A terminal would poll for key press messages, find none and yield.
And so on.

There are flurries of activity when something happens, but most of the time the non-waiting processes just yield to each other, only slowed down by the kernel idle process issuing a hlt instruction.
Without it, i get 5500 switches per second in Qemu - i guess it runs as fast as it can switch.

So, how normal is that?
On one hand, you'd want the system to spend most of the time in idle/low power mode when nothing is happening.
On the other hand, you want fast responses when something does happen.
The scheduler can't really keep track of what would or wouldn't get an event, so i can't quite see a way to improve both things at once.
It's feasible to balance one way or the other - i.e. make the system idle until the next timer interrupt when a process yields.

Any thoughts?

The code that generates the event should also wake up the process that's supposed to receive that event. A process that has no pending events or work should put itself to sleep. So instead of a Yield call you can use a wait call instead.

Your design seems quite strange. I don't quite understand why you need to switch context to find that something doesn't need to run. In most microkernels the kernel either executes an idle thread or hlts when there is nothing to do. When a message or event arrives for a thread that thread is woken up to process the message. Once the processing is done it sleeps until another message or event arrives for it. Other threads are never considered for running by the scheduler.

Hm.
The way it evolved, task scheduling and messaging are two separate systems with no communications.

So, in the simplest shape it's a matter of putting the waiting threads to sleep and make the message processor wake a thread when a message is posted for it?

Yes.