A Software Cache Partitioning System for Hash-Based Caches

Abstract

Contention on the shared Last-Level Cache (LLC) can have a fundamental negative impact on the performance of applications executed on modern multicores. An interesting software approach to address LLC contention issues is based on page coloring, which is a software technique that attempts to achieve performance isolation by partitioning a shared cache through careful memory management. The key assumption of traditional page coloring is that the cache is physically addressed. However, recent multicore architectures (e.g., Intel Sandy Bridge and later) switched from a physical addressing scheme to a more complex scheme that involves a hash function. Traditional page coloring is ineffective on these recent architectures. In this article, we extend page coloring to work on these recent architectures by proposing a mechanism able to handle their hash-based LLC addressing scheme. Just as for traditional page coloring, the goal of this new mechanism is to deliver performance isolation by avoiding contention on the LLC, thus enabling predictable performance. We implement this mechanism in the Linux kernel, and evaluate it using several benchmarks from the SPEC CPU2006 and PARSEC 3.0 suites. Our results show that our solution is able to deliver performance isolation to concurrently running applications by enforcing partitioning of a Sandy Bridge LLC, which traditional page coloring techniques are not able to handle. CCS Concepts: r Computer systems organization → Multicore architectures; r Software and its engineering → Main memory;

Make the Most out of Last Level Cache in Intel Processors

“…These works mainly suffer from being limited to a traditional physical addressing scheme where the cache is physically addressed and/or based on application profiling without considering Intel's LLC Complex Addressing. In contrast, other works (e.g., [60,85]) extended traditional page coloring to be applicable to Intel's multi-core architectures that involve a hash-based LLC addressing scheme. However, these works will not be as effective as before on newer architectures (e.g., Haswell and Skylake), as the mapping between LLC slices and physical addresses changes at a finer granularity than 4kpages.…”

Locality-aware cache random replacement policies

“…Also, an oracle replacement policy has been defined as a reference but not made implementable [40]. Work on optimizing replacement policies for second (L2) and third level (L3) caches is abundant [41,42,43,44,45]. Those works, ei-1405 ther for uniform [41,42,43] or non-uniform [44,45] cache access architectures, leverage the fact that L1 caches filter many accesses, so that access patterns in L2 and L3 caches differ noticeably from those in L1 caches.…”

“…Work on optimizing replacement policies for second (L2) and third level (L3) caches is abundant [41,42,43,44,45]. Those works, ei-1405 ther for uniform [41,42,43] or non-uniform [44,45] cache access architectures, leverage the fact that L1 caches filter many accesses, so that access patterns in L2 and L3 caches differ noticeably from those in L1 caches. In general, those cache policies have 1410 systematic pathological cases due to their deterministic nature, thus being unfriendly for MBPTA, as it is the case for LRU.…”

Supporting I/O and IPC via Fine-Grained OS Isolation for Mixed-Criticality Real-Time Tasks

“…More broadly, this paper falls within an overarching set of research results pertaining to shared-hardware isolation [31]. Prior e orts have focused on issues such as cache partitioning [3,5,18,26,43,49,50], DRAM controllers [4,14,23,24,32,38], and busaccess control [1,2,13,15,16,42]. Other work has focused on reducing shared-resource interference when per-core scratchpad memories are used [45], thro ling lower-criticality tasks' memory accesses [52], and controlling bandwidth allocations [44].…”