System-Level Performance Metrics for Multiprogram Workloads

Eyerman, Stijn; Eeckhout, Lieven

doi:10.1109/mm.2008.44

Cited by 401 publications

(228 citation statements)

References 13 publications

Supporting

Mentioning

226

Contrasting

Unclassified

Order By: Relevance

“…We measure system performance with the commonly-used weighted speedup (WS) [6,39] metric. To report the DRAM system power, we use the methodology from the Micron power calculator [27].…”

Section: Methodsmentioning

confidence: 99%

“…To demonstrate the negative system performance impact of DRAM refresh, we evaluate 100 randomly mixed workloads categorized to five different groups based on memory intensity on an 8-core system using various DRAM densities. 6 We use up to 32Gb DRAM density that the ITRS predicts to be manufactured by 2020 [10]. Figure 6 shows the average performance loss due to all-bank refresh compared to an ideal baseline without any refreshes for each memory-intensity category.…”

Section: Increasing Performance Impact Of Refreshmentioning

confidence: 99%

See 1 more Smart Citation

Improving DRAM performance by parallelizing refreshes with accesses

Chang

Lee

Chishti

et al. 2014

2014 IEEE 20th International Symposium on High Performance Computer Architecture (HPCA)

178

153

View full text Add to dashboard Cite

Modern DRAM cells are periodically refreshed to prevent data loss due to leakage. Commodity DDR (double data rate) DRAM refreshes cells at the rank level. This degrades performance significantly because it prevents an entire DRAM rank from serving memory requests while being refreshed. DRAM designed for mobile platforms, LPDDR (low power DDR) DRAM, supports an enhanced mode, called per-bank refresh, that refreshes cells at the bank level. This enables a bank to be accessed while another in the same rank is being refreshed, alleviating part of the negative performance impact of refreshes. Unfortunately, there are two shortcomings of per-bank refresh employed in today's systems. First, we observe that the perbank refresh scheduling scheme does not exploit the full potential of overlapping refreshes with accesses across banks because it restricts the banks to be refreshed in a sequential round-robin order. Second, accesses to a bank that is being refreshed have to wait.To mitigate the negative performance impact of DRAM refresh, we propose two complementary mechanisms, DARP (Dynamic Access Refresh Parallelization) and SARP (Subarray Access Refresh Parallelization). The goal is to address the drawbacks of per-bank refresh by building more efficient techniques to parallelize refreshes and accesses within DRAM. First, instead of issuing per-bank refreshes in a round-robin order, as it is done today, DARP issues per-bank refreshes to idle banks in an out-of-order manner. Furthermore, DARP proactively schedules refreshes during intervals when a batch of writes are draining to DRAM. Second, SARP exploits the existence of mostly-independent subarrays within a bank. With minor modifications to DRAM organization, it allows a bank to serve memory accesses to an idle subarray while another subarray is being refreshed. Extensive evaluations on a wide variety of workloads and systems show that our mechanisms improve system performance (and energy efficiency) compared to three state-of-the-art refresh policies and the performance benefit increases as DRAM density increases.

show abstract

“…We measure system performance with the commonly-used weighted speedup (WS) [6,39] metric. To report the DRAM system power, we use the methodology from the Micron power calculator [27].…”

Section: Methodsmentioning

confidence: 99%

Section: Increasing Performance Impact Of Refreshmentioning

confidence: 99%

Improving DRAM performance by parallelizing refreshes with accesses

Chang

Lee

Chishti

et al. 2014

2014 IEEE 20th International Symposium on High Performance Computer Architecture (HPCA)

178

153

View full text Add to dashboard Cite

show abstract

“…The weighted speed-up corresponds to total system throughput [3]. Figure 6 shows weighted speed up normalized to private L2 cache (CC (0%), non-spilling).…”

Section: Results and Analysismentioning

confidence: 99%

Throttling Capacity Sharing Using Life Time and Reuse Time Prediction in Private L2 Caches of Chip Multiprocessors

Eom

Kwak

Jhang

et al. 2012

IEICE Trans. Inf. & Syst.

View full text Add to dashboard Cite

SUMMARYIn Chip Multi-Processors (CMPs), private L2 caches have potential benefits in future CMPs, e.g. small access latency, performance isolation, tile-friendly architecture and simple low bandwidth on-chip interconnect. But the major weakness of private cache is the higher cache miss rate caused by small private cache capacity. To deal with this problem, private caches can share capacity through spilling replaced blocks to other private caches. However, indiscriminate spilling can make capacity problem worse and influence performance negatively. This letter proposes throttling capacity sharing (TCS) for effective capacity sharing in private L2 caches. TCS determines whether to spill a replaced block by predicting reuse possibility, based on life time and reuse time. In our performance evaluation, TCS improves weighted speedup by 48.79%, 6.37% and 5.44% compared to non-spilling, Cooperative Caching with best spill probability (CC) and Dynamic Spill-Receive (DSR), respectively.

show abstract

“…All the metrics used in our evaluation are calculated as suggested by Eyerman et al [10]. Metrics are calculated based on the performance (execution time) of applications run in isolation and run in the multiprogrammed workload.…”

Section: Methodsmentioning

confidence: 99%

Enabling preemptive multiprogramming on GPUs

Tanasic

Gelado

Cabezas

et al. 2014

SIGARCH Comput. Archit. News

View full text Add to dashboard Cite

GPUs are being increasingly adopted as compute accelerators in many domains, spanning environments from mobile systems to cloud computing. These systems are usually running multiple applications, from one or several users. However GPUs do not provide the support for resource sharing traditionally expected in these scenarios. Thus, such systems are unable to provide key multiprogrammed workload requirements, such as responsiveness, fairness or quality of service.In this paper, we propose a set of hardware extensions that allow GPUs to efficiently support multiprogrammed GPU workloads. We argue for preemptive multitasking and design two preemption mechanisms that can be used to implement GPU scheduling policies. We extend the architecture to allow concurrent execution of GPU kernels from different user processes and implement a scheduling policy that dynamically distributes the GPU cores among concurrently running kernels, according to their priorities. We extend the NVIDIA GK110 (Kepler) like GPU architecture with our proposals and evaluate them on a set of multiprogrammed workloads with up to eight concurrent processes. Our proposals improve execution time of high-priority processes by 15.6x, the average application turnaround time between 1.5x to 2x, and system fairness up to 3.4x.

show abstract

System-Level Performance Metrics for Multiprogram Workloads

Cited by 401 publications

References 13 publications

Improving DRAM performance by parallelizing refreshes with accesses

Improving DRAM performance by parallelizing refreshes with accesses

Throttling Capacity Sharing Using Life Time and Reuse Time Prediction in Private L2 Caches of Chip Multiprocessors

Enabling preemptive multiprogramming on GPUs

Contact Info

Product

Resources

About