MAPPER: Managing Application Performance via Parallel Efficiency Regulation

Abstract

State-of-the-art systems, whether in servers or desktops, provide ample computational and storage resources to allow multiple simultaneously executing potentially parallel applications. However, performance tends to be unpredictable, being a function of algorithmic design, resource allocation choices, and hardware resource limitations. In this article, we introduce MAPPER, a manager of application performance via parallel efficiency regulation. MAPPER uses a privileged daemon to monitor (using hardware performance counters) and coordinate all participating applications by making two coupled decisions: the degree of parallelism to allow each application to improve system efficiency while guaranteeing quality of service (QoS), and which specific CPU cores to schedule applications on. The QoS metric may be chosen by the application and could be in terms of execution time, throughput, or tail latency, relative to the maximum performance achievable on the machine. We demonstrate that using a normalized parallel efficiency metric allows comparison across and cooperation among applications to guarantee their required QoS. While MAPPER may be used without application or runtime modification, use of a simple interface to communicate application-level knowledge improves MAPPER’s efficacy. Using a QoS guarantee of 85% of the IPC achieved with a fair share of resources on the machine, MAPPER achieves up to 3.3 \( \times \) speedup relative to unmodified Linux and runtime systems, with an average improvement of 17% in our test cases. At the same time, MAPPER violates QoS for only 2% of the applications (compared to 23% for Linux), while placing much tighter bounds on the worst case. MAPPER relieves hardware bottlenecks via task-to-CPU placement and allocates more CPU contexts to applications that exhibit higher parallel efficiency while guaranteeing QoS, resulting in both individual application performance predictability and overall system efficiency.

Interference Analysis and Resource Management in Server Processors: from HPC to Cloud Computing

“…Moori et al [66] propose a static approach that decides the TLP before the application execution starts; thus, this is not applicable in dynamic environments. In contrast, MAPPER [65] regulates application parallelism at run-time, but, as experimental results will show, it does not perform well with graph workloads.…”

“…The authors implement a dynamic loop scheduler in the OpenMP runtime system to provide dynamic spatial scheduling. A similar approach, MAPPER [65], focuses on ensuring QoS rather than maximizing system utilization. MAPPER may run without runtime modification (i.e., MAPPER applies only the scheduling part), but minor performance improvements are obtained.…”

“…To this end, two main issues must be overcome: i) how many cores should be allocated to each application at each point in time, and ii) how can an application change the number of threads spawned dynamically? Previous works [64,65,66,60,63,22,62] have proposed spatial scheduling approaches to improve the efficiency of the execution of parallel applications by tuning the thread-level parallelism (TLP). Only the approaches proposed by Moori et al and Srikanthan et al [66,65] consider graph applications.…”

“…Previous works [64,65,66,60,63,22,62] have proposed spatial scheduling approaches to improve the efficiency of the execution of parallel applications by tuning the thread-level parallelism (TLP). Only the approaches proposed by Moori et al and Srikanthan et al [66,65] consider graph applications. Moori et al [66] propose a static approach that decides the TLP before the application execution starts; thus, this is not applicable in dynamic environments.…”

“…• MAPPER. State-of-the-art approach proposed by Srikanthan et al [65], which controls the degree of parallelism of each application and the specific cores allocated.…”