Migration Models

For a four-core platform, if only one core enters HI-crit mode, the migration tasks have three possible cores to migrate towards. We propose three models based on the distribution of these migration tasks.

• Model 1 represents the model that all migration tasks migrate to one core. • Model 2 represents the model that all migration tasks migrate to two cores. • Model 2a represents a varient on Model 2 (see description below).

• Model 3 represents the model that all migrate tasks migrate to three cores. The following subsection will introduce the details of these models, including the relationship among cores and how the migration tasks are divided to migrate to different cores. Note for this 4-core system, mode changes on less than or equal to two cores must be tolerated without the loss of scheduling.

Model 1

Model 1 is a naive model that migration tasks on each core may only migrate to one core. The model can be viewed as Figure 4.1, where the rectangles stand for cores and arrows stand for migration routes.

Figure 4.1: Model 1

According to the figure above, the migration routes form a circle which indicates that it is always possible to find an available core (a core that still in LO-crit mode) following the routes. Figure 4.2 and Figure 4.3 indicate two example scenarios of Model 1. The core in grey indicates that this core is currently in HI-crit mode; the thin arrow indicates a load of tasks migrate from one core to another; the thick arrow indicates different steps of the scenarios (the left hand side of the arrow is step 1 while the right hand side is step 2).

Based on these scenarios, the migrating load seems to be the main issue of Model 1. In Step 2 of Scenario 1 and Scenario 2, an extremely heavy task load is migrated to Core c4 while no task migrates to Core c3, which will undoubtedly

affect the schedulability of the model. Based on this observation, the issue of this model lays on the heavy migration load during the second migration progress.

Figure 4.2: Model 1 Scenario 1

1. Core c1 enters HI-crit mode, all of the migratable tasks on Core c1 will

migrate to Core c2.

2. Core c2enters HI-crit mode, all of the migratable tasks on Core c2, including

tasks migrated from Core c1, will migrate to Core c4.

Figure 4.3: Model 1 Scenario 2 Model: Scenario 2 (Figure 4.3)

1. Core c2 enters HI-crit mode, all of the migratable tasks on Core c2 will

migrate to Core c4.

2. Core c1 enters HI-crit mode, all of the migratable tasks on Core c1 will

migrate to Core c2. But since Core c2 is already in HI-crit mode, these

migrating tasks will migrate to Core 4 directly.

Model 2

This model allows migration tasks to migrate to two cores rather than one. This increment of the migrating destinations leads to two issues: how to decide which two cores to migrate to and how the migration tasks shall be divided. Regarding

to the first issue, Model 2 pairs cores into four groups: (Core c1, Core c2), (Core

c1, Core c3), (Core c2, Core c4) and (Core c3, Core c4). Each core has two

group-mate cores and migration tasks originally on the core will only migrate to the group-mate cores if they are available. For example, Core c1 is paired with

Core c2 and Core c3. If Core c1 enters HI-crit mode, all of the migratable tasks

on Core c1 will migrate to Core c2 and Core c3. The model can be viewed as

Figure 4.4.

Figure 4.4: Model 2

Figure 4.5: Model 2 Scenario 1 Model: Scenario 1 (Figure 4.5)

1. Core c1 enters HI-crit mode, migratable tasks on Core c1 will split into two

parts and migrate to Core c2 due to the pairing relationship (Core c1, Core

c2) and Core c3 due to the pairing relationship (Core c1, Core c3).

2. Core c2 enters HI-crit mode, all of the migratable tasks originally on Core

c2 will migrate to Core c4 due to the pairing relationship (Core c2, Core

c4), and all of the migratable tasks from Core c1 will migrate back to Core

c1. But since Core c1 is already in HI-crit mode, these tasks will migrate

to Core c3. (In practice, these tasks will directly migrate to core c3.)

Figure 4.6: Model 2 Scenario 2

1. Core c1 enters HI-crit mode, all of the migratable tasks on Core c1 will split

into two parts and migrate to Core c2 due to the pairing relationship (Core

c1, Core c2) and Core c3 due to the pairing relationship (Core c1, Core c3).

2. Core c4 enters HI-crit mode, all of the migratable tasks on Core c4 will split

into two parts and migrate to Core c2 due to the pairing relationship (Core

c2, Core c4) and Core c3 due to the pairing relationship (Core c3, Core c4).

The split here (and following ones used in other models) is actually using WF bin-packing algorithm to assign the migratable tasks to other available cores. The reason to use WF algorithm is that WF provides a more balancing task distribution than other bin-packing algorithms.

Model 2a

This model is a possible variant on Model 2, but later on we will show that this model is dominated by Model 2. In Model 2a, cores are also paired into several groups and only tasks between groups may migrate to each other. The difference between this model and Model 2 is that this model migrates the whole migratable tasks to one paired core rather than splits the task load and migrates to two paired cores. For example, assume that Core c1 is paired with Core c2 and

Core c3. If Core c1 enters HI-crit mode, all of the migratable tasks on Core c1

will migrate to Core c2 due to the pairing relationship (Core c1, Core c2). Then

if Core c2 also enters HI-crit mode, all of the migratable tasks from Core c1 shall

migrate to Core c3 due to the pairing relationship (Core c1, Core c3), while the

the pairing relationship for Core c2. The model can be viewed as Figure 4.4.

Figure 4.7: Model 2a

From the figure, the cores are paired into four groups: (Core c1, Core c2),

(Core c1, Core c3), (Core c2, Core c4) and (Core c3, Core c4). Based on that,

there are two possible scenarios:

Figure 4.8: Model 2a Scenario 1 Model: Scenario 1 (Figure 4.8)

1. Core c1 enters HI-crit mode, all of the migratable tasks on Core c1 will

migrate to Core c2 due to the pairing relationship (Core c1, Core c2).

2. Core c2 enters HI-crit mode, all of the migratable tasks originally on Core

c2 will migrate to Core c4, while all of the migratable tasks from Core c1

will migrate to Core c3.

Figure 4.9: Model 2a Scenario 2 Model: Scenario 2 (Figure 4.9)

1. Core c1 enters HI-crit mode, all of the migratable tasks on Core c1 will

migrate to Core c2 due to the pairing relationship (Core c1, Core c2).

2. Core c4 enters HI-crit mode, all of the migratable tasks on Core c4 will

migrate to Core c3 due to the pairing relationship (Core c3, Core c4).

Although this model looks quite similar to Model 2, there exists a problem that the migration task load may be quite heavy in certain scenarios, for instance, step 2 in Scenario 1. A detailed explanation on why Model 2a is dominated by Model 2 will be given in the Section 4.2.2.

Model 3

Model 3 is a quite different model from all of the previous ones. In this model, tasks are allowed to migrate to all of the cores currently in the LO-crit mode. Figure 4.10 shows how Model 3 may be viewed as.

Figure 4.10: Model 3

As shown in the figure, migratable tasks can migrate to all of the cores which makes a maximum usage of the computation ability of the system. Here is a possible scenario of Model 3:

Figure 4.11: Model 3 Scenario 1 Model: Scenario 1 (Figure 4.11)

1. Core c1 enters HI-crit mode, all of the migratable tasks on Core c1 will split

and migrate to all other cores in LO-crit mode (Core c2, Core c3 and Core

c4).

2. Core c2 enters HI-crit mode, all of the migratable tasks on Core c2 will split

and migrate to all other cores in LO-crit mode (Core c3 and Core c4)