General Algorithm

Regarding to a n-core platform, the boundary number is dlog2(n)e. There exist

two different situations: n is an even number or n is an odd number. If n is an even number, then there exists an integer k such that n = 2 × k. In order to apply Model 2, the cores in the system require to be paired so that each core has dlog2(n)e paired mates. By applying the clone algorithm, the pairing relationship

of the n-core platform can be generated by finding the pairing relationship of a k-core platform where the boundary number is dlog2(n)e−1 = dlog2(2×k)e−1 =

log2(2) + dlog2(k)e − 1 = dlog2(k)e. Thus, finding the pairing relationship of a

k-core platform will solve the pairing problem for this n-core platform.

If n is an odd number, then there exists an integer k0 such that n = 2 × k0− 1. Similar to the previous scenario, in order to apply Model 2, the cores in the system require to be paired so that most cores have dlog2(n)e paired mates. By applying

the modified clone algorithm, the pairing relationship of the n-core platform can be generated by finding the pairing relationship of a k’-core platform where the boundary number is dlog2(n)e − 1 = dlog2(2 × k0− 1)e − 1 = log2(2) + dlog2(k0)e −

1 = dlog2(k0)e. Thus, finding the pairing relationship of a k0-core platform will

solve the pairing problem for this n-core platform. In all, the pairing relationship of a n-core platform can be generated by a recursion usage of the clone algorithm

and the modified clone algorithm. When the pairing relationship between cores is settled, migratable tasks may be split into the boundary number of groups and migrate to the paired cores when required by the system.

4.4

Summary

This chapter has explored the semi-partitioned model on a multi-core platform. It first addresses the boundary number determination problem by the use of a probability calculation. In consideration of easier usage, it is proposed that dlog2(n)e shall be used as the boundary number for an n-core system. That is,

for a n-core system, all tasks shall remain schedulable if no more than dlog2(n)e

cores enter HI-crit mode. This chapter then explores the task allocation problem on a four-core platform. Four task allocation models are proposed and analysed by response time analysis and experiments. According to the results observed and the consideration of calculation complexity, it is suggested that Model 2, which splits the migration task load within paired cores, will be the most appropriate task allocation model for a four-core system. In addition, this chapter has provided an iterative algorithm to manipulate a possible pairing relationship for an n-core platform to apply Model 2. In the previous chapter, we illustrate that the combination usage of Semi2WF and Semi2FF provides the best scheduling performance for a dual-core platform. In other words, when the migration source core and the migration destination core are fixed, Semi2 algorithm is an appropriate approach to determine which task to be migratable. Based on that, we propose an appropriate semi-partitioned model for a n-core system as:

• Each core is paired with dlog2(n)e cores.

• Semi2 approach is used to determine which LO-crit tasks shall be migrat- able.

• If Core ci enters HI-crit mode and the total number of the cores in HI-

“equally” (by the use of WF bin-packing algorithm) to the paired cores which are still in LO-crit mode. All tasks guarantee their executions. • If Core ci enters HI-crit mode and the total number of the cores in HI-crit

mode is more than dlog2(n)e, all LO-crit tasks on Core ciwill be abandoned.

Chapter 5

Extended NoC Version with

More Criticality Levels

The previous chapters have introduced appropriate approaches to schedule tasks in a multi-core platform with two criticality levels. However, the result has assumed that the migration costs between different cores are the same. In this chapter, we will extend the model to multi-criticality levels. In addition, we will explore the system architecture influence on the semi-partitioned model.

This chapter will first discuss the influence from increasing the number of criticality levels, and propose how the model can be extended. Then it will discuss the effects of considering the migration difference between cores and provide a detailed analysis of the issues when extending the semi-partitioned model to Network-on-Chip-based multi-core platforms (NoC for short). Then, this chapter will introduce a new model for scheduling tasks on a multi-core NoC system with three criticality levels. An experiment is set up to show how the semi-partitioned model outperforms the non-migration model. An evaluation will be made at the end.

5.1

Extend Criticality Levels

This section will focus on extending the semi-partitioned model to more than two criticality levels. The direct influence from increasing the number of criticality levels is that each task has more WCET estimations for different criticality levels. In a system with n criticality levels, each task shall have n WCET estimations for different levels by definition. Thus, scheduling such a system will be quite complicated. In order to ease the calculation capacity and the complexity of the model, we adopt a model that only uses two WCET estimations for each task ([29],[76]). One is the WCET estimation at the lowest criticality level, while the other is the WCET for the task at its own criticality level. Take a three criticality system (LO < M ID < HI) as an example, we may get the following performances based on this model:

• All of the tasks execute with their LO-crit budgets by default.

• If a MID-crit task exceeds its LO-crit budget, then the system will enter MID-crit mode, in which all of the MID-crit tasks will execute with their MID-crit budgets, while LO-crit tasks and HI-crit tasks will still execute with their LO-crit budgets.

• If a HI-crit task exceeds its LO-crit budget, then the system will enter HI-crit mode, in which all of the HI-crit tasks will execute with their HI- crit budgets, MID-crit tasks will execute with their MID-crit budgets, and LO-crit tasks will still execute with their LO-crit budgets.

According to this behaviour, it can be observed that tasks with the lowest criticality level will only have one WCET estimation. For other tasks, if the task exceeds its WCET budget for the lowest criticality level, it will execute with the other WCET estimation and the system will increase to the criticality level of that task. Due to that, the change of the criticality level of a core may skip the middle levels. For example, the core may increase directly from LO to HI when a HI-crit task exceeds its LO-crit budget. In addition, tasks will still be executing

with their own criticality budgets if the system is executing in a higher criticality level. In all, a general model for a core with n criticality levels (0 represents the lowest level and n represents the highest level) can be generated as following:

• All tasks execute with their WCETs for criticality level 0 (C(0)) by default. • No task may exceed its own criticality budget.

• If task τi with Li > 0 exceeds its 0-crit budget (Ci(0)), the system will

enter Li-crit mode and task τi will execute with its own criticality budget

Ci(Li). If task τk has a smaller or equal criticality level (Lk ≤ Li), it will

execute with its highest criticality level budget (Ck(Lk)); otherwise, it will

still execute with the lowest criticality budget (Ck(0)).

• No task is abandoned.