This section addresses the issue caused by DVS state switching overhead in the RTSC problem and proposes a solution by enhancing the traditional schedulability analysis.
7.2.1 Problem Description
On single-core processor platforms the problem caused by DVS state switch-ing is quite straightforward. Since each task runs at its assigned speed, at each task switching point the core operating speed may have to be changed.
𝝉𝟏 𝝉𝟐
(a) Task execution without consideration of switching overhead
(b) Task execution with consideration of switching overhead
Figure 7.1: A comparison of task execution with and without DVS state switching overhead
Clearly, DVS switching latency introduces additional delays into the task execution. If this latency is not considered properly in schedulability analy-sis, some deadline misses may not be predicted. This problem is similar to the context switching problem. Figure 7.1 illustrates the comparison of task execution with and without consideration of DVS state switching overhead.
This example assumes W (τ1) = 20 ms, T (τ1) = 40 ms, W (τ2) = 15 ms and T(τ2) = 80 ms. The tasks τ1and τ2are assigned with the P-states S1and S2, respectively, where F(S1) = 1 and F(S2) = 0.5. The EDF algorithm is ap-plied as real-time scheduler. Based on the traditional schedulability analysis, all the tasks can be scheduled without deadline miss.
U=W(τ1) · F(S1) If the DVS state switching overhead is ignored, as shown in Figure 7.1(a), all the tasks indeed complete before their deadlines. However, if the switching overhead is considered, which takes 5 ms in this example, the task τ2misses its deadline at the time point 80 ms. The reason is rather obvious, because additional delays due to DVS state switches have been introduced into the task execution.
7.2.2 Enhanced Schedulability Analysis
In order to solve the above mentioned problem, this work provides Theorem 7.2.1 by taking DVS switching overhead into consideration in the schedula-bility analysis. Before the theorem is presented, an example is illustrated in Figure 7.2 to simplify the explanation.
This example involves 4 real-time tasks and assumes a priority based schedul-ing algorithm. In terms of task priority, τ1 < τ2< τ3< τ4 holds. During
𝑺𝟏
Figure 7.2: A single-core processor example with 4 real-time tasks
execution, one further assumes that τ1 is preempted by τ2. τ2is in turn pre-empted by τ3, which is again preempted by τ4. As a result, there are in total 6 DVS state switches (L1p, L2p, etc.) shown in the figure. Note that a DVS switch is always associated with a context switch. In other words, if there is a DVS state switch then there must be a context switch. However, a context switch may not be necessarily accompanied with a DVS state switch.
Therefore, in order to take DVS state switching overhead into account, it is sufficient to count the number of context switches [Dev03]. In a preemp-tive real-time system, context switches can be classified into two categories according to their causes:
1. Switches due to preemption: These context switches are cased by pre-emption when a task with higher priority arrives while the currently running task has a lower priority. In Figure 7.2, the switches L1p, L2p and L3pare clearly belonging to this category.
2. Switches due to task completion: These context switches are caused when a task completes and there is at least one ready task is waiting for execution. Obviously, the switches L4p, L5p and L6pin Figure 7.2 fall in this category.
Based on this classification, context switches can be charged to tasks. In particular, a switch due to preemption is charged to the task, which has caused the preemption, i.e., the task which just arrives and has a higher priority than the current running task. A switch due to task completion is charged to the task, which just completes. Following this rule, it is not hard to see that a task may be responsible for at most one switch due to preemption and one switch due to task completion inside its period, because the task arrives and completes only once. Consequently, a task may cause two context switches at most, once at the arriving time and once at the completion time. In Figure 7.2, clearly L1pand L6pare accounted to τ2, L2pand L5pare accounted to τ3and finally L3p and L4p are accounted to τ4. Except the task τ1, all the tasks are causing exactly two switches. If the example is extended to running n tasks, the required switches become 2n − 2.
Now it is ready to introduce Theorem 7.2.1.
Theorem 7.2.1. A hard real-time system on a DVS enabled single-core pro-cessor platform is schedulable, if the following condition is satisfied:
n
∑
i=1
W(τi)·F(S1)
F(assign(τi))+ 2 · Lp
Ti ≤ UB (7.2)
Proof. The delays are always caused by P-state switching, which may only happen at context switch. Since each task may cause two context switches at most inside its period, the maximal number of delays caused by a job is limited by two. If these two delays are accounted into task worst case execution time, clearly the system feasibility can be guaranteed.
If the processor utilization in the previous example (shown in (7.1)) is re-computed using (7.2), the deadline miss can be predicted.
U = 20 ms + 2 · 5 ms
40 ms +30 ms + 2 · 5 ms
80 ms = 5
4 > 1 (7.3) Clearly, Theorem 7.2.1 gives a conservative analysis of processor utilization.
In general, the test (7.2) overestimates the real utilization of processor. This is mainly due to two reasons: i) not every task causes exact two context switches and ii) not every context switch is accompanied with a DVS state switch and thus a delay. However, the system schedulability is of utmost importance in a hard real-time system. The analysis must work on all the scenarios, even in the worst case.