Progress Categorisation

Given the progresses of all running VMs, the next step is to categorise them into different groups, each of which is handled differently. This process, which is named progress categorisation, will be discussed in this section.

Based on a current execution progress, a VM can be put into one of the following categories:

• IDLE: instance that does not have any workload to execute.

• CAN_RECEIV E: instance that has remaining workloads to execute but can receive extra ones.

• NOT_RECEIV E: instance that has finished executing current workloads and must start executing the next ones immediately, so it cannot receive an extra workload. • NOT_GIV E: instance that is executing the last task of its current workload so it cannot

give any workload.

• V IOLAT ING: instance that is predicted to violate the deadlines of its current workload. • CAN_GIV E: instance that is executing its current workload and is predicted to not

violate a deadline but can still give workload if possible.

In terms of reassignment, instances in categoriesIDLE andCAN_RECEIV E can receive extra tasks, i.e. new workloads from those of categoryV IOLAT INGandCAN_GIV E.

Algorithm 6.1 presents the logic to categorise an instance based on its current progress. The inputs of the algorithm are an instance, its current workload and the number of finished tasks (denoted asnwf). The output of the algorithm is a category of an instance. Moreover,

Algorithm 6.1 also calculate the amount of time that an instance either can use to receive extra workload or need to give away in order to avoid deadline violation.

First of all, an instance needs to be checked if it has finished its current workload. This can be done by comparing the number of finished tasks to the total number of tasks assigned to a workload (Line 4). In other words, an instance has finished executing its current workload if the number of finished tasks is equal to the number of tasks assigned to a workload. On the other hand, if the number of finished tasks is less than the number of assigned tasks, a VM has not finish its execution yet. Instances are handled differently based on the fact that they finish their current workloads or not.

Categorise Finished Instances

For VMs which have finished its current execution, the next step is to check if there are any unfinished workloads assigned to them (Line 6). An instance that has no remaining workload is calledidle instanceand its label is set toIDLE (Line 7). Since each VM is charged by hour, it is possible to keep an idle instance running until the end of the nearest ATU without paying any additional cost. Hence, an idle instance is free to receive extra workload as long as it does not exceed a termination time. In other words, its available time to receive extra workload is the difference between termination time and the current time (Line 9). The idle workload is illustrated by Figure 6.1a.

On the other hand, if a VM has remaining workload(s) left, it is necessary to check the expected start time of the immediately next workload. If an expected start time is in the future, i.e. there is gap between current time and an expected start time of the next workload, it is possible for an instance to receive extra workload and its label is set toCAN_RECEIV E

(Lines 16 and 17). Its available time to receive extra workload is the difference between a start time of the next workload and the current time (Line 18), as illustrated by Figure 6.1b. However, if an expected start time is not in the future, i.e. an instance finishes its execution either on time or later than estimated, a VM, whose label isSTART_NEW, cannot receive additional workload and has to start executing the next workload immediately (Lines 13 and 14).

Algorithm 6.1Progress Categorisation

1: functionCATEGORISE(v,w,nwf)

2: LABEL NULL

3: e 0

4: ifnwf =nw then

5: An instance has finished its current execution

6: ifvhas no remaining workloadthen 7: vis idle 8: LABEL IDLE 9: e tev NOW 10: else 11: wn next workload 12: ifstwn NOW then

13: vcannot receive additional tasks

14: LABEL START_NEW

15: else

16: vcan receive additional tasks

17: LABEL CAN_RECEIV E

18: e stwn NOW

19: else

20: nr_w nw nwf 1 21: ifnr_w=0then

22: vis executing the last task

23: LABEL NOT_GIV E

24: else

25: er_w=nr_w⇥ejw,vw

26: f iu_w=NOW+er_w

27: if f iu_w>djw then

28: Possible deadline violating detected

29: LABEL V IOLAT ING

30: e f iu_w djw

31: else

32: LABEL CAN_GIV E

33: e f iuw NOW

2

Time w1

fiw₁= NOW _tev

gap v

(a) Gap of an Idle Instance

Time w1 w2 fiw₁= NOW _stw 2 gap v

(b) Gap of a Non-Idle Instance

Fig. 6.1 Gap for Receiving Extra Workload

Categorise Unfinished Instances

For instances which have not finished executing the current workloads yet, the first step is to calculate the number of remaining tasks, which is denoted asnr

w. The number of remaining

tasks can be calculated by subtracting the current workload’s total number of tasks to the number of finished tasks. Notably, since there is one task currently in execution, the result is them subtracted to one (Line 20).

If the number of remaining tasks is equal to zero, which mean an instance is executing the last task of a workload and has no task left be reassigned (Lines 22 and 23).

On the other hand, if there are tasks left to be reassigned, i.e. nr

w>0, the next step is to

calculate the remaining execution time by multiplying the number of remaining tasks to the task execution time (Line 25). Then, an updated expected finish time, denoted as f iu

w, can be

calculated by adding a remaining execution time to the current time (Line 26).

A potential deadline violation is detected if an instance is estimated to finish executing its current workload after a deadline, i.e. an updated finish time is greater than a workload’s job’s deadline (Lines 28 and 29). An instance’s label is set toV IOLAT ING. In order to resolve a violation, the goal is to reduce an execution time of a violating workload an amount of time which is equal to the difference between an updated finish time and a deadline (Line 30).

On the other hand, an instance which is not predicted to be deadline violating if an updated finish time is less than or equal to a deadline (Line 32), its label is set toCAN_GIV E. Notably, it is possible to reassign tasks from a non-violating VM in order to improve performance. For instance, given an instancev1has 10 tasks left and is predicted to not violate a deadline.

However, there is another VM v2 which can receive 5 tasks from v1. In this case, it is

estimated, thus improve an overall performance. Hence, it is beneficial to reassign at most half of the remaining execution time of this workload, if it is possible (Line 33).