Attacking the one-out-of-m multicore problem by combining hardware management with mixed-criticality provisioning

Abstract

The multicore revolution is having limited impact in safety-critical application domains. A key reason is the “one-out-of-m” problem: when validating real-time constraints on an m-core platform, excessive analysis pessimism can effectively negate the processing capacity of the additional $m-1$ cores so that only “one core’s worth” of capacity is utilized even though m cores are available. Two approaches have been investigated previously to address this problem: mixed-criticality allocation techniques, which provision less-critical software components less pessimistically, and hardware-management techniques, which make the underlying platform itself more predictable. A better way forward may be to combine both approaches, but to show this, fundamentally new criticality-cognizant hardware-management tradeoffs must be explored. Such tradeoffs are investigated herein in the context of a new variant of a mixed-criticality framework, called $\textsf {MC}^\textsf {2}$, that supports configurable criticality-based hardware management. This framework allows specific DRAM memory banks and areas of the last-level cache (LLC) to be allocated to certain groups of tasks. A linear-programming-based optimization framework is presented for sizing such LLC areas, subject to conditions for ensuring $\textsf {MC}^\textsf {2}$ schedulability. The effectiveness of the overall framework in resolving hardware-management and scheduling tradeoffs is investigated in the context of a large-scale overhead-aware schedulability study. This study was guided by extensive trace data obtained by executing benchmark programs on the new variant of $\textsf {MC}^\textsf {2}$ presented herein. This study shows that mixed-criticality allocation and hardware-management techniques can be much more effective when applied together instead of alone.

Appendices

Appendix 1: Overhead accounting

In our schedulability study, to account for implementation-related overheads beyond those discussed in Sect. 5.2, we applied several existing overhead-accounting techniques (Brandenburg 2011). While a complete, formal description of all techniques is beyond the scope of this paper, in what follows, we give a high-level description of the techniques employed, and highlight the most relevant ideas. We account for all overhead sources through PET inflation, i.e., increasing the PET of each task before evaluating schedulability. In addition to CRPDs, we considered the following overhead sources, defined in Brandenburg (2011): context switching, release latency, timer ticks, scheduling, job release, and inter-processor interrupts (IPIs).

To account for these overheads, we applied techniques pioneered by Brandenburg (2011) for PEDF and GEDF, for Level B and Level C, respectively, with minor modifications to account for interactions among criticality levels in $\textsf {MC}^\textsf {2}$. When analyzing tasks at each criticality level, we used measured overheads acquired using similar assumptions as used for PETs, e.g., at Level C, average-case measured overheads were considered. Also, in the case of scheduling and release overheads, we have to account for per-core partitioned scheduling and release overheads at Levels A and B, and also global scheduling and release overheads that may be incurred on any core for Level C. Releases and IPI overheads from task migrations at Level C may cause delays at all criticality levels.

Our $\textsf {MC}^\textsf {2}$ implementation heavily uses PET budgets. The management of such budgets gives rise to a new overhead source. These overheads are incurred when a budget is replenished or depleted, and are accounted for similarly to other overheads by inflating PETs.

Appendix 2: PET-generation process

The PETs assumed in Sect. 6.1 are based on an analytical model, which we derived by distilling the measured execution-time data discussed in Sect. 4. This appendix describes this PET-generation model in greater detail. As described in Sect. 6.1, all PETs required in our schedulability experiments are defined based on EDF-scheme PETs, which correspond to A-inflated WCETs in an idle system with the full LLC allocated to the task in question. We denote this WCET parameter as $C_i^0$ for task $\tau _i$. In our experimental framework, the $C_i^0$ values are obtained implicitly from the randomly generated task utilizations and periods. All execution-time values used to obtain all other PETs for $\tau _i$ for different isolation and analysis assumptions are listed in Table 4. Table 5 shows how these values are used to define all PETs under each scheme. The columns of Table 4 indicate how each execution-time value is defined (i.e., whether the value is a Level-A-inflated WCET, a non-inflated WCET, or an ACET, whether the system is assumed to be under load or idle, etc.). Each of these values is generated by applying scaling factor(s) to the prior-listed execution-time values. We present an overview of this entire process here.

Table 4 Generated PET values

Step 1: Generate $C_i^1$ by scaling $C_i^0$ to account for interfering workload. We choose $C_i^1$ uniformly from [120, 150)% of $C_i^0$, based on WCET measurement data in idle and loaded systems with the full LLC allocation.

Table 5 Assignment of execution time parameters to PETs

Step 2: Generate $C_i^2$ by scaling $C_i^1$ for different LLC allocations. Our $C_i^0$ values are defined from generated utilizations. The process for generating such utilizations was carefully defined to produce trends similar to those seen from measurement data. Since our $C_i^1$ values are simply scaled versions of our $C_i^0$ parameters, similar utilization trends will be seen when utilizations are defined in terms of $C_i^1$ values. Figure 23 illustrates typical generated utilizations. As seen in this figure, task utilizations monotonically decrease with increasing LLC space and converge at the ICAS. This is in accordance with Obs. 2. To reflect this, we obtain $C_i^2$ values for different LLC-allocation choices by applying a scaling factor to $C_i^1$ that exponentially increases with the minimum of the ICAS and LLC space. The actual scaling factors employed were selected to reflect measurement data.

Fig. 23

Utilizations generated under different LLC allocations for three example tasks

Task ICASs were deduced using the Load Time parameter in Table 2. The two both hinge on a task’s cache footprint. Our Load Time parameter was defined to reflect Obs. 1, which showed that cache isolation can improve a task’s WCET by up to 369%. For example, when the Light Load Time distribution is assumed, LLC isolation typically reduces WCETs by 20–50%, while when the Heavy distribution is assumed, the reduction is typically 200–500%. In addition, for all parameter combinations, tasks at Levels A and B tend to be more insensitive to LLC space than those at Level C. This reflects the underlying motivation for $\textsf {MC}^\textsf {2}$ that Level-A and -B tasks will tend to be rather deterministic fly-weight tasks and that Level-C tasks will tend to be more complex data-intensive tasks (see Sect. 2).

Step 3: Generate $C_i^3$ by scaling $C_i^2$ to account for shared DRAM banks. As seen in Fig. 7, the impact of DRAM bank isolation on task execution times tended to range from imperceptible to 20% under small LLC allocations. Based on these results, we uniformly choose $C_i^3$ to be [100, 130)% of $C_i^2$ to account for the lack of bank isolation. Similar to the last step, this step is affected by the task ICAS and LLC allocation.

Step 4: Generate $C_i^4$ from $C_i^3$ based on known worst-case shared-cache behavior. When sharing a cache, cross-core interference may prevent a program from reusing any data in any shared cache blocks, thus eliminating any benefit from the LLC in the worst case. Therefore, we define $C_i^4$ to equal $C_i^3$ for the case when the allocated LLC space is zero.

Step 5: Generate all Level-B PETs from previously generated Level-A PETs. Using the A-Inflation Factor in Table 2, all Level-B PETs can be computed from corresponding Level-A PETs. This gives us all $C_i^5$ values.

Step 6: Generate $C_i^6$ and $C_i^7$ to reflect expected ACET:WCET ratios under cache isolation and varying background workloads. ACET:WCET ratio trends will depend on the given background workload, i.e., the total utilization of all competing tasks. Based on ACET:WCET ratio trends observed for benchmark and synthetic programs under different background workload utilizations, we identified an appropriate distribution from which to uniformly choose an ACET:WCET ratio for each task. For all tasks, these ratios were chosen uniformly among a range of percentages. For Level-C tasks, these ratios range over 20–40% for the lightest background workloads, and over 30–60% for the heaviest. For Level-A and -B tasks, these ratios range over 50–70% for the lightest background workloads, and 80–100% for the heaviest. This reflects our assumption that higher-criticality tasks tend to be more deterministic in their execution than Level-C tasks. Note that this process requires a means to calculate the Level-C utilization of a background-workload, which is dependent on the ACETs that are generated. This entails an iterative process, such as that in Fig. 24a.

Fig. 24

Two methods for calculating ACETs in Step 6

However, given the scale of our schedulability experiments, which involved millions of task systems, an iterative process was infeasible. As a result, we used the non-iterative process outlined in Fig. 24b. We used the EDF-scheme utilization of the background workload as an upper bound on its average-case utilization.

Step 7: Generate $C_i^8$ to reflect differences between ACETs for a fully unmanaged system and ACETs for a cache-isolated system. From Fig. 7 and Obs. 8, we see that ACETs in an unmanaged cache gradually decline in a linear fashion as the allocated LLC space increases, even beyond the ICAS of the task. However, these ACETS generally remain higher than ACETs under cache isolation. When the LLC allocation is zero, both ACETs are the same, since LLC management does not affect tasks bypassing the LLC. To reflect this behavior, we generated $C_i^8$ as shown in Fig. 25. On the right axis, we depict a scale showing the range of $C_i^7$’s reduction in value as the allocated LLC space increases. On this scale, $C_i^7$ is at 0% reduction under zero allocated LLC space, and 100% under maximum allocated LLC space. $C_i^8$ at maximum allocated LLC space for the Matrix program would fall at approximately 50% on this scale. For each generated task, we choose a value from 30 to 70% on this scale for our generated $C_i^8$ at maximum LLC space.

Fig. 25

Comparison of $C_i^7$ and $C_i^8$ for a generated task

At zero allocated LLC space, $C_i^8$ matches $C_i^7$. For all other LLC allocation sizes, we interpolate values for $C_i^8$ linearly between values generated for zero allocated LLC space and maximum allocated LLC space.

From these steps, we now have all required PETs. We note once again that this process produces a model for producing PETs. As such, all claims resulting from our schedulability experiments apply only within the context provided by this model. Still, we have taken great pains to ensure that the range of PETs generated by this model encompass those that we have seen based on real measurement data, and that trends among related PETs for the same task correspond to those seen in our measurement data.