Locating cache performance bottlenecks using data profiling

Pesterev, Aleksey; Zeldovich, Nickolai; Morris, Robert

doi:10.1145/1755913.1755947

Cited by 61 publications

(43 citation statements)

References 18 publications

(15 reference statements)

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Although widely used for performance tuning and architectural-design verification [7,30], they have only had limited use in automated softwarereliability tools for several reasons:…”

Section: Contributionmentioning

confidence: 99%

Production-run software failure diagnosis via hardware performance counters

et al. 2013

View full text Add to dashboard Cite

Sequential and concurrency bugs are widespread in deployed software. They cause severe failures and huge financial loss during production runs. Tools that diagnose production-run failures with low overhead are needed. The state-of-the-art diagnosis techniques use software instrumentation to sample program properties at run time and use off-line statistical analysis to identify properties most correlated with failures. Although promising, these techniques suffer from high run-time overhead, which is sometimes over 100%, for concurrency-bug failure diagnosis and hence are not suitable for production-run usage.We present PBI, a system that uses existing hardware performance counters to diagnose production-run failures caused by sequential and concurrency bugs with low overhead. PBI is designed based on several key observations. First, a few widely supported performance counter events can reflect a wide variety of common software bugs and can be monitored by hardware with almost no overhead. Second, the counter overflow interrupt supported by existing hardware and operating systems provides a natural and effective mechanism to conduct event sampling at user level. Third, the noise and non-determinism in interrupt delivery complements well with statistical processing.We evaluate PBI using 13 real-world concurrency and sequential bugs from representative open-source server, client, and utility programs, and 10 bugs from a widely used software-testing benchmark. Quantitatively, PBI can effectively diagnose failures caused by these bugs with a small overhead that is never higher than 10 %. Qualitatively, PBI does not require any change to software and presents a novel use of existing hardware performance counters.

show abstract

“…Although widely used for performance tuning and architectural-design verification [7,30], they have only had limited use in automated softwarereliability tools for several reasons:…”

Section: Contributionmentioning

confidence: 99%

Production-run software failure diagnosis via hardware performance counters

et al. 2013

View full text Add to dashboard Cite

show abstract

“…Load Imbalance and Serialization can be measured by counting the cycles when a core is idle or busy-waiting for work (and not waiting on synchronization primitives) while another core (or cores) are busy doing work 1 . Distinguishing between Load Imbalance and Serialization is tricky, as they both show up as processor idle cycles while a thread is either 1 We assume that the program is not I/O-bound.…”

Section: A Measuring Software-induced Overheadmentioning

confidence: 99%

“…Distinguishing between Load Imbalance and Serialization is tricky, as they both show up as processor idle cycles while a thread is either 1 We assume that the program is not I/O-bound.…”

Section: A Measuring Software-induced Overheadmentioning

confidence: 99%

“…There are many factors that can contribute to a lack of scaling including contention for locks, contention for cache and memory system resources, overhead in the runtime work scheduler, inefficient work distribution leaving processors idle, or very simply, there could be not enough available parallelism. Profiling tools measure where a program spends its time and attribute the overhead to functions, synchronization primitives and even to data structures [1], but fail to generate immediately actionable insight into issues limiting scalability. Profiling data is specific to a given program and is not organized in a way that allows us to process it automatically and diagnose performance issues.…”

Section: Introductionmentioning

confidence: 99%

See 1 more Smart Citation

Deconstructing the overhead in parallel applications

Roth

Best²,

Mustard

et al. 2012

2012 IEEE International Symposium on Workload Characterization (IISWC)

View full text Add to dashboard Cite

Abstract-Performance problems in parallel programs manifest as lack of scalability. These scalability issues are often very difficult to debug. They can stem from synchronization overhead, poor thread scheduling decisions, or contention for hardware resources, such as shared caches. Traditional profiling tools attribute program cycles to different functions, but do not generate immediate insight into issues limiting scalability. Profiling information is very program-specific and is usually processed manually by a human expert in a time-consuming and cumbersome process.Our experience in tuning performance of parallel applications led us to discover that performance tuning can be considerably simplified, and even to some degree automated, if profiling measurements are organized according to several intuitive performance factors common to most parallel programs. In this work we present these factors and propose a hierarchical framework composing them. We present three case studies where analyzing profiling data according to the proposed principle led us to improve performance of three parallel programs by a factor of 6-20×. Our work lays foundation for new ways of organizing and visualizing profiling data in performance tuning tools.

show abstract

“…Software profiling relies on code instrumentation to associate certain hardware performance events with specific code segments (e.g. oprofile, gprof, Intel VTune, Sun Studio collect/analyze) or data structures [2]. Software profiling is conventionally regarded as an off-line method, because it slows down application execution.…”

Section: A Traditional Approaches To Understanding Workload Behaviourmentioning

confidence: 99%

A configurable framework for investigating workload execution

Matthews

Shannon

Fedorova

2010

2010 International Conference on Field-Programmable Technology

View full text Add to dashboard Cite

Abstract-Processor systems contain a limited number of hardware counters that provide some visibility for certain types of interactions, but do not support sophisticated analysis due to limited resources. By contrast, system software simulators provide multidimensional runtime data, but slowdown application execution, often resulting in an inaccurate picture of hardware/software interactions. The ideal solution to this problem is to create a dedicated hardware unit to "watch" the processor for these types of behaviours. In this paper, we present a hardware framework that leverages an FPGA's reconfigurable fabric to investigate of workload execution behaviours on processors using a hArdware-Based Analyzer for the Characterization of User Software (ABACUS). ABACUS is currently able to interface with the LEON3 processor using 1367 FFs, 1504 LUTs and 1 Block RAM on a Virtex 2Pro running at 144MHz.

show abstract

Locating cache performance bottlenecks using data profiling

Cited by 61 publications

References 18 publications

Production-run software failure diagnosis via hardware performance counters

Production-run software failure diagnosis via hardware performance counters

Deconstructing the overhead in parallel applications

A configurable framework for investigating workload execution

Contact Info

Product

Resources

About