Procedimiento de Solicitud de Vacaciones

After describing the key components of the architecture of a multicore platform, we now turn our attention to previous work that has identified and proposed approaches to mitigating interference that can arise due to contention for shared hardware components. Quantifying and mitigating the effects of interference in real-time systems has been studied extensively for quite some time, and therefore we limit this discussion to only those works that are most relevant to the contributions of this dissertation.

2.3.2.1 Caches

We begin our discussion of interference caused by shared hardware with caches. Even on a uniprocessor platform, local caches are shared among multiple processes or real-time tasks. However, on such platforms, at most one task may be scheduled at a time, which limits the number of tasks that can access the cache at any time to at most one. However, when one taskτl is preempted by a higher-priority taskτh,τh may evict the previously cached data ofτl. Whenτlresumes execution, subsequent accesses to previously cached data will miss, inflating the execution time of the task. Quantifying the cost of these cache misses is called cache-related preemption delay(CRPD)analysis. For brevity, we refer the reader to (Altmeyer et al., 2012) for further discussion on CRPD analysis for local caches.

Shared caches, which can be concurrently accessed by tasks executing on different processors, are a more challenging issue. Two concurrently executing tasks may thrash one another withcross-core cache evictions, thereby negating the benefit of the cache in the first place. This issue in particular has been identified by the FAA in a recent position paper on the use of multicore processors in avionics (Certification Authorities Software Team (CAST), 2014). For these reasons, as mentioned earlier, the currentde factostandard practice for multicore processors in industrial real-time applications is to simply disable all but one processing core, so as to eliminate the possibility of cross-core evictions.

One general approach to mitigate cache interference from other tasks iscache partitioning(Kirk, 1989; Bui et al., 2008; Altmeyer et al., 2014). Under cache partitioning, tasks are allocated memory in such a way so as to minimize or eliminate the possibility of interference. Cache partitioning can be applied to local caches on uniprocessors to eliminate cache-related preemption delays by partitioning all tasks to disjoint cache sets (rows in Figure 2.16). Such allocation can also be automatically determined by the compiler (Mueller, 1995). At the OS level,page coloring(Kessler and Hill, 1992) can be used to allocate memory pages that realize cache partitioning. Under page coloring, pages that map to the same cache sets are assigned the same color, and differently colored pages do not conflict in the cache.

Cache partitioning can also be applied to eliminate cross-core cache evictions in a shared cache. For a partitioned scheduler, the cache can be partitioned among the processors, thereby eliminating the possibility of cross-core cache evictions. This partitioning strategy effectively renders a shared cache as several smaller local caches. The CRPD analysis mentioned previously could be used to quantify the effects of cache-related preemption delays within each cache partition.

Cache lockdown. The previously discussed cache-partitioning techniques areset based. Using additional hardware available on some platforms, it is also possible to partition based on thewaysof the cache, or the columns in Figure 2.16. To support way-based cache partitioning, the cache must support some form ofcache lockdown. Cache lockdown allows software to specify which ways of the cache may be evicted, and which are locked down, or prevented from being evicted. This feature can be implemented in a number of different ways. For example, on some platforms, a global lockdown register specifies which ways are locked and which are not. On others, a lockdown register exists per core. In the later case, way-based cache partitioning can be realized by setting the cache-lockdown registers to all be disjoint, such that each core is partitioned to a subset of the available ways. This lockdown hardware was used recently by Mancuso et al. (2013) in a technique they calledcolored lockdownto permanently lock the most commonly accessed pages into the cache.

Cache partitioning is static in that partitions are determined offline and remain throughout the execution of the task system. However, in more recent work, several approaches have been presented that seek to more dynamically manage the allocation of the cache so as to realize better cache performance, while still providing cache isolation (Ward et al., 2013b; Xu et al., 2016; Kim et al., 2013). These techniques seek to provide larger cache allocations, which in turn result in smaller execution-time bounds, while also limiting or eliminating cache interference.

2.3.2.2 Memory

Memory references that do not hit in the cache are deferred to main memory. However, as described previously, there are a number of different factors that affect the latency of memory requests. Furthermore, interference from other memory references coming from other cores may also affect the latency of such requests. Much recent research seeks to minimize the effect of such interference to increase the timing predictability of memory references.

Similar to cache partitioning, the memory banks (recall from Figure 2.13) may also be partitioned, such that there is no bank interference across cores. Yun et al. (2014) presented a framework calledPALLOC

that allows for bank-aware memory allocations to minimize or eliminate interference through bank isolation.

PALLOConly affects memory allocations, and therefore does not aim to address memory interference at runtime. Yun et al. (2013) presented a tool called MemGuard, which can be used to dynamically limit the

memory bandwidth tasks receive at runtime. MemGuard leverages the hardware performance counters and suspends tasks that have used too much memory bandwidth in a given time interval, thereby freeing memory bandwidth to other tasks. MemGuard is best suited to SRT applications, though the authors note that by disabling some optimistic features, it may be possible to apply in HRT applications as well.

does not make performance guarantees, and is therefore best suited to SRT applications.

Memory controllers have also been a focus in work on more predictable memory systems (e.g., (Krish- napillai et al., 2014)). Real-time memory controllers offer the potential of more predictable memory-access latency, and more effective use of the row buffer. In this dissertation, we focus more on software-based techniques to improve the platform utilization of more widely available commercial off-the-shelf(COTS) hardware platforms, and therefore discussion of special-purpose memory controllers, which are built into the hardware platform, are beyond the scope of this dissertation.

In order to “hide” memory latency, as well as more carefully arbitrate access to memory resources, Wasly and Pellizzoni (2014) presented an algorithm that schedules both processor and memory accesses. In that work, the authors assume a two-phase memory model, in which during the first phase, the job loads all of its data from memory into a cache, and during the second phase it executes on the processor. In this model, it is assumed that during the second phase the task does not access main memory. They assume the existence of adirect memory access(DMA)engine, which facilitates background memory transfers that do not occupy processor cycles.

2.3.2.3 GPUs and Accelerators

GPUs and other hardware accelerators may be used by multiple tasks or processors. Similar to the previously discussed resources, such sharing can also cause interference that can affect the timing behavior of the use of such resources. How access to such resources is controlled is often specific to the underlying hardware being controlled in order to better utilize the hardware. In this section, we briefly highlight common techniques, and discuss a few examples.

Gai et al. (2003), who developed the previously discussed MSRP multiprocessor locking protocol, considered the use of that locking protocol to control access to hardware resources on asystem-on-chip (SOC). The hardware platform they considered was a two-core system. They considered an automotive power-train control system with I/O channels and analogue-to-digital (A/D) converters, and applied theMSRP

to synchronize access to these hardware resources, in addition to other memory resources. Locking protocols have also been used to arbitrate access to other hardware resources as well. Elliott et al. (2013) presented GPUSync, a framework that applies a synchronization-based approach to control access to GPUs and the hardware elements therein. Locking protocols are particularly amenable to both of these motivating examples due to the nature of the hardware being controlled. In both of these examples, tasks require exclusive access to the hardware to prevent interference that could negatively impact either the logical correctness, or the timing behavior of the hardware.

Others have taken a more scheduling-oriented approach to managing GPU resources (Kato et al., 2011a,b, 2012). Fundamentally, these approaches seek to resolve contention for hardware resources on the GPU. However, the implementation details associated with such management may differ greatly. GPUSync provides an additional layer of abstraction on top of the closed-source GPU driver. This design reduces contention for GPU resources at the driver level, thereby encouraging the driver to make more predictable resource- allocation decision more amenable to real-time analysis. In other work, such as RGEM (Kato et al., 2011a) and Gdev (Kato et al., 2012), the authors develop their own open-source GPU drivers through reverse engineering, which allows the driver to more predictably manage access to GPU resources. For a complete discussion of GPUs in real-time systems, we refer the interested reader to (Elliott, 2015).