Since 1986 - Covering the Fastest Computers in the World and the People Who Run Them

Language Flags
November 13, 2013

Fair Pricing Key to Node Sharing in HPC

Alex Breslow, University of California San Diego
trendspotting

In HPC systems, jobs almost never share compute nodes. Each user requests the number of physical machines that they need to run their job, and then they run it in isolation.

While this practice was clearly the best choice for distributed applications in the pre-multi core era, the same is not necessarily true for the compute nodes of today, which integrate tens to hundreds of cores. Instead, distributed application co-location, whereby multiple parallel codes share the cores on sets of compute nodes, is a pragmatic choice for those seeking to optimize machine performance and power efficiency.

A previous study we did demonstrated co-locating pairs of 1024 process MPI jobs across 2048 cores decreases the run time of most applications and thus improves system throughput and energy efficiency by 10 to 20%.

Figure 1: An example of running 2 two-node jobs in isolation versus co-located: Switching from isolation (left) to co-location (right), where each socket is divided between applications improves system performance and energy efficiency.

Figure 1: An example of running 2 two-node jobs in isolation versus co-located: Switching from isolation (left) to co-location (right), where each socket is divided between applications improves system performance and energy efficiency.

However, not all applications benefit from distributed co-location: a significant number do slow down due to contention from their co-runners. While this slowdown is almost universally offset by gains in the performance of the co-running applications, and therefore still results in improved throughput, it causes an unfair inequity in pricing.This unfairness arises from the typical HPC accounting policy, which charges users proportionally to application run time. An example of this pricing unfairness is shown in Figure 2.  The plot shows the price a user running the GTC code would expect to pay when their job is co-run with each of the applications on the x-axis.  Under the current pricing model, the user would pay 60% more when their job is co-run with MILC instead of with AMG.

Figure 2: The current pricing mechanism (SOP) penalizes the user for co-locating their job by charging them more when their job degrades more.

Figure 2: The current pricing mechanism (SOP) penalizes the user for co-locating their job by charging them more when their job degrades more.

In this current pricing scheme, the user not only suffers from a decrease in utility caused by the increased job run time, but also faces an additional associated surcharge.  Our work, published and to be presented at SC’13 as one of the best paper candidates, targets this problem and introduces contention-aware fair pricing, where a user pays progressively less and less as their job is degraded more and more.

However, implementing such a policy is a challenge, as it requires a non-intrusive mechanism that precisely quantifies individual application degradation caused by co-running applications.  While previous work has employed offline profiling techniques to determine this degradation, we argue that such techniques are not always practical in a production setting, where online application behavior can significantly deviate from offline characterizations [3-6].  Instead we need a dynamic, lightweight, runtime system or OS service to detect such contention.

To satisfy these objectives, we have developed a low-overhead daemon, the Persistent Online Precise Pricing Agent (POPPA).  POPPA uses a fine-grain precise pricing shutter, a novel mechanism capable of measuring contention between applications with less than 1% overhead and with a mean absolute prediction error of 4%.  The shutter mechanism works by alternating the execution environment of each application between one where contention from co-runners is present, and one where it is effectively absent.  POPPA achieves this by cyclically pausing all but one application in a round-robin fashion and measuring the spike in the performance of the lone running application versus when it was co-located.

Figure 3: POPPA alternates application execution between isolation and co-location.  P and S are tunable parameters.

Figure 3: POPPA alternates application execution between isolation and co-location. P and S are tunable parameters.

The above shows the mechanism in action.  During the first phase, the POPPA daemon is dormant and threads from both applications execute.  Next, the instructions per cycle (IPC) of each application is derived from measurements taken using the hardware’s performance monitoring unit.  Then Job B is put to sleep, and the IPC of the Job A is measured.  Then Job B is woken up, and the IPC of both applications is measured.  This process then repeats but with Jobs A and B switching roles.

The POPPA daemon is fully parameterizable to allow for machine- and application-specific tradeoffs. In particular, we can configure the length of the periods between shutter events, the length of the shutter time, as well as the length for pre- and post-shutter measurements. Since each shutter requires all applications but one to sleep, the sleeping applications cannot make progress and thus lose performance during the shutter, which results in run time overhead.  By controlling the ratio between shutter time and shutter interval, this overhead can be carefully tuned to an acceptable value.  For our work, we decided on a shutter interval of 200 ms and a shutter length of 3.2 ms, as these values offered high prediction accuracy while keeping the average overhead under 1%.

This mechanism allows POPPA to be highly accurate, with a mean absolute error of 4%. The low prediction error stems from the fact that the system does not rely on a single measurement for determining degradation estimates, but rather can base its analysis on hundreds to thousands of fine-grain measurements that are uniformly spaced throughout the execution of each co-running application.  As a result, POPPA detects phase-level behaviors in applications that allow it to construct more accurate prediction estimates.

Based on these predictions, we then implement a fair pricing strategy and discount the user relative to their predicted degradation due to co-runner interference.  Our philosophy is that when a user’s application is degraded by 20%, the simplest and most intuitive pricing policy is to discount that user by 20%.  This policy allows the user to easily reason about how they will be priced and to also reap the benefit of a discount, which directly compensates for the additional time taken to run their job.  This compensation encourages users to embrace co-location, as the discounts allow their resource allocation to go further.

The art of precise and fair pricing is a key for designing future, agile, software systems and opens the door to new ways to utilize the rising class of multi- and many-core nodes.  If this article has piqued your interest, we invite you to our talk at the SC’13 conference (Title: “Enabling Fair Pricing on HPC Systems with Node Sharing”, to be presented on November 20th at 10:30AM in rooms 401/402/403). The contact author for this work is Alex Breslow, PhD student at the University of California San Diego.  Ananta Tiwari and Laura Carrington are research scientists at San Diego Supercomputer Center, Martin Schulz is a computer scientist at Lawrence Livermore National Laboratory, and  Lingjia Tang and Jason Mars are assistant professors in the University of Michigan EECS Department.

See Also:

 Cache pirating: Measuring the Curse of the Shared Cache. In Parallel Processing (ICPP)

Quantifying Effects of Shared On-chip Resource Interference for Consolidated Virtual Machines

Bubble-up: Increasing Utilization in Modern Warehouse Scale Computers via Sensible Co-locations

Managing Performance Interference Effects for QoS-Aware Clouds

SC14 Virtual Booth Tours

AMD SC14 video AMD Virtual Booth Tour @ SC14
Click to Play Video
Cray SC14 video Cray Virtual Booth Tour @ SC14
Click to Play Video
Datasite SC14 video DataSite and RedLine @ SC14
Click to Play Video
HP SC14 video HP Virtual Booth Tour @ SC14
Click to Play Video
IBM DCS3860 and Elastic Storage @ SC14 video IBM DCS3860 and Elastic Storage @ SC14
Click to Play Video
IBM Flash Storage
@ SC14 video IBM Flash Storage @ SC14  
Click to Play Video
IBM Platform @ SC14 video IBM Platform @ SC14
Click to Play Video
IBM Power Big Data SC14 video IBM Power Big Data @ SC14
Click to Play Video
Intel SC14 video Intel Virtual Booth Tour @ SC14
Click to Play Video
Lenovo SC14 video Lenovo Virtual Booth Tour @ SC14
Click to Play Video
Mellanox SC14 video Mellanox Virtual Booth Tour @ SC14
Click to Play Video
Panasas SC14 video Panasas Virtual Booth Tour @ SC14
Click to Play Video
Quanta SC14 video Quanta Virtual Booth Tour @ SC14
Click to Play Video
Seagate SC14 video Seagate Virtual Booth Tour @ SC14
Click to Play Video
Supermicro SC14 video Supermicro Virtual Booth Tour @ SC14
Click to Play Video