1 | = Task Preemption Benchmark |
---|
2 | |
---|
3 | This benchmark measures the average time it takes the system to recognize |
---|
4 | a ready higher priority task and switch to it from a lower priority task. |
---|
5 | This differs from a task-switch in the sense that there is no explicit |
---|
6 | yield, the system forces the context switch. |
---|
7 | |
---|
8 | == Directives |
---|
9 | |
---|
10 | * rtems_task_suspend |
---|
11 | * rtems_task_resume |
---|
12 | |
---|
13 | == Methodology |
---|
14 | |
---|
15 | Preemption usually occurs in a program when a high priority task moves from |
---|
16 | a suspended or idle state to a ready state in response to an event. This is |
---|
17 | achieved in the benchmark by using rtems_task_suspend and rtems_task_resume |
---|
18 | to move the high priority task in between states. |
---|
19 | |
---|
20 | As this is an average, we structure the benchmark code in a way that results |
---|
21 | in some overhead being included that inflates the total elapsed time. This |
---|
22 | overhead includes: |
---|
23 | * loop overhead (minimal) |
---|
24 | * the time it takes to task-switch from the high priority task back to |
---|
25 | the low priority task. |
---|
26 | * The time it takes to change the state of a task (suspend/resume). |
---|
27 | |
---|
28 | We instantiate two tasks, one with a higher priority than the other. The |
---|
29 | benchmark starts with the high priority task suspended. The benchmark code |
---|
30 | has the lower priority task resume the high priority task, at which point |
---|
31 | the preemption we are seeking to time occurs. The high priority task, now |
---|
32 | executing, suspends it self, and a non-preemptive task switch back to the |
---|
33 | low priority task occurs. This is repeated a total of BENCHMARKS times. |
---|
34 | |
---|
35 | The average time is found by using put_time to divide the total elapsed time |
---|
36 | by the number of benchmarks, and subtracting out the overhead found earlier. |
---|