O(1) system calls
Every system call in KideRT is O(1). The work the kernel does on a call does not grow with the number of threads, timers or waiters in your application. That makes system call timing deterministic. The bound stays the same however many kernel objects the application creates, threads wait on them, or messages it queues.
A WCET at any sizeA WCET that grows with the application
What sets the WCET
O(1) means the worst-case execution time of a system call has an upper limit that does not grow with the application. The limit is set by the target, meaning the core, its clock, the compiler and the options in the build. Measuring on the target gives the times; treat an observed maximum as the maximum of that run, not as a bound.
It holds for the timer interrupt behind High-Resolution Scheduling, and for a thread switch with memory protection enabled, which adds a fixed cost per switch.
- Set by
- The core, its clock, the compiler and optimisation level, flash wait states and caches, and the options enabled in the build, such as memory protection.
- Not changed by
- How many threads exist, are ready or share a priority, how many timers are armed and threads asleep, how many threads wait on a mutex, semaphore or message queue, and how many messages a queue holds. Nor what was created and destroyed before.
- Not covered
- Application code the kernel runs, such as a timer’s notification function, thread-local storage destructors when a thread exits and cancellation cleanup handlers. The kernel cannot guarantee its worst-case execution time.
Measuring the WCET
KideRT measures its own timing. With the instrumentation enabled, the kernel records the longest time each system call took on your target and reports the figures. The profiling chapter describes how to enable it and how to read the report.
The figures from one run, with its conditions, are on the measured WCET page.
Read the profiling chapterO(1) in practice
Is O(1) the same as fast?
No. O(1) says the worst-case execution time of a call does not grow with the application; it says nothing about how large it is. That depends on the core, the clock and the build, and is measured on the target.
Does creating objects at run time change the WCET?
No. Creating a thread, queue or timer is O(1). It does not depend on how many objects exist or on what has been created and destroyed before. Creation and destruction are O(1) like every other call.
Does memory protection change it?
With memory protection enabled, a thread switch also loads the memory regions of the incoming thread. That is a fixed cost per switch. It does not depend on the number of threads or on the regions configured for other threads.
What if several timers expire at the same instant?
Each expiry is handled in O(1). When several fall due at once, the timer interrupt handles them in turn, so its run grows with the events due at that instant, not with the number of timers armed.
Profiling KideRT
Discuss your target and how to profile KideRT on it with our engineers.