**3.1 CPU idle times determination under EDL**

The basic foundation of our scheduling approach for enhancing the QoS of skippable periodic tasks relies on the *Earliest Deadline as Late as possible (EDL)* algorithm (Chetto & Chetto, 1989). Thus, we will review the fundamental properties of this algorithm. Such an approach is known as Slack Stealing since it makes any spare processing time available as soon as possible. In doing so, it effectively steals slack from the hard deadline periodic tasks. A means of determining the maximum amount of slack which may be stolen without jeopardizing the hard timing constraints is thus key to the operation of the EDL algorithm. We described in Chetto & Chetto (1989) how the slack available at any current time can be found. This is done by mapping out the processor schedule produced by EDL for the periodic tasks from the current time up to the end of the current hyperperiod (the least common multiple of task periods). This schedule is constructed dynamically whenever necessary. It is computed from a static EDL schedule constructed off-line and memorized by means of the following two vectors:

• *K*, called static deadline vector. *K* represents the instants from 0 to the end of the first hyperperiod – at which idle times occur – and is constructed from the distinct deadlines of periodic tasks.

6 Will-be-set-by-IN-TECH

*T*0 *T*1 *T*2 *T*3

*T*0 *T*1 *T*2 *T*3

vectors:

periodic tasks.

*: processing red instance*

*: processing red instance : processing blue instance*

Fig. 3. A schedule produced by the RTO scheduling algorithm (*si* = 2)

Fig. 4. A schedule produced by the BWP scheduling algorithm (*si* = 2)

Figure 4 illustrates a BWP schedule for the task set T (see Table 1).

under RTO which represents a total of seven instances.

**3. Superior skip-over scheduling algorithms**

**3.1 CPU idle times determination under EDL**

✻*: release time*

✻*: release time*

✻ ✻ ✲✻ ✻ ✻ ✻ ✻ ✻ ✻ ✻ ✻ ✻ ✻ ✻ ✻ ✻ ✻ ✻ ✻

✻ ✻ ✲✻ ✻ ✻ ✻ ✻ ✻ ✻ ✻ ✻ ✻ ✻ ✻ ✻ ✻ ✻ ✻ ✻

0 36 72 0 24 48 72 0 18 36 54 72 0 12 24 36 48 60 72

As can be seen, BWP increases the total number of task instances that complete successfully. Five deadlines of blue instances are missed at instants *t* = 24 (task *T*3), *t* = 36 (task *T*2), *t* = 48 (tasks *T*<sup>1</sup> and *T*3) and *t* = 72 (task *T*3). In contrast, all deadlines of blue instances are missed

The basic foundation of our scheduling approach for enhancing the QoS of skippable periodic tasks relies on the *Earliest Deadline as Late as possible (EDL)* algorithm (Chetto & Chetto, 1989). Thus, we will review the fundamental properties of this algorithm. Such an approach is known as Slack Stealing since it makes any spare processing time available as soon as possible. In doing so, it effectively steals slack from the hard deadline periodic tasks. A means of determining the maximum amount of slack which may be stolen without jeopardizing the hard timing constraints is thus key to the operation of the EDL algorithm. We described in Chetto & Chetto (1989) how the slack available at any current time can be found. This is done by mapping out the processor schedule produced by EDL for the periodic tasks from the current time up to the end of the current hyperperiod (the least common multiple of task periods). This schedule is constructed dynamically whenever necessary. It is computed from a static EDL schedule constructed off-line and memorized by means of the following two

• *K*, called static deadline vector. *K* represents the instants from 0 to the end of the first hyperperiod – at which idle times occur – and is constructed from the distinct deadlines of

0 36 72 0 24 48 72 0 18 36 54 72 0 12 24 36 48 60 72

✲ ✲ ✲

✲ ✲ ✲ • *D*, called static idle time vector. *D* represents the lengths of the idle times which start at instants of *K*.

The dynamic EDL schedule is updated at run-time from the static one. It takes into account the execution of the current ready tasks. It is described by means of the following two vectors:


Assume now that, given the task set T = {*T*1(3, 10, 10); *T*2(3, 6, 6)}, we want to compute idle times from instant *t* = 5 while tasks have been processed by EDF from 0 to *t*. The resulting schedule is depicted in Figure 5. Note that *f EDL* = 1 if the processor is idle at *t*, 0 otherwise.

Fig. 5. EDL computation of dynamic idle times at time *t* = 5

Next, tasks are scheduled as late as possible according to EDL from time *t* = 5 to the end of the hyperperiod. Nonzero idle times resulting from the computation of vectors *Kt* and *Dt* appear at times *t* = 5, *t* = 6, *t* = 12 and *t* = 20.

Chetto & Chetto (1989) showed that the EDL schedule computation can be efficiently used for improving the service of aperiodic tasks. By definition, soft aperiodic requests must not compromise the guarantees given for periodic tasks and should be completed as soon as possible. No acceptance test is performed for soft aperiodic requests; they are served on a best-effort basis within the computed idle times, the goal being to minimize their response times. Concerning hard aperiodic tasks, each task is subject to an acceptance-rejection test upon arrival. Hard aperiodic tasks can indeed easily be admitted or rejected on the basis of the knowledge of idle times localization.

In the next sections, we are first interested in using EDL to build a schedule on the red instances only so as to execute the blue instances as soon as possible in the remaining EDL idle times (see section 3.2 The RLP algorithm). In a second phase, EDL will allow us to derive a test for deciding on-line whether a blue instance can be accepted for execution or not (see section 3.3 The RLP/T algorithm).

in the Firm Real-Time Systems 9

Quality of Service Scheduling in the Firm Real-Time Systems 199

*Algorithm RLP*(t : current time)

*break endif*

*break endif*

*else*

*endif*

*endif endif*

*endwhile*

Fig. 6. RLP scheduling algorithm

*endwhile*

*endif end*

*and* (f\_EDL(t)=0)) */\*red task release\*/*

*endwhile*

*/\*checking blue ready list in order to abort tasks\*/ while* (task=next(blue ready list)=*not*(∅))

> Pull task from blue ready list task→release time+= task→period

task→current skip value=1 Put task into waiting list

*/\*checking waiting list in order to release tasks\*/ while* (task=next(waiting list)=*not*(∅)) *if* (task→release time>t)

> Pull task from waiting list Put task into red ready list

Compute EDL\_schedule

Pull task from waiting list Put task into blue ready list

*if* ((blue ready list=*not*(∅)) and (f\_EDL(t)!=0))

Pull task from red ready list Put task into waiting list

*/\*checking red ready list in order to suspend task\*/ while* (task=next(red ready list)=*not*(∅))

task→current skip value+=1

*if* (blue ready list=∅)

*if* (f\_EDL(t)!=0) */\*blue task release\*/*

*if* (task→release time+task→critical delay<t)

*if* ((task→current skip value < task→max skip value)

*begin*

### **3.2 The RLP algorithm**

BWP executes blue instances in background beside red ones. Processor time is often wasted due to the abortion of uncompleted blue instances that have reached their deadlines. Figure 4 shows that task *T*<sup>2</sup> is aborted at time *t* = 36. This leads to 8 units of wasted processor time.

### **3.2.1 Algorithm description**

The *Red tasks as Late as Possible (RLP)* algorithm (Marchand & Chetto, 2008) brings forward the execution of blue instances so as to enhance the actual QoS (*i.e.,* the total number of successful executions). From this perspective, RLP runs as follows:


Figure 6 gives the pseudo-code of the RLP algorithm. RLP maintains three task lists which are sorted in increasing order of deadline: *waiting list*, *red ready list* and *blue ready list*.


At every instant *t*, the scheduler performs the following actions:


The main idea of this approach is to take advantage of the slack of red instances. The determination of the latest start time for every red instance requires preliminary construction of the schedule by a variant of the EDL algorithm taking skips into account (Marchand & Silly-Chetto, 2006). We assume in the EDL schedule established at time *τ* that the instance following immediately a blue one - which is part of the current periodic instance set at time *τ* - is red. Indeed, none of the blue instances is guaranteed to complete within its deadline.

We proved in (Silly, 1999) that the online computation of the slack time is required only at instants which corresponds to the arrival of a request while no other is already present on the machine. The EDL sequence is constructed here not only when a blue instance is released - and no other one was already present - but also after a blue task completion, if blue tasks remain in the system. The next task instance of the completed blue task has then to be considered as a blue one. Note that blue instances are executed in the EDL idle times with the same importance as red instances, contrary to BWP which always assigns higher priority to red instances.

*Algorithm RLP*(t : current time)

```
begin
  /*checking blue ready list in order to abort tasks*/
  while (task=next(blue ready list)=not
                                          (
                                           ∅))
       if (task
               →release time+task
                                    →critical delay
                                                     <t)
         break
       endif
       Pull task from blue ready list
       task
           →release time+= task
                                   →period
       task
           →current skip value=1
       Put task into waiting list
  endwhile
  /*checking waiting list in order to release tasks*/
  while (task=next(waiting list)=not
                                       (
                                        ∅))
       if (task
               →release time
                              >t)
         break
       endif
       if ((task
                →current skip value
                                      < task
                                              →max skip value)
       and (f_EDL(t)=0))
         /*red task release*/
         Pull task from waiting list
         Put task into red ready list
       else
         if (blue ready list=
                              ∅
                               )
            Compute EDL_schedule
         endif
         if (f_EDL(t)!=0)
            /*blue task release*/
            Pull task from waiting list
            Put task into blue ready list
         endif
       endif
       task
           →current skip value+=1
  endwhile
  if ((blue ready list=not
                           (
                            ∅)) and (f_EDL(t)!=0))
       /*checking red ready list in order to suspend task*/
       while (task=next(red ready list)=not
                                              (
                                               ∅))
         Pull task from red ready list
         Put task into waiting list
```

```
endif
end
```
8 Will-be-set-by-IN-TECH

BWP executes blue instances in background beside red ones. Processor time is often wasted due to the abortion of uncompleted blue instances that have reached their deadlines. Figure 4

The *Red tasks as Late as Possible (RLP)* algorithm (Marchand & Chetto, 2008) brings forward the execution of blue instances so as to enhance the actual QoS (*i.e.,* the total number of successful

• if no blue instance waits for execution, red instances execute as soon as possible according

• else (i.e. at least one blue instance is ready for execution), blue instances execute as soon as possible according to EDF scheduling (note that it could be according to any other scheduling heuristic), and red instances are processed as late as possible according to EDL.

Figure 6 gives the pseudo-code of the RLP algorithm. RLP maintains three task lists which are

1. it updates all the three lists: instances may be released or aborted according to their current

The main idea of this approach is to take advantage of the slack of red instances. The determination of the latest start time for every red instance requires preliminary construction of the schedule by a variant of the EDL algorithm taking skips into account (Marchand &

following immediately a blue one - which is part of the current periodic instance set at time

We proved in (Silly, 1999) that the online computation of the slack time is required only at instants which corresponds to the arrival of a request while no other is already present on the machine. The EDL sequence is constructed here not only when a blue instance is released - and no other one was already present - but also after a blue task completion, if blue tasks remain in the system. The next task instance of the completed blue task has then to be considered as a blue one. Note that blue instances are executed in the EDL idle times with the same importance as red instances, contrary to BWP which always assigns higher priority to red


*t* belongs to an EDL idle time, it selects the first instance in the blue ready list for

*t*, the scheduler performs the following actions:

execution. Otherwise it selects the first instance in the red ready list.

Silly-Chetto, 2006). We assume in the EDL schedule established at time

= 36. This leads to 8 units of wasted processor time.

, *red ready list* and *blue ready list*

.

*τ* that the instance

*τ*

*t*

**3.2 The RLP algorithm**

**3.2.1 Algorithm description**

to the EDF scheduling rule.

*T*<sup>2</sup> is aborted at time

executions). From this perspective, RLP runs as follows:

sorted in increasing order of deadline: *waiting list*

state (i.e. waiting or ready red/blue instances),

• *waiting list*: list of instances waiting for their next release, • *red ready list*: list of red instances ready for execution, • *blue ready list* : list of blue instances ready for execution.

shows that task

At every instant

2. if

instances.

Fig. 6. RLP scheduling algorithm

*endwhile*

in the Firm Real-Time Systems 11

Quality of Service Scheduling in the Firm Real-Time Systems 201

the blue instance set at time *τ*. The value *ci*(*τ*) is called *dynamic execution time* and represents the remaining execution time of *Bi* at *τ*. B(*τ*) is ordered such that *i* < *j* implies *di* ≤ *dj*.

Theorem 2 presents the acceptance test of blue instances within a system involving RLP skippable tasks. This test is based on theoretical results established in (Silly-Chetto et al., 1990) for the acceptance of sporadic requests that occur in a system composed of non-skippable

**THEOREM 2.** *Instance B is accepted if and only if, for every instance Bi* ∈ B(*τ*) ∪ {*B*} *such that*

<sup>T</sup> (*τ*)(*τ*, *di*) <sup>−</sup>

*δi*(*τ*) is called *slack of instance Bi at time τ*. It defines the maximum units of time during which

that the processor is idle in the time interval [*τ*, *di*]. The total computation time required by

*<sup>p</sup>* �*n* + *blue*(*τ*)) in the worst-case, where *n* is the number of periodic tasks, *R* is the longest deadline and *p* is the shortest period. *blue*(*τ*) denotes the number of blue instances at time *τ* whose deadline is greater or equal to the deadline of *Bi*. A specific updating of additional data structures with slack tables may reduce the complexity to *O*(*n* + *blue*(*τ*)) as proved in

Figure 8 gives an illustration of RLP/T scheduling for the periodic task set T defined in Table 1. Clearly, RLP/T improves on both RLP and BWP. Only three deadline violations relative to blue instances are observed: at instants *t* = 36 (task *T*3), *t* = 54 (task *T*2) and *t* = 72 (task *T*3). The acceptance test contributes to compensating for the time wasted in starting the execution of blue instances which are not able to complete before deadline. The blue instance *T*<sup>2</sup> released at time *t* = 36 is aborted at time *t* = 54 – 8 units of time were indeed wasted – in the RLP case (see Figure 7). This rejection performed with RLP/T permits us to save time recovered for the successful completion of the blue instance *T*<sup>1</sup> released at time *t* = 48.

We report part of a performance analysis composed of three simulation experiments in order

*<sup>j</sup>*=<sup>1</sup> *cj*(*τ*). The acceptance test is based on the computation of EDL idle times which gives the slack of any blue instances. Then, this slack is compared to zero. The acceptance test runs in

*i* ∑ *j*=1

T (*τ*)

*cj*(*τ*) (6)

(*τ*, *di*) denotes the total units of time

*δi*(*τ*) = Ω*EDL*

periodic tasks.

*<sup>O</sup>*(� *<sup>R</sup>*

(Tia et al., 1994).

**3.3.3 Illustrative example**

**4. Performance analysis**

We successively measure:

to evaluate RLP/T with respect to RTO, BWP and RLP.

• *the QoS* (i.e. the ratio of instances that complete within their deadline), • *the CPU wasted time ratio* (i.e. the percentage of useless processing time),

**4.1 Simulation details**

*di* ≥ *d, we have δi*(*τ*) ≥ 0*, with δi*(*τ*) *defined as:*

blue instances within [*τ*, *di*] is given by ∑*<sup>i</sup>*

*Bi* could be delayed without violating its deadline. Ω*EDL*

## **3.2.2 Illustrative example**

Consider the periodic task set T defined in Table 1. The relating RLP scheduling is illustrated in Figure 7. The number of deadline misses has been reduced to four. Missed deadlines occur at instants *t* = 36 (task *T*3), *t* = 54 (task *T*2) and *t* = 72 (tasks *T*<sup>1</sup> and *T*3). Observe that the first blue instance *T*<sup>2</sup> which failed to complete within its deadline under BWP scheduling (see Figure 4) has enough time to succeed under RLP scheduling. The execution of the first red instances of *T*<sup>1</sup> and *T*<sup>0</sup> is postponed. Red instances are scheduled as soon as possible until time *t* = 12 and execute as late as possible in the presence of blue instances from time *t* = 12 up to the end of the hyperperiod. This enhances the actual QoS of periodic tasks.

Fig. 7. A schedule produced by the RLP scheduling algorithm (*si* = 2)
