Job Scheduling Strategies for Parallel Processing by Unknown

Author:Unknown
Language: eng
Format: epub
ISBN: 9783030106324
Publisher: Springer International Publishing

5.1 Microbenchmark Experiments

Microbenchmarks measure the performance of individual RP components in isolation. In a microbenchmark experiment, RP launches a pilot on a resource with a single unit scheduled onto the Agent. When the unit enters the component under investigation, it is cloned a specified number of times—10000 for experiments in this paper. The components operate on the clones, experiencing real loading while being stressed in isolation and independent of other components.

Microbenchmark experiments are designed to isolate a component by eliminating communication, coordination and concurrency with other components. In this way, the benchmarked component does not compete for shared system resources and communication channels, and remains immune from bottlenecks in other components. Thus, the microbenchmark measures the performance upper bound of a component implementation, as achieved in isolation from all types of overhead as a consequence of interaction with other components.

We perform microbenchmark experiments for the Scheduler and Executer components of RP Agent, the two components that most affect the overall performance of the RP Agent (see Fig. 4). For the Executer, we test two launch methods: ORTE-CLI, and ORTE-LIB. Note that these methods are not used by the executable of the units, but instead by the RP component to launch the executable. In turn, the executable could be single/multi-thread/process or use MPI itself. Depending on the launch methods, we run microbenchmarks load-balancing among 2, 4 and 8 Executer instances, executed on 1, 2, 4, and 8 compute nodes.

We perform microbenchmark experiments on Blue Waters as the representative Cray system. As noted before, the executable of the units has no bearing on the microbenchmarks. Microbenchmarking of the Scheduler component require no execution, while Executer benchmarking requires actual execution of the units. We use the sleep command to avoid any irrelevant complication deriving from setting up specific execution environments.

A full set of microbenchmarks would span a large parameter space, making it unfeasible to present the full set of experimental results. We focus on results which expose performance and scaling differences among the RP Agent components. This enables a better characterization of the overall performance of the Agent.

Agent Scheduler Performance. Currently, RP can instantiate exactly one Scheduler component per Agent. The Scheduler is compute and communication bound: the scheduling algorithm searches repeatedly through the list of managed cores, while core assignment and deassignment are handled in separate, message-driven threads.

Figure 6(a) shows the performance of the Scheduler component in assigning cores to one generation of single-core units, for four pilot sizes. We see that the throughput is dependent on the pilot size, and that the throughput rate declines as more units are scheduled. This is explained by the chosen scheduling algorithm and its implementation: the fewer free cores remain, the more work needs to be done by the scheduling algorithm to find a suitable set of cores for the next units. This behavior is a consequence of using one scheduler to handle workloads with both homogeneous and heterogeneous units (single/multi-core, mpi, cpu/gpu, etc.). In Sect. 5.3, we show how a special-purpose scheduler drastically improves performance.

Download

Copyright Disclaimer:
This site does not store any files on its server. We only index and link to content provided by other sites. Please contact the content providers to delete copyright contents if any and email us, we'll remove relevant links or contents immediately.