• No results found

In addition to applying the ILP based task allocation approaches we considered how the requirements of the case study measure up in a uni-processor fixed priority context. We began by considering the number of cores required for its execution and how this can be investigated using speed-up factors. Speedup, also known as Amdahl’s argument [68], is a means of assessing how fast a single processor would need to be in order to schedule a set of tasks designed for a multi-core. This section describes how this initial work developed.

We considered the example system model as the task set shown in Table 6.3, which represents the original values provided, with no C(LO) or C(HI) differenti- ation. C T/D L I/O_1 4.5 20 HI I/O_2 1 20 HI I/O_3 1 20 HI I/O_4 6 40 HI I/O_5 6 40 HI I/O_6 6 40 HI I/O_7 2 20 HI I/O_8 0.5 40 HI I/O_9 0.25 80 HI P_1 1.5 20 HI P_2 0.5 20 HI P_3 1 20 HI P_4 4 20 HI P_5 2 20 HI P_6 3 20 HI PL_1 6 20 LO PL_2 3 20 LO PL_3 20 80 LO I/OL_1 17 40 LO SYS 0.25 40 LO

Table 6.3: Case Study: Original Model (no criticality levels).

This initial task set does not include differing values for LO WCETs of HI criti- cality tasks. We ran this task set through the AMCrtb [15] schedulability test and reduced the original WCET values until schedulable to determine the speed-up factor.

S = C(Old)

C(N ew) (6.1)

S(I/O_1) = 4.5

1.71 (6.2)

The speedup factor S is calculated by dividing the Old WCET (originally from Table 6.3) by a new reduced value. All tasks are reduced by the same % until schedulable, once schedulable the speedup factor can be determined. The result is a speed-up factor of 2.63, given that this system is designed to run on three 1.2 Ghz CPUs we can calculate the frequency required of a single core to run the system.

1.2 × 2.63 = 3.156 (6.3)

In this case the system would require a CPU running at 3.16 Ghz to schedule on a single processor.

As we are dealing with a mixed criticality system, the HI criticality tasks should be given a LO WCET derived from the provided HI WCETs. As this reduction was not defined for us (although an estimate of 80% was confirmed to be reasonable) we began investigating the impact of reducing the LO WCET as a % of the HI to attempt to reduce the speedup factor. Given the task set in Table 6.1 which provides LO WCET values for HI criticality tasks calculated as 80% of their HI WCETs, we apply the same speedup factor technique. We reduce the WCETs (both LO and HI) of each task by the same % until the system is schedulable. The resulting speedup factor is 2.33 which required a 2.79Ghz uni-processor to schedule all tasks.

As well as considering the case above, we also considered the speedup factor when the LO tasks were assumed to be 90%, 70% , 60% and 50% of the origi- nal WCET. The resulting speedup factors and the required speed of the CPU to schedule the task set are shown in Table 6.4.

LO % of HI 100% 90% 80% 70% 60% 50%

Speedup Factor 2.63 2.5 2.33 2.17 2.04 1.89

Req CPU Speed (GHz) 3.16 3 2.79 2.61 2.45 2.26

Table 6.4: Case Study: Speedup Factors.

In addition, the results from Table 6.4 as plotted in Figure 6.6:

50 55 60 65 70 75 80 85 90 95 100

C(LO) % of C(HI)

1.8 1.9 2 2.1 2.2 2.3 2.4 2.5 2.6 2.7

Speedup Factor

Optimised

Figure 6.6: Speedup Graph.

We illustrate here how mixed criticality functionality makes a big difference in the overall average system load.

This analysis presents a simplified look at the schedulability of the system on a single processor. We can make two main points. Firstly, this work shows that by providing smaller LO criticality WCETs for HI criticality tasks it is possible to reduce the speedup factor by a significant amount (0.3 from 100% to 80%). Secondly, it is clear that the clock speed required makes it infeasible to schedule this system on a single processor in an embedded real-time scenario. Such frequencies are beyond those provided by typical embedded hardware due to high power draw and

thermal output. As such we concluded that a multi-processor approach is required.

6.4

Summary

This chapter has described and examined the mixed criticality case study provided

by BAE Systems5. We have discussed its features and how they are both similar

and different from our perception of a mixed criticality system. We have applied our ILP/MLP based task allocation techniques to schedule the case study on a multi- core cyclic executive platform. We applied task splitting to overcome a number of tasks with very large execution times. Additionally, we coupled this with two optimisations; we optimised the task set to maximise the spare capacity within the LO criticality mode and we optimised the system to reduce the number of cores used by HI criticality tasks. Finally, we make brief mention of some initial work investigating how speedup factor can be used to gauge the requirements of this system if it were scheduled on a uni-processor platform.

The ability to apply our tools and techniques to a real world example case study is an invaluable step. Not only do we establish how our tools perform given genuine task data, but we also gain understanding as to how they may be best used to support future expansion of the system.

Chapter 7

Conclusion

7.1

A return to the thesis hypothesis

We return to the thesis hypothesis:

Mixed Criticality Cyclic Executives provide an attractive platform for highly criti- cal near-future systems. The challenge of allocating tasks to the platform, providing support for design and aiding in allocation optimisation can be achieved through the use of Linear Programming.

We have illustrated how merging the deterministic Cyclic Executive with the flexibility of mixed criticality functionality provides an attractive platform for near fu- ture mixed criticality applications. Fundamentally, we retain a familiar scheduling paradigm and extend it to encompass additional functionality, rather than starting from scratch. As such legacy applications designed to run on cyclic executive systems could be ported to a mixed criticality cyclic executive with minimal diffi- culty. Meanwhile, newer applications, perhaps those able to utilise multi-threaded workloads, are able to execute alongside due to the complete separation provided between criticality levels. Proving the isolation of higher criticality work is simple as it always executes before lower criticality work. While the classic problems of cyclic executives are not removed with this work, the mixed criticality approach allows for greater leverage of the platform resources under typical execution.

in the allocation of tasks to mixed criticality cyclic executives. The tools provided in both the standard allocation and the more complex splitting and optimisation functionality are intended as a means to aid system design. It may be best used as part of a design process, allowing the system designer to quickly discover how to adjust the parameters of their system, or to discover where additional capacity might lie to introduce more functionality. Linear Programming optimisation provides a large number of parameters which may be adjusted to allow the system designer to ask questions about the allocation and design of their system.

Related documents