RTOS CPU Overhead

This article is written by Jean J. Labrosse, RTOS Expert.

An RTOS consumes CPU cycles to perform its duties. When an event occurs (possibly an interrupt), the scheduler of the RTOS is invoked to determine whether the event is one for which a higher-priority task is waiting for. If that is the case, the RTOS performs a context switch to this more important task. A context switch consists of saving enough CPU registers to resume, at a later time, the pre-empted task (e.g., lower-priority task) and restoring the CPU registers of the new task. The number of CPU cycles consumed depends on the CPU architecture. If the CPU is equipped with a floating-point unit (FPU), then registers of the FPU might also require saving/restoring depending on whether the task makes use of the FPU or not. Finally, if the CPU has some form of hardware memory protection, such as a memory management unit (MMU) or a memory protection unit (MPU), then a context switch will also need to account for those registers.

For example, the context switch overhead of an RTOS running on a Cortex-M having both an FPU and MPU would be about:

• 200~ for the scheduler
• 80~ for saving/restoring the integer registers
• 80~ for saving/restoring the FPU registers
• 60~ to setup the MPU for the new task

Note: ~ means clock cycles.

This adds up to 420 clock cycles (assuming zero wait-states) and, the CPU runs at 100 MHz, then the system would need just over 4 microseconds to perform a context switch. Viewed differently, if an application makes the RTOS switch tasks 5,000 times per second then the overhead would be 2%. Note that this is only the overhead associated with determining which task to run next, saving the registers for the task being switched out and, restoring the registers of the new task! 

CPU cycles are also consumed whenever any of the RTOS’ services are invoked, such as signaling that an event has occurred, sending messages to tasks, delaying execution of a task and so on. The overhead depends on the service being performed.

RTOSs are typically event-driven, meaning that a task will only execute when an event it is waiting for eventually occurs. When all tasks in an application have serviced their events, the RTOS can easily enter one of the CPU’s or MCU’s low-power modes, thus conserving energy, which is ideal for battery-powered applications.

A conservative figure when using an RTOS is to allocate between 10% to 30% of your CPU’s clock cycles to allow an RTOS to perform its services. Said differently, when planning for your CPU, get one that is 11% to 43% faster than originally planned for.

As bad as it may sound, there are far more benefits to using an RTOS than there are drawbacks!