Exp.4: Scalability

Methodology. We study the impact of each latency type upon increasing number of cores. We run one instance of the Synth1 workload on the core under consideration, c0, and sweep the num-

ber of co-running cores from 0 to 7. Each co-running core also executes the Synth1 workload. We measure the experimental WC latencies of c0 and delineate them in Figure3.13.

Observations. Clearly, increasing the number of cores, the increasing rate in the inter-coherence latency is much larger than that of the arbitration and intra-coherence latencies. This aligns with the analysis in Section 3.7. The inter-coherence latency is a quadratic function, while both the arbitration and intra-coherence latencies are linear functions in the number of cores. Moreover, the increasing rate of the intra-coherence latency is double that of the arbitration-latency. Fig- ure 3.13 shows that increasing the number of cores, the coherence-latency dominates the total memory latency. This emphasizes the importance of carefully considering the coherence latency impact on multi-core real-time systems upon allowing for simultaneous accesses to shared data.

0 1000 2000 3000 4000 5000 6000 1 2 3 4 5 6 7 8 WC L Num. of cores

totL interCohL intraCohL arbL accL

Figure 3.13: Latencies with different number of cores.

3.9 Summary

In this chapter, we pointed out possible sources of unpredictable behaviour on conventional co- herence protocols. To address this unpredictability, we described a set of invariants. These invariants are general and can be applied to any coherence protocol. We showed how to deploy these invariants in the fundamental MSI protocol as an example. Towards this target, we pro- posed a set of novel transient states as well as minimal architecture requirements. In addition, we integrated the coherence effects on the latency analysis for the first time. We experimented using parallel applications from the SPLASH-2 suite as well as worst-case oriented synthetic workloads.

Chapter 4

PMC: A Requirement-aware DRAM

Controller for Multi-core Mixed Criticality

Systems

We propose a novel approach to schedule DRAM requests in MCS. This approach supports an arbitrary number of CLs by enabling the MCS designer to specify memory requirements per task. It retains locality within large-size requests to satisfy memory requirements of all tasks. To achieve this target, we introduce a compact harmonic work-conserving TDM scheduler, and a framework that constructs optimal schedules to manage requests to off-chip memory. We also present a static analysis that guarantees meeting requirements of all tasks. We compare the pro- posed controller against state-of-the-art MCs using both a case study and synthetic experiments.

4.1 Introduction

As aforementioned, MCS contain a mix of tasks with different criticalities. For example, HRT tasks are latency-critical and mandate strict assurances that their temporal requirements are never violated such that their worst-case latencies should always be no greater than their deadlines. Since a violation in temporal requirements of a HRT task may result in unacceptable loss of lives, a detailed WCET analysis of the task executions on the designated hardware platform is necessary. However, to compute tight WCET estimates, the hardware platforms must be pre- dictable; thereby, leading itself to accurate WCET analysis. This means that speculative features such as out-of-order execution, complex cache hierarchies, and branch prediction are often elim- inated [67]. Contrarily, SRT tasks can be considered as non latency-critical. They require a

minimum average-case performance and memory BW. To accomplish this, hardware platforms often use architectural features such as those disallowed for the purposes of predictability. Hence, the requirements of predictability for HRT tasks and average-case performance for SRT are in conflict. This poses an increasingly difficult challenge for designers of MCS.

One response to this challenge is utilizing temporal isolation [68–70]. Temporal isolation re- quires the designer to deploy the application such that resources used by tasks with strict temporal requirements are distinct. Heterogeneous multi-cores [71] with a combination of predictable and conventional processors offer an appealing hardware platform for deploying mixed criticality tasks. This is because HRT tasks can execute on predictable cores while SRT tasks execute on conventional cores. However, providing distinct off-chip memories to the cores is prohibitively costly, and researchers recognize that access to off-chip memories must be shared.

This has generated a considerable volume of research in the re-design of memory controllers (MCs) [59,72–74] to control accesses to off-chip dynamic random-access memories (DRAMs). The key technique used in these works is to write back the data in the DRAM row buffer af- ter each access. This is known as close-page policy, which ensures that every DRAM access consumes the same number of cycles and thereby achieves predictability. However, row local- ity between successive requests is not exploited. While this is apt for HRT tasks, SRT tasks experience significant bandwidth degradation. This makes such MCs ill-suited for SRT tasks. Goossens et al. [75] address this issue by keeping the data in the row buffer available for any further access within a designated time window. To exploit this for performance benefits, there must be multiple requests targeting the same row within a short time window. To address this limitation, Wu et al. [60] assign private DRAMs to each core to utilize the fact that accesses from the same core have a higher likelihood of exploiting row locality. Their approach prohibits shar- ing of data across the cores, and it requires assigning a DRAM bank per core, which may not be possible with a large number of cores. Three recent MCs [23,76,77] target MCS with critical and non-critical tasks. All the three MCs deploy a fixed-priority scheduling; thus, providing neither latency nor BW guarantees to any task other than the most-critical ones. While fixed-priority approach is suitable for dual-criticality systems, we find it ill-suited for systems with various mixed-critical tasks, where less-critical tasks may still require some guarantees [13]. As a result, we find that designers are still faced with the challenge of designing DRAM MCs that allow tasks with different memory requirements to share off-chip DRAMs in MCS while satisfying their respective temporal and bandwidth requirements.

4.1.1 Contributions

1. We directly address this challenge by proposing a novel requirement-aware approach to man- age DRAM accesses in MCS. This is achieved by enabling the designer of MCS to assign

memory requirements (both BW and latency) per task/requestor1_{. To achieve this target, we}

introduce three components that together construct our approach. (1) A novel harmonic dis- tributed time-division-multiplexing (TDM) scheduling scheme with low cost implementation adequate for MCS (Section4.6). (2) A deployment framework to generate optimal schedules for the MC. The proposed framework is a tool to explore the trade-offs between requirements of different tasks to provide the optimal MC behaviour satisfying these requirements (Sec- tion 4.7.1). (3) Since MCS can deploy different sets of running tasks, we introduce PMC, a programmable memory controller that can be programmed with the optimal schedule at boot-time to meet varying requirements of different task sets in MCS (Section4.5.1).

2. The proposed approach is based on the following novel observation. In MCS, SRT BW- sensitive requestors (such as multimedia processors, network processors and direct-memory access (DMA) processors) usually issue large-size memory requests. The observation we make is that if the locality within these large-size requests is exposed to the MC, we can min- imize the WCL of HRT tasks, while satisfying the BW requirements of SRT tasks. To exploit the locality in large-size requests, we use a mixed-page policy that dynamically switches be- tween close- and open-page policies based on the request size (Section 4.5.2). In addition, to bound the interference among different requestors, we provide an adaptive rate regula- tion mechanism (Section 4.5.5). The framework decides the optimal threshold of this rate- regulator to meet latency and BW requirements of all tasks.

3. Current DRAM modules are composed of a number of entities denoted as banks, where mul- tiple banks can be combined in one group called rank. Based on the available DRAM module in the system as well as the characteristics of the set of running tasks, we introduce two archi- tecture optimizations toPMCthat further reduce DRAM latency and enhance its performance. (1) For systems with multi-rank DRAMs, requests can be interleaved across different ranks such that they are serviced in parallel. Rank interleaving is different than the rank switching mechanism proposed by [23,59,78] in that it parallelizes each request across available ranks instead of mapping consecutive requests to different ranks. We utilize this rank interleaving to reduce WCL, while increasing memory performance (Section 4.5.4). (2) To exploit the available bank parallelism,PMCinterleaves each request across banks. Bank interleaving ap- proach is followed by many real-time controllers such as [72,74,75,79]. Interleaving requests with small transaction sizes across all available banks can result in unnecessary latency and bandwidth penalties [80]. Accordingly, we follow a similar approach to [79] and extendPMC

to support interleaving across dynamic number of banks based on the issued transaction size (Section4.5.3).

1_{Assuming a core affinity where each task executes on a designated core, we use words task and requestor in}

R equestors Logical Address Address Mapping Physical Address Command Generation Command Queues Command Arbitration

Memory Controller Banks Columns

Row buffer Rows Interface Queues Requestors Arbitration Rank Frontend _Backend DIMM chip

Figure 4.1: DRAM subsystem.

4. We present a static analysis for accesses to the DRAM managed byPMCin multi-core MCS to guarantee meeting the requirements of all requestors under all circumstances. The static analysis provides a different latency and BW bounds per requestor based on the generated optimal schedule (Section4.7).

5. We provide a detailed comparison between the three different memory access policies: close- page policy [74], conservative-open page policy [75] and the mixed-page policy, which illus- trates the strengths and scope of each one.