Overhead

Which partition is the overhead associated with scheduling charged to?

Let's consider all kernel calls, such as messaging and mutexting, that switch threads to be overhead. Call the initial running thread t1, and the next thread t2. Let's consider the kernel calls that are initiated by t1 and cause t1 to stop running and t2 to start running.

The overhead is split between t1 and t2, but mostly to t1 with the following details:

Time to:	Is charged to the partition of:
Enter the kernel	t1
Run the scheduling algorithm	t1
Do a context switch	t2
Exit the kernel	t2

Which partition is the overhead for processing interrupts charged to?

There are two parts of interrupt servicing: the interrupt handler and the interrupt thread.

If you service interrupts with an interrupt thread, most of the time spent servicing the interrupt is the thread's time, and only a small part of the time is spent in the interrupt handler. The interrupt handler determines the thread to which the interrupt event should be delivered.

If you service interrupts with an interrupt handler, all of the time spent servicing the interrupt is in the handler.

The time spent in an interrupt thread is charged against the partition of that thread.

The time spent in an interrupt handler is charged against the partition that's running at that time.

Since the interrupts occur in random, time spent in interrupt handler is spread evenly over all running partitions.

What is the CPU overhead with the thread scheduler?

The QNX Neutrino results indicate that heavy compiling benchmarks that involve a lot of filesystem-related messaging are about 1% slower on x86 platforms when using the thread scheduler.

What is the memory overhead with the thread scheduler?

Data

A few kilobytes of fixed overhead along with 2 KB per partition.

Code

About 18 KB.

Both of these are in the kernel space.

What factors increase the overhead for the thread scheduler?

In approximate order of importance, the cost of the thread scheduler increases with:

• the number of scheduling operations, such as sending messages, events and signals sent, mutex operations, and sleeps
• the platform — in particular, ARM is noticeably slower because of the I/O needed to implement ClockCycles()
• the frequency of clock ticks
• the number of partitions
• the use of runmasks

In all the above cases, the increase is approximately linear.

The following factors don't affect the cost of scheduling at all:

• the number of threads
• the length of the averaging window (except for a very small effect when changing the window size)
• the choice of percentage budgets
• the choice of thread priorities
• the choice of FIFO, round-robin, or sporadic thread policies