DAMA: A Dual Arbitration Mechanism for Mixed-Criticality Applications

Modern commercial off-the-shelf (COTS) systems aim to maximize average performance by employing high-performance arbiters that adopt different policies such as FCFS policy[21], parallelism-aware batch policy [35], out-of-order policy [38], and many more. While these arbitration schemes significantly improve average performance, they fail to honor the timing requirements for $LTC$ requests in a system.

To address this, extensive research has focused on designing predictable arbiters, such as round-robin (RR) and its various adaptations [25], time division multiplexing (TDM) [20], and similar approaches. These arbiters are designed to provide timing guarantees, making them suitable for real-time applications. While this approach provides strong timing guarantees, it can lead to substantial overall performance degradation due to its rigid scheduling policy.

Many studies have addressed the tradeoff between predictability and average performance by handling requests with varying levels of criticality. One line of work has focused on proposing OS-level mechanisms to manage the memory resource primarily through space isolation and bandwidth regulation in memory resources [27, 45, 46]. Another significant body of work has explored redesigning the memory controllers to support mixed-criticality systems, offering differentiated services to critical and non-critical requests [17, 11, 22, 15, 18]. The work most related to ours is the Duetto model [31], which combines the performance benefits of high-performance arbiters with bounded request latency. Duetto associates a relative deadline (maximum per-request latency) to each requestor and uses it to derive an absolute deadline for each request at runtime. It then uses a monitoring component to dynamically compute the worst-case finish time of the request, assuming that the system continues to operate in high-performance mode for the current clock cycle. If the computed finish time exceeds the deadline, Duetto switches to a real-time arbiter to preserve the per-request latency guarantee. This arbitration scheme has been applied to a banked SRAM model in [31], to a DRAM model in [32], and to a coherent shared cache in [33]. DAMA simplifies the Duetto model by avoiding tracking and computing individual per-request latencies, and instead providing a cumulative latency bounds on all requests issued by a task. As discussed in Section 5.4, this results in better performance for the same task-level latency bound, and a potentially easier hardware implementation.

Prefetching is a commonly used technique that hides memory latency by anticipating future memory accesses and proactively loading data into the cache before the processor requests it. This has proven to be an effective technique that reduces the likelihood of cache misses, thereby improving the overall performance of the system. Numerous prefetchers have been proposed to target sequential memory accesses [8, 39], strided access patterns [3, 24], irregular access patterns [6, 7, 23], and more complex designs that employ low-cost perceptron networks to predict diverse access patterns [5, 4]. A detailed overview of prefetchers can be found in [12, 34]. Among the most widely adopted prefetching techniques in systems are stride [3] prefetchers. Stride prefetchers can identify recurring patterns for accesses that are not necessarily separated with constant strides. These prefetchers are particularly effective for dense matrix operations and multi-dimensional array traversals [12]. Conventionally, stride prefetchers place prefetched blocks directly into the cache, which can lead to cache pollution by displacing useful datasets especially if the prefetcher is very aggressive. To that end, Joupi et al. [24] proposed placing prefetched blocks into a separate buffer, known as a stream buffer, and migrating the blocks to the cache only when requested by the core.

While prefetchers significantly improve average system performance, their complexity makes them difficult to analyze, leading to overly pessimistic execution time bounds for $LTC$ requests. In this paper, we address two key factors contributing to this limitation:

• $\mathrm{■}$

  Prefetchers can induce memory reordering, potentially leading to pathological scenarios where $LTC$ requests are delayed by prefetch requests fetching non-essential data. We address this limitation in Section 3.

• $\mathrm{■}$

  A prefetcher can alter the state of cache lines by replacing existing blocks with prefetched blocks, or by modifying the ages of cache lines within a particular associative set. We address this limitation in Section 4.

Consequently, disabling hardware prefetchers is a common practice in real-time systems [14].

To mitigate the unpredictability inherent in prefetchers and capitalize on their performance gains, researchers in the real-time community have devised various software and hardware techniques. The work in [36, 29, 10] addresses this by introducing a software model that segments tasks into computational and memory phases, with data and code prefetched into the cache at the start of each memory phase. Other software-based approaches have investigated prefetching data into a scratchpad memory rather than the cache in a predictable manner [2, 41, 44, 40, 9]. Software-based approaches, while effective, often require modifying the code and potentially the compiler to incorporate prefetching instructions or directives.

Work proposing predictable prefetching through hardware modifications is scarcer. The most relevant solution is [13], whose authors propose a WCET-preserving hardware prefetcher for many-core systems. Their solution involves a memory-level prefetcher connected to a predictable interconnect with a fixed-priority scheme, which bounds the blocking periods for high and low-priority packets. However, as noted in [34], attaching a prefetcher at the memory side may not always be optimal, as the memory can only detect misses and lacks accurate knowledge of the core’s reference patterns and whether the prefetched blocks are hitting or missing in the cache. In their paper, they utilize idle system slots to issue prefetch requests and employ a variant of the stream buffer to temporarily store prefetched blocks. These blocks are only moved to the cache upon demand, helping to preserve the cache state and maintain its analyzability. However, as we demonstrate in Section 5, relying solely on idle slots for issuing prefetch requests can be suboptimal, especially when cores execute bandwidth-intensive workloads that leave few empty slots for prefetch requests.

We consider a system comprising $M$ distinct requestors $\{R_1,\mathrm{\dots },R_M\}$, which may include cores, DMA engines, accelerators, bus masters, and more. We assume that a requestor $R_i$ can either issue $LTC$ requests, $NLTC$ requests, or both, targeting a shared resource. For the sake of simplicity, we present our solution without considering data sharing between requestors. We denote $r_{i,j}$ to represent $LTC$ requests, originating from requestor $R_i$ and indexed by $j$ (e.g. $r_{i,1},r_{i,2}\mathrm{\dots }{r}_{i,j}$) according to their arrival time $t_{i,j}^a$ at the resource. We assume that a request is enqueued at the shared resource upon its arrival, and remains outstanding in the queue until it finishes being serviced; we denote $t_{i,j}^f$ the finishing time for $LTC$ request $r_{i,j}$. We consider a discrete model of time, expressed in multiples of the clock period at the resource. We assume that it takes at least one clock cycle to service a request, hence $t_{i,j}^f>t_{i,j}^a$, and that no more than one request can finish in any given clock cycle. We further assume that requests can be serviced in an out-of-order fashion and that a single requestor can have multiple outstanding requests.

In this subsection, we describe the latency regulation mechanism outlined in Algorithm 1. After performing the system initialization at $t=0$, the memory controller conducts a series of checks on a per-cycle basis. At every cycle, the queues $\{{ℒ}_1,\mathrm{\dots },{ℒ}_M\}$ are checked to determine whether outstanding requests are still waiting to be serviced (line 12). If this is the case, the counter ${𝒞}_i$ of requestor $i$ is decremented by 1, indicating the passage of time and the consumption of 1 cycle from its latency budget (line 13). It is important to note that the latency counters are only updated when there are outstanding $LTC$ requests residing in $\{{ℒ}_1,\mathrm{\dots },{ℒ}_M\}$ and when these requests are serviced. This is because our mechanism focuses solely on regulating the latency of $LTC$ requests, with no consideration for regulating $NLTC$ requests. Let $\mathrm{\Theta }({ℒ}_i,t)$ be a function that returns a request $r_{i,j}$ that finishes at time $t$. If such a request does not exist, the function returns NULL. At every cycle, the memory controller checks whether any of the oldest requests residing in queues $\{{ℒ}_1,\mathrm{\dots },{ℒ}_M\}$ have been serviced (line 15). If such a request exists, the latency counter ${𝒞}_i$ for the corresponding requestor $i$ is incremented by the minimum between the maximum slack value ${𝒮}_i$, and the sum of the current counter value ${𝒞}_i$ with ${\mathrm{\Delta }}_i$ (line 16). The purpose of this minimum operation is to bound the accumulated counter value, ensuring it does not exceed ${𝒮}_i$. This guarantees that the counter values will not grow indefinitely beyond ${𝒮}_i$ which is essential to derive a latency bound for $LTC$ requests. After updating the value of the counters, we push the newly arrived requests into their respective queues and pop the ones that finished (line 18). At the end of each processing round, the status of the latency counters is checked. If any counter ${𝒞}_i\in \{{𝒞}_1,\mathrm{\dots },{𝒞}_M\}$ is less than or equal to zero (line 20), this indicates that requester $i$ has exhausted its allocated latency budget, and the arbiter executes in real-time mode (line 21). Transitioning to the RTA when any of the counters gets depleted is essential as this mode imposes a bound ${ℬ}_i$ on the maximum service time of a request issued by requestor $R_i$. Conversely, if all counters return to values above zero, the arbiter transitions back to high-performance mode (line 23). Note that both loops in Algorithm 3.3 depict how the hardware operates and are thus executed in parallel.

Figure 3 provides an illustrative example of how the counter value changes throughout the program’s execution, demonstrating how switches are performed accordingly. For this example, we assume ${\mathrm{\Delta }}_i=3$, ${𝒮}_i=4$, and ${ℬ}_i=3$. The counter begins with a value initialized to ${𝒮}_i$, allowing the arbiter to operate in HPA mode, as the counter value is positive. At $t=1$ the first memory request from requestor 1 becomes the oldest. As it can be seen in the figure, the arrival time $t_{i,j}^a$ overlaps $t_{i,j}^o$ the time the request becomes oldest. This indicates that queue ${ℒ}_1$ was empty and did not have any outstanding requests when $r_{1,1}$ arrived, which makes queuing time for $r_{i,j}$ equal to zero. After the request becomes oldest the counter starts decrementing by 1 with each cycle until the request gets serviced. At $t=3$, request $r_{1,1}$ completes, prompting the controller to add ${\mathrm{\Delta }}_i$ to the counter. Although the counter would have reached 5 at $t=3$, it is capped at ${𝒮}_i$ to keep the value bounded. At $t=4$ and $t=11$ two new requests $r_{1,2}$ and $r_{1,3}$ become the oldest and the same behavior with the counters repeats. Notice that $r_{1,3}$ arrives at $t=6$ but does not become the oldest until $t=11$ since at $t=6$ $r_{1,2}$ is the oldest outstanding request that is still waiting to get serviced. At $t=8$ the counter reaches 0, prompting the controller to switch to RTA. In the worst-case scenario, the oldest request will spend at most ${ℬ}_i$ cycles in RTA mode. The constraint ${\mathrm{\Delta }}_i\ge {ℬ}_i$ ensures that when a request $r_{i,j}$ finishes, its counter ${𝒞}_i$ will be greater than or equal to zero, as demonstrated at cycles 11 to 13. At cycle 13 since $r_{1,3}$ is serviced, the counter becomes greater than 0, and the arbiter switches back to HPA mode.

We next formally prove the timing guarantee provided by DAMA. In what follows, let ${𝒞}_i(t)$ to denote the value of counter ${𝒞}_i$ at clock cycle $t$ (after executing Algorithm 1 for that clock cycle). Also, let $\mathrm{next}(j)$ to denote the index of the first $LTC$ request of $R_i$ after $r_{i,j}$ that becomes oldest at some point. First, in Lemmas 3 and 4, we constraint the value of the counter whenever a $LTC$ request becomes oldest. Then, Theorem 5 uses the lemmas to compute a latency bound for a sequence of $LTC$ requests. Finally, Theorem 6 extends the bound to a task under analysis considering the effects of preemptions.

Conventionally, prefetchers place data fetched from main memory into the cache, thus altering the state of its cache lines. This alteration can involve replacing existing blocks with prefetched data or updating the ages of cache lines within a particular associative set. Incorporating this behavior into static WCET analysis is generally avoided due to its complexity. In our approach, we maintain WCET analyzability of the cache by using a prefetch side buffer, a concept first introduced in [24] and later adapted for real-time systems in [13]. This side buffer prevents cache pollution and avoids modifying the cache state by storing prefetched blocks separately and transferring them to the cache only upon a demand hit. However, it is important to note that although a prefetch side buffer prevents changes to the cache line state, it does impact the time needed to service a miss request. This is because, before introducing the prefetch side buffer, servicing a cache miss required accessing the main memory. However, with the side buffer, servicing a cache miss can either be handled by fetching the data from the main memory or by accessing the side buffer, which takes less time. Due to this difference in the time required to handle a cache miss, any static analysis tool used to determine the state of cache lines (e.g., always hit, always miss, etc.) must be able to account for these timing variabilities.

A core generates a $LTC$ demand request $r_{i,j}$ whenever it misses in the L1 data cache. Note that if $r_{i,j}$ finds a matching address for a block in the prefetch side buffer, it is not propagated to the memory controller; instead, the block is moved directly into the cache. Therefore, from the core’s perspective, the request’s processing latency ${\beta }_{i,j}$ is zero. By including the request in the sequence $\{r_{i,j}\}$ of $LTC$ requests issued by $R_i$, we ensure that the total number of issued $LTC$ requests remains unchanged, with or without the prefetcher.

In Section 3.5, we provide a proof of how timing guarantees are ensured for $LTC$ requests when operating in RTA mode. Importantly, the introduction of the prefetch side buffer guarantees that, regardless of the prefetching strategy, prefetch requests do not interfere with the state of $LTC$ requests and therefore do not impact their timing. As a result, the previously derived bound on the cumulative latency of $LTC$ requests remains valid even with the addition of the prefetcher, and no modifications are required to account for it.

When a prefetch request is issued by requestor $R_i$, an $NLTC$ request is created and added to its corresponding queue ${𝒩}_i$ at the memory controller. Before servicing this request, the requestor may issue a demand request (considered to be $LTC$) to the same address. Under normal circumstances, this $LTC$ request would be inserted into its designated queue ${ℒ}_i$ at its intended arrival time. However, this is problematic, as two requests targeting the same address would exist in ${ℒ}_i$ and ${𝒩}_i$, both to be processed by the memory controller. To address this, we incorporate a request-merging mechanism. This mechanism involves retaining the $LTC$ request in ${ℒ}_i$ and removing the $NLTC$ request from ${𝒩}_i$. Before discarding the $NLTC$ request, we merge any relevant information from it into the $LTC$ request, as required by the HPA. For instance, if the HPA operates on a FCFS basis, the merged information would be the arrival time of the $NLTC$ request, which arrived before the $LTC$ request ²²2Note that from a hardware implementation perspective, FCFS is typically implemented through a queue of pointers to requests, ordered by arrival time. Hence, the merging operation effectively consists in overwriting the queue position previously occupied by the $NLTC$ request with a pointer to the $LTC$ request.. This process ensures that the system behaves as though the earlier-arrived $NLTC$ request was maintained, without affecting the cumulative processing latency bound of $LTC$ requests.

Another feature we incorporated into our system is incrementing the latency counter $C_i$ for requestor $i$ when it accesses a prefetched block that is already present in the prefetch side buffer. Conventionally, upon processing a demand request issued by requestor $R_i$, the value ${\mathrm{\Delta }}_i$ would be added to its counter upon completion, as outlined in Algorithm 1. However, as discussed in Section 4.1, locating a matching block in the prefetch side buffer indicates that the request has already been prefetched, so there is no need to send a new request to the memory controller. This allows us to instantly increment the latency counter $C_i$ for the requestor $R_i$ that issued the demand request. Incrementing the counter in this way enables us to maintain HPA mode for a longer period, thereby avoiding a transition to RTA mode.

Implementing the predictable prefetcher described in the previous subsections requires modifying the cache controller to handle prefetched blocks differently. In our model, we assume a cache controller that includes a prefetch side buffer, implemented as a fully associative cache, along with two separate miss status holding register (MSHR) queues: one for demand requests $DMSHR$ and another for prefetch requests $PFMSHR$. An MSHR queue is used to track outstanding cache misses, storing information such as the address of the missed request. As discussed in [42], MSHRs can be a significant contention point and therefore require partitioning based on request criticality. In our model, we split the MSHR queues to prevent the prefetcher, which issues $NLTC$ requests, from overwhelming the MSHR queue handling $LTC$ requests. This approach limits the number of prefetch requests that can be issued while ensuring that requestors issuing $LTC$ requests are never blocked by the prefetcher. Algorithm 2 outlines how the cache controller handles request packets sent from the core and the response packets received from the memory controller.

When a request arrives from the core, we first check if the requested data is available in the cache or the prefetch side buffer (line 8). If the data is not found and the request does not match a PFMSHR or DMSHR entry, a new entry is created in the appropriate MSHR queue (lines 9-14). Subsequently, the request is forwarded to the next level in the memory hierarchy (line 15). On the other hand, if a cache hit is encountered (line 18), the ages of the cache lines within the accessed set are adjusted (line 19). If a request packet from the core is received and is identified as being present in either the PFMSHR or the prefetch side buffer, there are two cases to consider:

• $\mathrm{■}$

  Case 1: The received request packet corresponds to a demand request and matches the address of a prefetch request in the prefetch MSHR (line 20). This indicates that a demand request is accessing the same address as a prefetch request that has been issued but not yet serviced. As discussed in Section 4.2, in this case, the memory controller merges both requests by discarding the prefetch packet and transferring its information to the demand packet, which is then placed into the ${ℒ}_i$ queue. To achieve this, the cache controller is modified to send a merge packet with all the required information, which the memory controller must receive and respond to accordingly (lines 21-24).

• $\mathrm{■}$

  Case 2: The received request packet corresponds to a demand request that hits in the prefetch side buffer (line 25). This indicates that the demand request is accessing a block that was previously prefetched and stored in the prefetch side buffer. In this case, the block is copied to the cache and evicted from the prefetch side buffer. Additionally, as outlined in Section 4.2, when a demand request hits in the prefetch side buffer, the latency counter of the corresponding requestor is immediately incremented by ${\mathrm{\Delta }}_i$. To facilitate this, we modify the cache controller to send a counter increment packet, which the memory controller must receive and handle accordingly (lines 26-32).

Note that in cases 1 and 2, sending merge and counter increment packets does not introduce additional interconnect overhead in our setup, as we assume a crossbar interconnect (see Section 5). This may not hold for other interconnect designs.

If a core tries to issue a demand request to an address already present in the $DMSHR$, the corresponding instruction stalls until the response is received, and only then the demand request is processed by the cache. Similarly, if the prefetcher issues a request for a block that resides in the $PFMSHR$, the prefetch side buffer, or the cache, the prefetch packet is dropped.

Upon receiving a response packet from the memory controller, we first verify if it corresponds to a prefetch request (line 36). If so, this suggests that data for a prefetch request, which initially missed in the cache, has now arrived. We then check if there is space in the prefetch side buffer to accommodate this request (line 37). In the event that the buffer is full, the oldest prefetched block is evicted to make room for the incoming data (line 38-39). Once sufficient space is available, the new prefetched block is inserted into the prefetch side buffer, and the corresponding entry in the prefetch MSHR queue is subsequently freed (lines 41-44). However, if the response packet corresponds to a demand request, we allocate a new cache block, perform the necessary evictions, and insert the new block into the cache (lines 46-47). Note that if the evicted block is dirty, a $LTC$ writeback request is issued to the memory resource.

In this section, we experimentally demonstrate DAMA’s latency guarantees by running a subset of real-world SDV benchmarks on the foreground core and the synthetic bandwidth-intensive IsolBench benchmark on the background cores. Our goal is to show that, under DAMA, the foreground core meets its derived per-request and cumulative latency bounds even when background cores are acting in an adversarial manner. In this set of experiments, we regulate the latency of requests originating from the foreground and background cores. This means that if any counter ${𝒞}_i$ for any $i\le M$ gets depleted a switch to RTA is prompted. Figure 4 delineates the processing latency of requests for the foreground core executing SDV benchmarks under FCFS (HPA), RR (RTA), and DAMA. It also shows the per-request RR and DAMA bounds, the cumulative processing latency bound scaled by the number of requests $𝒦$, and the average latencies of requests. We scale the cumulative bound by $𝒦$ and display the average latency instead of the total latency for clearer visualization. For all experiments, unless otherwise stated, we configure DAMA’s parameters as follows: ${\mathrm{\Delta }}_i={ℬ}_i=8$, $𝒮=16$, $𝒫=1$. Under RR, the worst-case scenario occurs when a switch to RR happens after starting to process an $NLTC$ request, causing the next $LTC$ request in RR order to suffer a waiting time of $𝒫-1$ plus the maximum waiting time in RR which is $M\cdot 𝒫$. Hence, the RR per-request bound is computed as ${ℬ}_i=M\cdot 𝒫+𝒫-1$. Since in our case $𝒫=1$, our per-request RR bound becomes ${ℬ}_i=8$. Under DAMA, the worst-case processing latency of an $LTC$ request $r_{i,j}$ occurs when the counter ${𝒞}_i$ starts at its maximum value ${𝒮}_i$ when $r_{i,j}$ becomes oldest. Because our employed arbiters process requests of $R_i$ at the memory controller in order, no other $LTC$ request of $R_i$ can finish while $r_{i,j}$ is oldest. Therefore, in the worst case the counter keeps decrementing until it reaches 0 and the arbiter switches to RTA mode. Then, the $LTC$ requests takes an additional ${ℬ}_i$ cycles to get serviced. Consequently, the maximum latency that could be experienced by a single request under DAMA in this experiment cannot exceed ${𝒮}_i+{ℬ}_i=24$.

Figure 4 illustrates how requests executing under FCFS experience substantial latency spikes. This is because FCFS prioritizes requests based on their arrival time, and the high volume of background core requests overloads the shared memory resource. As a result, the requests issued by the foreground core face significant delays, leading to the average latency exceeding the scaled cumulative latency bound. Under RR, however, the maximum latency experienced by a foreground core request remains within the bound imposed by RR. Consequently, the average latency of requests saturates at this bound and never exceeds it. The DAMA model, on the other hand, keeps executing requests in FCFS mode until the counter ${𝒞}_i$ is depleted, at which point it switches to RR mode. This explains the latency spikes that surpass the RR bound but stay within the per-request bound imposed by DAMA in both benchmarks $tracking$ and $localization$. It is important to note that the foreground core does not always trigger the switch to RTA mode. As a result, requests on the foreground core may not always experience latency spikes, since this depends on the core’s access pattern and the possibility of other cores triggering a switch. This helps explain why $tracking$ has fewer latency spikes than $localization$. As for the average latency of requests, we can see that it consistently remains below the scaled cumulative bound and eventually saturates at the RR bound. This saturation occurs because scaling the cumulative bound by $1/𝒦$ results in the expression $𝒮/𝒦+\mathrm{\Delta }$ which corresponds to the cumulative bound with $CS=1$ in Theorem 6. As the number of requests increases, the first term approaches zero, leaving only $\mathrm{\Delta }$ which is equal to the RR bound $ℬ$ in this experiment.

In Figure 5, we experimentally demonstrate that after enabling the prefetcher on all cores the cumulative processing latency bound is still honored for $tracking$ and $localization$ benchmarks. However, the $tracking$ benchmark exhibits per-request latency spikes, suggesting that the previous per-request latency bound is violated upon enabling the prefetcher. This happens because, with the prefetcher enabled, DAMA allows requests to be serviced out of order in the specific case where a demand request hits the prefetch side buffer while the memory controller is still servicing an earlier demand request. In this scenario, the latency counter is incremented by ${\mathrm{\Delta }}_i$, giving the request being serviced more time to continue executing in HPA mode, thereby exceeding the previous per-request latency bound. We remark that the focus of our approach is on bounding the cumulative processing latency of $LTC$ requests, allowing flexibility with the latency of individual requests to maintain the system in HPA mode as long as possible.

To evaluate the influence of prefetch buffer size on average performance, we executed a subset of linear algebra kernels from PolyBench on a single core. Figure 6 depicts the normalized Instructions Per Cycle (IPC) of the core for various cache and prefetch buffer sizes, relative to a configuration without a prefetcher. As observed, most benchmarks exhibit a performance increase with larger cache sizes. This is attributed to the larger cache’s ability to accommodate more prefetch blocks, potentially reducing cache evictions. For example, benchmarks $bicg$ and $mvt$ experienced an approximate 15% IPC boost when the cache size was increased from 2KB to 16KB.

As Figure 6 illustrates, for small cache sizes the prefetch side buffer can perform even better than a conventional (not pred) prefetcher. For example, with a 2KB cache, benchmarks $bicg$, $mvt$, and $doitgen$ experienced IPC increases of 12%, 5%, and 21%, respectively, with a 16-entry buffer. This improvement occurs because the prefetch side buffer stores prefetched blocks until they are needed, reducing cache pollution, especially when the prefetcher is aggressive. However, if the buffer is too small, performance can degrade significantly. In this case, prefetched data may be evicted before it is needed, leading to wasted prefetch effort. This behavior is exhibited with a prefetch buffer size of 2 and 4 for all benchmarks. Based on these results, we chose an 8-entry prefetch buffer, as Figure 6 indicates this configuration achieves near-optimal performance with a 16KB cache. Additionally, the extra memory overhead for this configuration is minimal, amounting to 3%. Note that we evaluated multiple prefetcher types (IPC results are in the supplementary material at [1]), and we selected the Stride Prefetcher due to its superior performance across various PolyBench benchmarks.

In this series of experiments, we evaluate the effectiveness of DAMA when we attach a predictable stride prefetcher to the L1 data caches of the system. To evaluate how DAMA performs when the prefetcher is enabled we use two different benchmark setups described as follows: (1): The foreground core executes PolyBench benchmarks, while all the background cores run bandwidth-intensive workloads. (2): We execute eight distinct PolyBench benchmarks, each assigned to a separate core.

Figure 7 illustrates the normalized average IPC for DAMA across all cores with and without the prefetcher across various slack values, relative to the FCFS configuration without a prefetcher under setup 1.