Periodic I/O scheduling for super-computers

TL;DR

This paper introduces a periodic I/O scheduling strategy for supercomputers that leverages the predictable nature of HPC applications to reduce congestion and improve efficiency without online computation overhead.

Contribution

The paper presents a novel periodic scheduling approach that pre-computes I/O patterns during job scheduling, enabling independent execution and reducing congestion compared to online methods.

Findings

Reduces I/O congestion at the node level

Improves application dilation by up to 13%

Enhances system efficiency by up to 18%

Abstract

With the ever-growing need of data in HPC applications, the congestion at the I/O level becomes critical in super-computers. Architectural enhancement such as burst-buffers and pre-fetching are added to machines, but are not sufficient to prevent congestion. Recent online I/O scheduling strategies have been put in place, but they add an additional congestion point and overheads in the computation of applications. In this work, we show how to take advantage of the periodic nature of HPC applications in order to develop efficient periodic scheduling strategies for their I/O transfers. Our strategy computes once during the job scheduling phase a pattern where it defines the I/O behavior for each application, after which the applications run independently, transferring their I/O at the specified times. Our strategy limits the amount of I/O congestion at the I/O node level and can be easily integrated into current job schedulers. We validate this model through extensive simulations and experiments by comparing it to state-of-the-art online solutions, showing that not only our scheduler has the advantage of being de-centralized and thus overcoming the overhead of online schedulers, but also that it performs better than these solutions, improving the application dilation up to 13% and the maximum system efficiency up to 18%.

Tables

Table 1. Table 1: Details of each application.

${\text{App}}^{\left(k\right)}$		$w^{\left(k\right)}$ (s)	${\text{vol}}_{\text{io}}^{\left(k\right)}$ (GB)	${\beta }^{\left(k\right)}$
Turbulence1	(T1)	70	128.2	32,768
Turbulence2	(T2)	1.2	235.8	4,096
AstroPhysics	(AP)	240	423.4	8,192
PlasmaPhysics	(PP)	7554	34304	32,768

Table 2. Table 2: Number of applications of each type launched at the same time for each experiment scenario.

Set #	T1	T2	AP	PP
1	0	10	0	0
2	0	8	1	0
3	0	6	2	0
4	0	4	3	0
5	0	2	0	1
6	0	2	4	0
7	1	2	0	0
8	0	0	1	1
9	0	0	5	0
10	1	0	1	0

Table 3. Table 3: Bandwidth slowdown, performance and application slowdown for each set of experiments

Set #	Application	BW slowdown	SysEfficiency
1	Turbulence 2	65.72%	0.064561
2	Turbulence 2	63.93%	0.250105
	AstroPhysics	38.12%
3	Turbulence 2	56.92%	0.439038
	AstroPhysics	30.21%
4	Turbulence 2	34.9%	0.610826
	AstroPhysics	24.92%
6	Turbulence 2	34.67%	0.621977
	AstroPhysics	52.06%
10	Turbulence 1	11.79%	0.98547
	AstroPhysics	21.08%

Table 4. Table 4: Best Dilation and SysEfficiency for our periodic heuristic and online heuristics.

Set	Min	Upper bound	PerSched		Online
	Dilation	SysEff	Dilation	SysEff	Dilation	SysEff
1	1.777	0.172	1.896	0.0973	2.091	0.0825
2	1.422	0.334	1.429	0.290	1.658	0.271
3	1.079	0.495	1.087	0.480	1.291	0.442
4	1.014	0.656	1.014	0.647	1.029	0.640
5	1.010	0.816	1.024	0.815	1.039	0.810
6	1.005	0.818	1.005	0.814	1.035	0.761
7	1.007	0.827	1.007	0.824	1.012	0.818
8	1.005	0.977	1.005	0.976	1.005	0.976
9	1.000	0.979	1.000	0.979	1.004	0.978
10	1.009	0.988	1.009	0.986	1.015	0.985

Table 5. Table 5: Maximum number of instances ( n inst subscript 𝑛 inst n_{\text{inst}} ) per application, ratio between longest and shortest application ( n max subscript 𝑛 n_{\max} ) in the solution returned by PerSched .

Set	$n_{\text{inst}}$	$n_{\max }$
1	11	1.00
2	25	35.2
3	33	35.2
4	247	35.2
5	1086	1110

Equations

$${\tilde{\rho }}^{(k)}(t)=\frac{{\sum }_{i\le n^{(k)}(t)}{w}^{(k,i)}}{t-r_k},$$

$${\rho }^{(k)}=\frac{w^{(k)}}{w^{(k)}+{\text{time}}_{\text{io}}^{(k)}}$$

$$\text{maximize }\frac{1}{N}\sum _{k=1}^K{\beta }^{(k)}{\tilde{\rho }}^{(k)}(d_k).$$

$$\text{minimize }\underset{k=\mathrm{1..}K}{\max }\frac{{\rho }^{(k)}}{{\tilde{\rho }}^{(k)}(d_k)}.$$

$${\int }_{{\text{initIO}}_i^{(k)}}^{{\text{initW}}_{(i+1)\%n_{\text{per}}^{(k)}}^{(k)}}{\beta }^{(k)}{\gamma }^{(k)}(t)dt={\text{vol}}_{\text{io}}^{(k)}.$$

$${\tilde{\rho }}_{\text{per}}^{(k)}=\frac{n_{\text{per}}^{(k)}{w}^{(k)}}{T}.$$

$${\tilde{\rho }}^{(k)}(d_k)$$

$$\approx \frac{n_{\text{per}}^{(k)}{w}^{(k)}}{T}={\tilde{\rho }}_{\text{per}}^{(k)}$$

$$\mathcal{P}={\cup }_{k=1}^K\left(n_{\text{per}}^{(k)},{\cup }_{i=1}^{n_{\text{per}}^{(k)}}\{{\text{initW}}_i^{(k)},{\text{initIO}}_i^{(k)},{\gamma }^{(k)}()\}\right),$$

$${\int }_{{\text{initW}}_i^{(k)}+w^{(k)}}^{{\text{initIO}}_i^{(k)}-w^{(k)}}\min \left({\beta }^{(k)}b,B-\sum _l{\beta }^{(l)}{\gamma }^{(l)}(t)\right)dt\ge {\text{vol}}_{\text{io}}^{(k)}$$

$$O\left(\left(\lceil \frac{1}{\epsilon }\rceil +\lceil \frac{\log K^{\prime }}{\log (1+\epsilon )}\rceil \right)\cdot K^2\left(n_{\max }+\log K^{\prime }\right)\right).$$

$$\{{\text{App}}^{(k)}|{\text{App}}^{(k)}\text{ is not yet known to not be schedulable}\}$$

$$\mathcal{P}={\cup }_{k=1}^K\left(n_{\text{per}}^{(k)},{\cup }_{i=1}^{n_{\text{per}}^{(k)}}\{{\text{initW}}_i^{(k)},{\text{initIO}}_i^{(k)},{\gamma }^{(k)}()\}\right)$$

$${\int }_{{\text{initW}}_i^{(k)}+w^{(k)}}^{{\text{initIO}}_i^{(k)}-w^{(k)}}\min \left({\beta }^{(k)}b,B-\sum _l{\beta }^{(l)}{\gamma }^{(l)}(t)\right)dt<{\text{vol}}_{\text{io}}^{(k)},$$

$${\int }_{{\text{initW}}_i^{(k)}+w^{(k)}}^{{\text{initIO}}_i^{(k)}-w^{(k)}}\min \left({\beta }^{(k)}b,B-\sum _l{\beta }^{(l)}{{\gamma }^{\prime }}^{(l)}(t)\right)dt<{\text{vol}}_{\text{io}}^{(k)}.$$

$$\mathcal{A}=\{{\text{App}}^{(k)}|{\text{App}}^{(k)}\text{ is schedulable}\}\subset \tilde{\mathcal{A}}.$$

$$\text{textsc}Sys\text{-}Effi\text{-}ciency(\mathcal{P})$$

$$=\frac{{\sum }_k{\beta }^{(k)}{n}_{\text{per}}^{(k)}{w}^{(k)}}{T}.$$

$$\text{textsc}Sys\text{-}Effi\text{-}ciency(\mathcal{P})$$

$$\frac{T_{\text{opt}}}{1+\epsilon }\text{textsc}Sys\text{-}Effi\text{-}ciency(\mathcal{P})$$

$$m=\frac{\log T_{\max }-\log T_{\min }}{\log (1+\epsilon )}=\frac{\log K^{\prime }}{\log (1+\epsilon )}.$$

$$O\left(\left(\lceil m\rceil +\lceil \frac{1}{\epsilon }\rceil \right)\left(K^2\log K+K^2{n}_{\max }\right)\right).$$

$$\text{Upper bound}=\frac{1}{N}\sum _{k=1}^K\frac{{\beta }^{(k)}{w}^{(k)}}{w^{(k)}+{\text{time}}_{\text{io}}^{(k)}}.$$

$$\frac{\text{textsc}Sys\text{-}Effi\text{-}ciency(K^{\prime })}{\text{textsc}Sys\text{-}Effi\text{-}ciency(100)}\left(\text{resp. }\frac{\text{textsc}Dilation(K^{\prime })}{\text{textsc}Dilation(100)}\right)$$

Full text

In this work, we show how to take advantage of the periodic nature of HPC applications in order to develop efficient periodic scheduling strategies for their I/O transfers. Our strategy computes once during the job scheduling phase a pattern where it defines the I/O behavior for each application, after which the applications run independently, transferring their I/O at the specified times. Our strategy limits the amount of I/O congestion at the I/O node level and can be easily integrated into current job schedulers. We validate this model through extensive simulations and experiments by comparing it to state-of-the-art online solutions, showing that not only our scheduler has the advantage of being de-centralized and thus overcoming the overhead of online schedulers, but also that it performs better than these solutions, improving the application dilation up to 13% and the maximum system efficiency up to 18%.

1 Introduction

In the race to larger supercomputers, the most commonly used metric is is the computational power. However supercomputers are not simply computers with billions of processors. One of the reason why Sunway TaihuLight (the world fastest supercomputer as of Nov 2016 [1]), reaches 93 PetaFlops on HPL (a performance benchmark based on dense linear algebra), but struggles to reach 0.37 PetaFlop on HPCG, a recent benchmark based on actual HPC applications [10] is data movement. Nowadays, a supercomputing application creates or has to deal with TeraBytes of data. This is true in all fields, from medical research (Brain initiatives), to astrophysics (HACC [16], Enzo [5], HOMME [24]), including meteorology (CM1 [4]) and fusion plasma (GTC [13]). In 2013, Argonne upgraded its house supercomputer: moving from Intrepid (peak performance: 0.56 PFlops; peak I/O throughput: 88 GB/s) to Mira (peak performance: 10 PFlops; peak I/O throughput: 240 GB/s). While both criteria seem to have improved considerably, the reality behind is that for a given application, its I/O throughput scales linearly (or worse) with its performance, and hence, what should be noticed is a downgrade from 160 GB/PFlop to 24 GB/PFlop! On Intrepid, it was shown that I/O congestion could cause up to a 70% decrease to the I/O throughput [14].

To help with the ever growing amount of data created, architectural improvement such as burst buffers [21] have been added to the system. Work is being done to transform the data before sending it to the disks in the hope of reducing the I/O sent [11]. However, even with the current I/O footprint burst buffers are not able to completely hide congestion. Moreover, the data used is always expected to grow. Recent works [14] have started working on novel online, centralized I/O scheduling strategies at the I/O node level. However one of the risk noted on these strategies is the scalability issue caused by potentially high overheads (between 1 and 5% depending on the number of nodes used in the experiments) [14]. Moreover, it is expected this overhead to increase at larger scale since it need centralized information about all applications running in the system.

In this paper, we present a decentralized I/O scheduling strategy for super-computers. We show how to take known HPC application behaviors (namely their periodicity) into account to derive novel static algorithms. The periodicity of HPC applications has been well observed and documented [6, 14, 12]: HPC applications alternate between computation and I/O transfer, this pattern being repeated over-time. Furthermore, fault-tolerance technique (such as periodic checkpointing [9]) also add to this periodic behavior. Using this periodicity property, we compute a static periodic scheduling strategy, which provides a way for each applications to know when they should start transferring their I/O (i) hence reducing potential bottlenecks either due to I/O congestion, and (ii) without having to consult with I/O nodes every time I/O should be done and hence adding an extra overhead. The main contributions of this paper are:

• •

A novel light-weight I/O algorithm that looks at optimizing both application-oriented (dilation or fairness) and platform-oriented (maximum system efficiency) objectives;

• •

A set of extensive simulations and experiments that show that this algorithm performs as well or better than current state of the art heavy-weight online algorithms.

Note that the algorithm presented here is done as a proof of concept to show the efficiency of this kind of light-weight techniques. We believe our scheduler can be implemented naturally into a job scheduler and we provide experimental results backing this claim. However, this integration is beyond the scope of this paper.

The rest of the paper is organized as follows: in Section 2 we present the application model and optimization problem. In Section 3 we present our novel algorithm technique as well as a brief proof of concept for a future implementation. In Section 4 we present extensive simulations based on the model to show the performance of our algorithm compared to state of the art. We then confirm the performance on a super-computer to validate the model. We give some background and related work in Section 5. We provide concluding remarks and ideas for future research directions in Section 6.

2 Model

In this section we use the model introduced in our previous work [14] that has been verified experimentally to be consistent with the behavior of Intrepid and Mira, super-computers at Argonne.

We consider scientific applications running at the same time on a parallel platform. The applications consist of series of computations followed by I/O operations. On a super-computer, the computations are done independently because each application uses its own nodes. However, the applications are concurrently sending and receiving data during their I/O phase on a dedicated I/O network. The consequence of this I/O concurrency is congestion between an I/O node of the platform and the file storage.

2.1 Parameters

We assume that we have a parallel platform made up of $N$ identical unit-speed nodes, composed of the same number of identical processors, each equipped with an I/O card of bandwidth $b$ (expressed in bytes per second). We further assume a centralized I/O system with a total bandwidth $B$ (also expressed in bytes per second). This means that the total bandwidth between the computation nodes and an I/O node is $N\cdot b$ while the bandwidth between an I/O node and the file storage is $B$, with usually $N\cdot b\gg B$. We have instantiated this model for the Intrepid platform on Figure 1.

We have $K$ applications, all assigned to independent and dedicated computational resources, but competing for I/O. For each application $\text{App}^{(k)}$ we define:

• •

Its size: $\text{App}^{(k)}$ executes with $\beta^{(k)}$ dedicated processors;

• •

Its pattern: $\text{App}^{(k)}$ obeys a pattern that repeats over time. There are $n_{\text{tot}}^{(k)}$ instances of $\text{App}^{(k)}$ that are executed one after the other. Each instance consists of two disjoint phases: computations that takes a time $w^{(k)}$, followed by I/O transfers for a total volume $\text{vol}_{\text{io}}^{(k)}$. The next instance cannot start before I/O operations for the current instance is terminated.

We further denote by $r_{k}$ the time when $\text{App}^{(k)}$ is released on the platform and $d_{k}$ the time when the last instance is completed. Finally, we denote by $\gamma^{(k)}(t)$, the bandwidth used by a node on which application $\text{App}^{(k)}$ is running, at instant $t$.

2.2 Execution Model

As the computation resources are dedicated, we can always assume w.l.o.g that the next computation chunk starts right away after completion of the previous I/O transfers, and is executed at full (unit) speed. On the contrary, all applications compete for I/O, and congestion will likely occur. The simplest case is that of a single periodic application $\text{App}^{(k)}$ using the I/O system in dedicated mode during a time-interval of duration $D$. In that case, let $\gamma$ be the I/O bandwidth used by each processor of $\text{App}^{(k)}$ during that time-interval. We derive the condition $\beta^{(k)}\gamma D=\text{vol}_{\text{io}}^{(k)}$ to express that the entire I/O data volume is transferred. We must also enforce the constraints that (i) $\gamma\leq b$ (output capacity of each processor); and (ii) $\beta^{(k)}\gamma\leq B$ (total capacity of I/O system). Therefore, the minimum time to perform the I/O transfers for an instance of $\text{App}^{(k)}$ is $\text{time}_{\text{io}}^{(k)}=\frac{\text{vol}_{\text{io}}^{(k)}}{\min(\beta^{(k)}b,B)}$. However, in general many applications will use the I/O system simultaneously, whose bandwidth capacity $B$ will be shared among all these applications (see Figure 2).

This model is very flexible, and the only assumption is that at any instant, all processors assigned to a given application are assigned the same bandwidth. This assumption is transparent for the I/O system and simplifies the problem statement without being restrictive. Again, in the end, the total volume of I/O transfers for an instance of $\text{App}^{(k)}$ must be $\text{vol}_{\text{io}}^{(k)}$, and at any instant, the rules of the game are simple: never exceed the individual bandwidth $b$ of each processor ($\gamma^{(k)}(t)\leq b$ for any $k$ and $t$), and never exceed the total bandwidth $B$ of the I/O system ($\sum\limits_{k=1}^{K}\beta^{(k)}\gamma^{(k)}(t)\leq B$ for any $t$).

2.3 Objectives

We now focus on the optimization objectives at hand here. We use the objectives introduced in [14].

First, the application efficiency achieved for each application $\text{App}^{(k)}$ at time $t$ is defined as

[TABLE]

where $n^{(k)}\!(t)\leq n_{\text{tot}}^{(k)}$ is the number of instances of application $\text{App}^{(k)}$ that have been executed at time $t$, since the release of $\text{App}^{(k)}$ at time $r_{k}$. Because we execute $w^{(k,i)}$ units of computation followed by $\text{vol}_{\text{io}}^{(k,i)}$ units of I/O operations on instance $\mathcal{I}^{(k)}_{i}$ of $\text{App}^{(k)}$, we have $t-r_{k}\geq\sum_{i\leq n^{(k)}(t)}\left(w^{(k,i)}+\text{time}_{\text{io}}^{(k,i)}\right)$. Due to I/O congestion, $\tilde{\rho}^{(k)}$ never exceeds the optimal efficiency that can be achieved for $\text{App}^{(k)}$, namely

[TABLE]

The two key optimization objectives, together with a rationale for each of them, are:

• •

SysEfficiency: where we maximize the peak performance of the platform, namely maximizing the amount of operations per time unit:

[TABLE]

• •

Dilation: where we minimize the largest slowdown imposed to each application (hence optimizing fairness across applications):

[TABLE]

Note that it is known that both problems are NP-complete, even in an (easier) offline setting [14].

3 Periodic scheduling strategy

In general, for an application $\text{App}^{(k)}$, $n_{\text{tot}}^{(k)}$ the number of instances of $\text{App}^{(k)}$ is very large and not polynomial in the size of the problem. For this reason, online schedule have been preferred until now. The key novelty of this paper is to introduce periodic schedules for the $K$ applications. Intuitively, we are looking for a computation and I/O pattern of duration $T$ that will be repeated over time (except for initialization and clean up phases), as shown on Figure 3a. In this section, we start by introducing the notion of periodic schedules and a way to compute the application efficiency differently. We then provide the algorithms that are at the core of this work.

Because there is no competition on computation (no shared resources), we can consider that a chunk of computation directly follows the end of the transfer of I/O, hence we need only to represent I/O transfers in this pattern. The bandwidth used by each application during the I/O operations is represented over time, as shown in Figure 3b. We can see that an operation can overlap with the one of the previous pattern or the next pattern, but overall, the pattern will just repeat.

To describe a pattern, we use the following notations:

• •

$n_{\text{per}}^{(k)}$: the number of instances of $\text{App}^{(k)}$ during a pattern.

• •

$\mathcal{I}^{(k)}_{i}$: the $i$-th instance of $\text{App}^{(k)}$ during a pattern.

• •

$\texttt{initW}^{(k)}_{i}$: the time of the beginning of $\mathcal{I}^{(k)}_{i}$. So, $\mathcal{I}^{(k)}_{i}$ has a computation interval going from $\texttt{initW}^{(k)}_{i}$ to $\texttt{endW}^{(k)}_{i}=\texttt{initW}^{(k)}_{i}+w^{(k)}\text{ mod }T$.

• •

$\texttt{initIO}^{(k)}_{i}$: the time when the I/O transfer from the $i$-th instance of $\text{App}^{(k)}$ starts (between $\texttt{endW}^{(k)}_{i}$ and $\texttt{initIO}^{(k)}_{i}$, $\text{App}^{(k)}$ is idle). Therefore, we have

[TABLE]

Globally, if we consider the two dates per instance $\texttt{initW}^{(k)}_{i}$ and $\texttt{initIO}^{(k)}_{i}$, that define the change between computation and I/O phases, we have a total of $S\leq\sum_{k=1}^{K}2n_{\text{per}}^{(k)}$ distinct dates, that are called the events of the pattern.

We define the periodic efficiency of a pattern of size $T$:

[TABLE]

For periodic schedules, we use it to approximate the actual efficiency achieved for each application. The rationale behind this can be seen on Figure 3. If $\text{App}^{(k)}$ is released at time $r_{k}$, and the first pattern starts at time $r_{k}+c$, that is after an initialization phase, then the main pattern is repeated $n$ times (until time $n\cdot T+r_{k}+c$), and finally $\text{App}^{(k)}$ ends its execution after a clean-up phase at time $d_{k}=r_{k}+c+n\cdot T+c^{\prime}$. If we assume that $n\cdot T\gg c+c^{\prime}$, then $d_{k}-r_{k}\approx n\cdot T$. Then the value of the $\tilde{\rho}^{(k)}(d_{k})$ for $\text{App}^{(k)}$ is:

[TABLE]

where $\delta$ can be 1 or 0 depending whether $\text{App}^{(k)}$ was executed or not during the clean-up or init phase.

3.1 PerSched: a periodic scheduling algorithm

For details in the implementation, we refer the interested reader to the source code available at https://github.com/vlefevre/IO-scheduling-simu.

The difficulties of finding an efficient periodic schedule are three-fold:

• •

The first one is that the right pattern size has to be determined;

• •

The second one is that for a given pattern size, the number of instances of each application that should be included in this pattern need to be determined;

• •

Finally, the time constraint between two consecutive I/O transfers of a given application, due to the computation in-between makes naive scheduling strategies harder to implement.

Finding the right pattern size

A solution is to find schedules with different pattern sizes between a minimum pattern size $T_{\min}$ and a maximum pattern size $T_{\max}$.

Because we want a pattern to have at least one instance of each application, we can trivially set up $T_{\min}=\max_{k}(w^{(k)}+\text{time}_{\text{io}}^{(k)})$. Intuitively, the larger $T_{\max}$ is, the more possibilities we can have to find a good solution. However this also increases the complexity of the algorithm. We want to limit the number of instances of all applications in a schedule. For this reason we chose to have $T_{\max}=O(\max_{k}(w^{(k)}+\text{time}_{\text{io}}^{(k)}))$. We discuss this hypothesis in Section 4, where we give better experimental intuition on finding the right value for $T_{\max}$. Experimentally we observe (Section 4, Figure 7) that $T_{\max}=10T_{\min}$ seems to be sufficient.

We then decided on an iterative search where the pattern size increases exponentially at each iteration from $T_{\min}$ to $T_{\max}$. In particular, we use a precision $\varepsilon$ as input and we iteratively increase the pattern size from $T_{\min}$ to $T_{\max}$ by a factor $(1+\varepsilon)$. This allows us to have a polynomial number of iterations. The rationale behind the exponential increase is that when the pattern size gets large, we expect performance to converge to an optimal value, hence needing less the precision of a precise pattern size. Furthermore while we could try only large pattern size, it seems important to find a good small pattern size as it would simplify the scheduling step. Hence a more precise search for smaller pattern sizes. Finally, we expect the best performance to cycle with the pattern size. We verify these statements experimentally in Section 4 (Figure 6).

Determining the number of instances of each application

By choosing $T_{\max}=O(\max_{k}(w^{(k)}+\text{time}_{\text{io}}^{(k)}))$, we guarantee the maximum number of instances of each application that fit into a pattern is $O\left(\frac{\max_{k}(w^{(k)}+\text{time}_{\text{io}}^{(k)})}{\min_{k}(w^{(k)}+\text{time}_{\text{io}}^{(k)})}\right)$.

Instance scheduling

Finally, our last item is, given a pattern of size $T$, how to schedule instances of applications into a periodic schedule.

To do this, we decided on a strategy where we insert instances of applications in a pattern, without modifying dates and bandwidth of already scheduled instances. Formally, we call an application schedulable:

Definition 1** (Schedulable).**

Given an existing pattern

[TABLE]

we say that an application $\text{App}^{(k)}$ is schedulable if there exists $1\leq i\leq n_{\text{per}}^{(k)}$, such that:

[TABLE]

To understand the integral in Equation (4): we are checking that during the end of the computation of the $i^{\text{th}}$ instance ($\texttt{initW}^{(k)}_{i}+w^{(k)}$), and the beginning of the computation of the $i+1^{\text{th}}$ instance ($\texttt{initIO}^{(k)}_{i}$-$w^{(k)}$), there is enough bandwidth to perform at least a volume of I/O of $\text{vol}_{\text{io}}^{(k)}$. We represent it graphically on Figure 4.

With Definition 1, we can now explain the core idea of the instance scheduling part of our algorithm. Starting from an existing pattern, while there exist applications that are schedulable:

• •

Amongst the applications that are schedulable, we choose the application that has the worse Dilation. The rationale is that even though we want to increase SysEfficiency, we do it in a way that ensures that all applications are treated fairly;

• •

We insert the instance into an existing scheduling using a procedure Insert-In-Pattern such that (i) the first instance of each application is inserted using procedure Insert-First-Instance which minimizes the time of the I/O transfer of this new instance, (ii) the other instances are inserted just after the last inserted one.

Note that Insert-First-Instance is implemented using a water-filling algorithm [15] and Insert-In-Pattern is implemented as described in Algorithm 1. We use a different function for the first instance of each application because we do not have any previous instance to use the Insert-In-Pattern function. Thus, the basic idea would be to put them at the beginning of the pattern, but it will be more likely to create congestion if all applications are “synchronized” (for example if all the applications are the same, they will all start their I/O phase at the same time). By using Insert-First-Instance, every first instance will be at a place where the congestion for it is minimized. This creates a starting point for the subsequent instances.

The function addInstance updates the pattern with the new instance, given a list of the intervals $(\mathcal{E}_{l},\mathcal{E}_{l^{\prime}},b_{l})$ during which $\text{App}^{(k)}$ transfers I/O between $\mathcal{E}_{l}$ and $\mathcal{E}_{l^{\prime}}$ using a bandwidth $b_{l}$.

Correcting the period size

In Algorithm 2, the pattern sizes under trial are determined by $T_{\min}$ and $\varepsilon$. There is no reason why this would be the right pattern size, and one might be interested in reducing it to fit precisely the instances that are included in the solutions that we found.

In order to do so, once a periodic pattern has been computed, we try to improve the best pattern size we found in the first loop of the algorithm, by trying new pattern sizes, close to the previous best one, let us say $T_{\text{opt}}$. To do this, we add a second loop which now tries $1/\varepsilon$ uniformly distributed pattern sizes from $T_{\text{opt}}$ to $T_{\text{opt}}/(1+\varepsilon)$.

With all of this in mind, we can now write PerSched (Algorithm 2), our algorithm to construct a periodic pattern. For all pattern sizes tried between $T_{\min}$ and $T_{\max}$, we return the pattern with maximal SysEfficiency.

3.2 Complexity analysis

Finally, in this section we show that our algorithm runs in reasonnable execution time. We detail theoretical results that allowed us to reduce the complexity. We want to show the following result:

Theorem 1**.**

*Let $n_{\max}=\left(\frac{\max_{k}(w^{(k)}+\text{time}_{\text{io}}^{(k)})}{\min_{k}(w^{(k)}+\text{time}_{\text{io}}^{(k)})}\right)$,

$\textsc{PerSched}(K^{\prime},\varepsilon,\{\text{App}^{(k)}\}_{1\leq k\leq K})$ runs in*

[TABLE]

Some of the complexity results are straightforward. The key results to show are:

• •

The complexity of the tests “while exists a schedulable application” on lines 2 and 2

• •

The complexity of computing $\mathcal{A}$ and finding its minimum element on line 2 and 2.

• •

The complexity of Insert-In-Pattern

To reduce the execution time, we proceed as follows: instead of implementing the set $\mathcal{A}$, we implement a heap $\tilde{\mathcal{A}}$ that could be summarized as

[TABLE]

sorted following the lexicographic order: $\left(\frac{\rho^{(k)}}{\tilde{\rho}_{\text{per}}^{(k)}},\frac{w^{(k)}}{\text{time}_{\text{io}}^{(k)}}\right)$. Hence, we replace the while loops on lines 2 and 2 by the algorithm snippet described in Algorithm 3. The idea is to avoid calling Insert-In-Pattern after each new inserted instance to know which applications are schedulable.

We then need to show that they are equivalent, that is:

• •

At all time, the minimum element of $\tilde{\mathcal{A}}$ is minimal amongst the schedulable applications with respect to the order $\left(\frac{\rho^{(k)}}{\tilde{\rho}_{\text{per}}^{(k)}},\frac{w^{(k)}}{\text{time}_{\text{io}}^{(k)}}\right)$ (shown in Lemma 4);

• •

If $\tilde{\mathcal{A}}=\emptyset$ then there are no more schedulable applications (shown in Corollary 2).

To show this, it is sufficient to show that (i) at all time, $\mathcal{A}\subset\tilde{\mathcal{A}}$, and (ii) $\tilde{\mathcal{A}}$ is always sorted according to $\left(\frac{\rho^{(k)}}{\tilde{\rho}_{\text{per}}^{(k)}},\frac{w^{(k)}}{\text{time}_{\text{io}}^{(k)}}\right)$.

Definition 2** (Compact pattern).**

We say that a pattern

[TABLE]

is compact if for all $1\leq i<n_{\text{per}}^{(k)}$, either $\texttt{initW}^{(k)}_{i}+w^{(k)}=\texttt{initIO}^{(k)}_{i}$, or for all $t\in[\texttt{initW}^{(k)}_{i},\texttt{initIO}^{(k)}_{i}]$, $\sum_{l}\beta^{(l)}\gamma^{(l)}(t)=B$.

Intuitively, this means that we can only schedule a new instance for all application $\text{App}^{(k)}$ between $\mathcal{I}^{(k)}_{n_{\text{per}}^{(k)}}$ and $\mathcal{I}^{(k)}_{1}$.

Lemma 1**.**

At any time during PerSched, $\mathcal{P}$ is compact.

Proof.

For each application, either we use Insert-First-Instance to insert the first instance (so $\mathcal{P}$ is compact as there is only one instance of an application at this step), either we use Insert-In-Pattern which inserts an instance just after the last inserted one, which is the definition of being compact. Hence, $\mathcal{P}$ is compact at any time during PerSched. ∎

Lemma 2**.**

$\textsc{Insert-In-Pattern}(\mathcal{P},\text{App}^{(k)})$* returns $\mathcal{P}$, if and only if $\text{App}^{(k)}$ is not schedulable.*

Proof.

One can easily check that Insert-In-Pattern checks the schedulability of $\text{App}^{(k)}$ only between the last inserted instance of $\text{App}^{(k)}$ and the first instance of $\text{App}^{(k)}$. Furthermore, because of the compacity of $\mathcal{P}$ (Lemma 1), this is sufficient to test the overall schedulability.

Then the test is provided by the last condition $\texttt{Dataleft}>0$.

• •

If the condition is false, then the algorithm actually inserts a new instance, so it means that one more instance of $\text{App}^{(k)}$ is schedulable.

• •

If the condition is true, it means that we cannot insert a new instance after the last inserted one. Because $\mathcal{P}$ is compact, we cannot insert an instance at another place. So if the condition is true, we cannot add one more instance of $\text{App}^{(k)}$ in the pattern.

∎

Corollary 1**.**

In Algorithm 3, an application $\text{App}^{(k)}$ is removed from $\tilde{\mathcal{A}}$ if and only if it is not schedulable.

Lemma 3**.**

If an application is not schedulable at some step, it will not be either in the future.

Proof.

Let us suppose that $\text{App}^{(k)}$ is not schedulable at some step. In the future, new instances of other applications can be added, thus possibly increasing the total bandwidth used at each instant. The total I/O load is non-decreasing during the execution of the algorithm. Thus if for all $i$, we had

[TABLE]

then in the future, with new bandwidths used ${\gamma^{\prime}}^{(l)}(t)>\gamma^{(l)}(t)$, we will still have that for all $i$,

[TABLE]

∎

Corollary 2**.**

At all time,

[TABLE]

This is a direct corollary of Corollary 1 and Lemma 3

Lemma 4**.**

At all time, the minimum element of $\tilde{\mathcal{A}}$ is minimal amongst the schedulable applications with respect to the order $\left(\frac{\rho^{(k)}}{\tilde{\rho}_{\text{per}}^{(k)}},\frac{w^{(k)}}{\text{time}_{\text{io}}^{(k)}}\right)$ (but not necessarily schedulable).

Proof.

First see that $\{\text{App}^{(k)}|\text{App}^{(k)}\text{ is schedulable}\}\subset\tilde{\mathcal{A}}$.

Furthermore, initially the minimality property is true. Then the set $\tilde{\mathcal{A}}$ is modified only when a new instance of an application is added to the pattern. More specifically, only the application that was modified has its position in $\tilde{\mathcal{A}}$ modified. One can easily verify that for all other applications, their order with respect to $\left(\frac{\rho^{(k)}}{\tilde{\rho}_{\text{per}}^{(k)}},\frac{w^{(k)}}{\text{time}_{\text{io}}^{(k)}}\right)$ has not changed, hence the set is still sorted. ∎

This concludes the proof that the snippet is equivalent to the while loops. With all this we are now able to show timing results for the version of Algorithm 2 that uses Algorithm 3.

Lemma 5**.**

The loop on line 2 of Algorithm 2 terminates in at most $\lceil 1/\varepsilon\rceil$ steps.

Proof.

The stopping criteria on line 2 checks that the number of instances did not change when reducing the pattern size. Indeed, by definition for a pattern $\mathcal{P}$,

[TABLE]

Denote SE the SysEfficiency reached in $T_{\text{opt}}$ at the end of the while loop on line 2 of Algorithm 2. Let $\textsc{Sys\-Effi\-ciency}(\mathcal{P})$ be the SysEfficiency obtained in $T_{\text{opt}}/(1+\varepsilon)$. By definition,

[TABLE]

Necessarily, after at most $\lceil 1/\varepsilon\rceil$ iterations, Algorithm 2 exits the loop on line 2.

∎

Proof of Theorem 1.

There are $\lfloor m\rfloor$ pattern sizes tried where $T_{\min}\cdot(1+\varepsilon)^{m}=T_{\max}$ in the main “while” loop (line 2), that is

[TABLE]

Furthermore, we have seen (Lemma 5) that there are a maximum of $\lceil 1/\varepsilon\rceil$ pattern sizes tried of the second loop (line 2).

For each pattern size tried, the cost is dominated by the complexity of Algorithm 3. Let us compute this complexity.

• •

The construction of $\tilde{\mathcal{A}}$ is done in $O(K\log K)$.

• •

In sum, each application can be inserted a maximum of $n_{\max}$ times in $\tilde{\mathcal{A}}$ (maximum number of instances in any pattern), that is the total of all insertions has a complexity of $O(K\log Kn_{\max})$.

We are now interested by the complexity of the different calls to Insert-In-Pattern.

First one can see that we only call Insert-First-Instance $K$ times, and in particular they correspond to the first $K$ calls of Insert-In-Pattern. Indeed, we always choose to insert a new instance of the application that has the largest current slowdown. The slowdown is infinite for all applications at the beginning, until their first instance is inserted (or they are removed from $\tilde{\mathcal{A}}$) when it becomes finite, meaning that the $K$ first insertions will be the first instance of all applications.

During the $k$-th call, for $1\leq k\leq K$, there will be $n=2(k-1)+2$ events (2 for each previously inserted instances and the two bounds on the pattern), meaning that the complexity of Insert-First-Instance will be $O(n\log{n})$ (because of the sorting of the bandwidths available by non-increasing order to choose the intervals to use). So overall, the $K$ first calls have a complexity of $O(K^{2}\log{K})$.

Furthermore, to understand the complexity of the remaining calls to Insert-In-Pattern we are going to look at the end result. In the end there is a maximum of $n_{\max}$ instance of each applications, that is a maximum of $2n_{\max}K$ events. For all application $\text{App}^{(k)}$, for all instance $\mathcal{I}^{(k)}_{i}$k, $1<i\leq n^{(k)}$, the only events considered in Insert-In-Pattern when scheduling $\mathcal{I}^{(k)}_{i}$k were the ones between the end of $\texttt{initW}^{(i)}_{k}+w^{(k)}$ and $\texttt{initW}^{(i)}_{k+1}$. Indeed, since the schedule has been able to schedule $\text{vol}_{\text{io}}^{(k)}$, Insert-In-Pattern will exit the while loop on line 1. Finally, one can see that the events considered for all instances of an application partition the pattern without overlapping. Furthermore, Insert-In-Pattern has a linear complexity in the number of events considered. Hence a total complexity by application of $O(n_{\max}K)$. Finally, we have $K$ applications, the overall time spent in Insert-In-Pattern for inserting new instances is $O(K^{2}n_{\max})$.

Hence, with the number of different pattern tried, we obtain a complexity of

[TABLE]

∎

Note that in practice, both $K^{\prime}$ and $K$ are small ($\approx 10$), and $\varepsilon$ is close to 0, hence making the complexity $O\left(\frac{n_{\max}}{\varepsilon}\right)$.

3.3 High-level implementation, proof of concept

We envision the implementation of this periodic scheduler to take place at two levels:

1. The job scheduler would know the applications profile (using solutions such as Omnisc’IO [12]). Using profiles it would be in charge of computing a periodic pattern every time an application enters or leaves the system.

2. Application-side I/O management strategies (such as [30, 22, 29]) then would be responsible to ensure the correct transfer of I/O at the right time by limiting the bandwidth used by nodes that transfer I/O. The start and end time for each I/O as well as the used bandwidth are described in input files.

4 Evaluation and model validation

Note that the data used for this section and the scripts to generate the figures are available at https://github.com/vlefevre/IO-scheduling-simu.

In this section, we (i) assess the efficiency of our algorithm by comparing it to a recent dynamic framework [14], and (ii) validate our model by comparing theoretical performance (as obtained by the simulations) to actual performance on a real system.

We perform the evaluation in three steps: first we simulate behavior of applications and input them into our model to estimate both Dilation and SysEfficiency of our algorithm (Section 4.4) and evaluate these cases on an actual machine to confirm the validity of our model. Finally, in Section 4.5 we confirm the intuitions introduced in Section 3 to determine the parameters used by PerSched.

4.1 Experimental Setup

The platform available for experimentation is Jupiter at Mellanox, Inc. To be able to verify our model, we use it to instantiate our platform model. Jupiter is a Dell PowerEdge R720xd/R720 32-node cluster using Intel Sandy Bridge CPUs. Each node has dual Intel Xeon 10-core CPUs running at 2.80 GHz, 25 MB of L3, 256 KB unified L2 and a separate L1 cache for data and instructions, each 32 KB in size. The system has a total of 64GB DDR3 RDIMMs running at 1.6 GHz per node. Jupiter uses Mellanox ConnectX-3 FDR 56Gb/s InfiniBand and Ethernet VPI adapters and Mellanox SwitchX SX6036 36-Port 56Gb/s FDR VPI InfiniBand switches.

We measured the different bandwidths of the machine and obtained $b=0.01$GB/s and $B=3$GB/s. Therefore, when 300 cores transfer at full speed (less than half of the 640 available cores), congestion occurs.

Implementation of scheduler on Jupiter

We simulate the existence of such a scheduler by computing beforehand the I/O pattern for each application and feeding it as input files. The experiments require a way to control the exact moment when all applications perform I/O, use the CPU or stay idle waiting to start their I/O. For this purpose, we modified the IOR benchmark [27] to read the input files that provide the start and end time for each I/O transfer as well as the bandwidth used. Our scheduler generates one such file for each application. Each IOR instance represents one application whose I/O pattern is described in one of the generated scheduling files. The IOR benchmark is split in different sets of processes running independently on different nodes, where each set represents a different application. One separate process acts as the scheduler and receives I/O requests for all groups in IOR. Since we are interested in modeling the I/O delays due to congestion or scheduler imposed delays, the modified IOR benchmarks do not use inter-processor communications.

We made experiments on our IOR benchmark and compared the results between periodic and online schedulers as well as with the performance of the original IOR benchmark without any extra scheduler.

4.2 Applications and scenarios

In the literature, there are many examples of periodic applications. Carns et al. [6] observed with Darshan the periodicity of four different applications (MADBench2 [7], Chombo I/O benchmark [8], S3D IO [25] and HOMME [24]). Furthermore, in our previous work [14] we were able to verify the periodicity of gyrokinetic toroidal code (GTC) [13], Enzo [5], HACC application [16] and CM1 [4].

Unfortunately, few documents give the actual values for $w^{(k)}$, $\text{vol}_{\text{io}}^{(k)}$ and $\beta^{(k)}$. Liu et al. [21] provide different periodic patterns of four scientific applications: PlasmaPhysics, Turbulence1, Astrophysics and Turbulence2. They were also the top four write-intensive jobs run on Intrepid in 2011. We chose the most I/O intensive patterns for all applications (as they are the most likely to create I/O congestion). We present these results in Table 1. Note that to scale those values to our system, we divided the number of processors $\beta^{(k)}$ by 64, hence increasing $w^{(k)}$ by 64. The I/O volume stays constant.

To compare our strategy, we tried all possible combinations of those applications such that the number of nodes used equals 640. That is a total of ten different scenarios that we report in Table 2.

4.3 Baseline and evaluation of existing degradation

We ran all scenarios on Jupiter without any additional scheduler. In all tested scenarios congestion occurred and decreased the visible bandwidth used by each applications as well as significantly increased the total execution time. We present in Table 3 the average I/O bandwidth slowdown due to congestion for the most representative scenarios together with the corresponding values for SysEfficiency. Depending on the IO transfers per computation ratio of each application as well as how the transfers of multiple applications overlap, the slowdown in the perceived bandwidth ranges between 25% to 65%.

Interestingly, set 1 presents the worst degradation. This scenario is running concurrently ten times the same application, which means that the I/O for all applications are executed almost at the same time (depending on the small differences in CPU execution time between nodes). This scenario could correspond to coordinated checkpoints for an application running on the entire system. The degradation in the perceived bandwidth can be as high as 65% which considerably increases the time to save a checkpoint. The use of I/O schedulers can decrease this cost, making the entire process more efficient.

4.4 Comparison to online algorithms

In this subsection, we present the results obtained by running PerSched and the online heuristics from our previous work [14]. Because in [14] we had different heuristics to optimize either Dilation or SysEfficiency, in this work, the Dilation and SysEfficiency presented are the best reached by any of those heuristics. This means that there are no online solution able to reach them both at the same time! We show that even in this scenario, our algorithm outperforms these heuristics for both optimization problems!

PerSched takes as input a list of applications, as well as the parameters, presented in Section 3, $K^{\prime}=\frac{T_{\max}}{T_{\min}}$, $\varepsilon$. All scenarios were tested with $K^{\prime}=10$ and $\varepsilon=0.01$.

Simulation results

We present in Table 4 all evaluation results. The results obtained by running Algorithm 2 are called PerSched. To go further in our evaluation, we also look for the best Dilation obtainable with our pattern (we do so by changing line 2 of PerSched). We call this result min Dilation in Table 4. This allows us to estimate how far the Dilation that we obtain is from what we can do. Furthermore, we can compute an upper bound to SysEfficiency by replacing $\tilde{\rho}^{(k)}$ by $\rho^{(k)}$ in Equation (1):

[TABLE]

The first noticeable result is that PerSched almost always outperfoms (when it does not, matches) both the Dilation and SysEfficiency attainable by the online scheduling algorithms! This is particularly impressive as these objectives are not obtained by the same online algorithms (hence conjointly), contrarily to the PerSched result.

While the gain is minimal (from 0 to 3%, except SysEfficiency increased by 7% for case 4) when little congestion occurs (cases 4 to 10), the gain is between 9% and 16% for Dilation and between 7% and 18% for SysEfficiency when congestion occurs (cases 1, 2, 3)!

The value of $\varepsilon$ has been chosen so that the computation stays short. It seems to be a good compromise as the results are good and the execution times vary from 4 ms (case 10) to 1.8s (case 5) using a Intel Core I7-6700Q. Note that the algorithm is easily parallelizable, as each iteration of the loop is independent. Thus it may be worth considering a smaller value of $\varepsilon$, but there will be no big improvement on the results.

Model validation through experimental evaluation

We used the modified IOR benchmark to reproduce the behavior of applications running on HPC systems and analyze the benefits of I/O schedulers. We made experiments on the 640 cores of the Jupiter system. Additionally to the results from both periodic and online heuristics, we present the performance of the system with no additional I/O scheduler.

Figure 5 shows the SysEfficiency (normalized using the upper bound in Table 4) and Dilation when using the periodic scheduler in comparison with the online scheduler. For the system efficiency the upper limit and the results when applications are running without any scheduler are also shown. As observed in the previous section, the periodic scheduler gives better or similar results to the best solutions that can be returned by the online ones, in some cases increasing the system performance by 18% and the dilation by 13%. When we compare to the current strategy on Jupiter, the SysEfficiency reach 48%! In addition, the periodic scheduler has the benefit of not requiring a global view of the execution of the applications at every moment of time (by opposition to the online scheduler).

Finally, a key information from those results is the precision of our model introduced in Section 2. The theoretical results (based on the model) are within 3% of the experimental results!

This observation is key in launching more thorough evaluation via extensive simulations and is critical in the experimentation of novel periodic scheduling strategies.

4.5 Discussion on finding the best pattern size

The core of our algorithm is a search of the best pattern size via an exponential growth of the pattern size until $T_{\max}$. As stated in Section 3, the intuition of the exponential growth is that the larger the pattern size, the less needed the precision for the pattern size as it might be easier to fit many instances of each application. On the contrary, we expect that for small pattern sizes finding the right one might be a precision job.

We verify this experimentally and plot on Figure 6 the SysEfficiency and Dilation found by our algorithm as a function of the pattern size $T$.

Finally, the last information to determine to tweak PerSched is the value of $T_{\max}$. Remember that we denote $K^{\prime}=T_{\max}/T_{\min}$.

To be able to get an estimate of the pattern size returned by PerSched, we provide in Table 5 (i) the maximum number of instances $n_{\text{inst}}$ of any application, and (ii) the ratio $n_{\max}=\frac{\max_{k}\left(w^{(k)}+\text{time}_{\text{io}}^{(k)}\right)}{\min_{k}\left(w^{(k)}+\text{time}_{\text{io}}^{(k)}\right)}$. Together along with the fact that the Dilation (Table 4) is always below 2 they give a rough idea of $K^{\prime}$ ($\approx\frac{n_{\text{inst}}}{n_{\max}}$). It is sometimes close to 1, meaning that a small value of $K^{\prime}$ can be sufficient, but choosing $K^{\prime}\approx 10$ is necessary in the general case.

We then want to verify the cost of under-estimating $T_{\max}$. For this evaluation all runs were done up to $K^{\prime}=100$ with $\varepsilon=0.01$. Denote $\textsc{Sys\-Effi\-ciency}(K^{\prime})$ (resp. $\textsc{Dilation}(K^{\prime})$) the maximum SysEfficiency (resp. corresponding Dilation) obtained when running PerSched with $K^{\prime}$. We plot their normalized version that is:

[TABLE]

on Figure 7.

The main noticeable information is that the convergence is very fast: when $K^{\prime}=3$, the average SysEfficiency is within $0.3\%$ of $\textsc{Sys\-Effi\-ciency}(100)$, but the corresponding average Dilation is $5\%$ higher than $\textsc{Dilation}(100)$. If we go to $K^{\prime}=10$ then we have a SysEfficiency of $0.1\%$ of $\textsc{Sys\-Effi\-ciency}(100)$ and a Dilation within $1\%$ of $\textsc{Dilation}(100)$! Hence validating that choosing $K^{\prime}=10$ is sufficient.

5 Related Work

Performance variability due to resource sharing can significantly detract from the suitability of a given architecture for a workload as well as from the overall performance realized by parallel workloads [28]. Over the last decade there have been studies to analyze the sources of performance degradation and several solutions have been proposed. In this section, we first detail some of the existing work that copes with I/O congestion and then we present some of the theoretical literature that is similar to our Periodic problem.

The storage I/O stack of current HPC systems has been increasingly identified as a performance bottleneck. Significant improvements in both hardware and software need to be addressed to overcome oncoming scalability challenges. The study in [18] argues for making data staging coordination driven by generic cross-layer mechanisms that enable global optimizations by enforcing local decisions at node granularity at individual stack layers.

While many other studies suggest that I/O congestion is one of the main problems for future scale platforms [3, 23], few papers focus on finding a solution at the platform level. Some paper consider application-side I/O management and transformation (using aggregate nodes, compression etc) [30, 22, 29]. We consider those work to be orthogonal to our work and able to work jointly. Recently, numerous works focus on using machine learning for auto tuning and performance studies [2, 20]. However these solution also work at the application level for IO-scheduling and do not have a global view of the I/O requirements of the system and they need to be supported by a platform level I/O management for better results.

Some paper consider the use of burst buffers to reduce I/O congestion by delaying accesses to the file storage, as they found that congestion occurs on a short period of time and the bandwidth to the storage system is often underutilized [21]. However, the computation power tends to increase faster than the I/O bandwidth, which may cause the bandwidth to be saturated more often and thus decreasing the efficiency of burst buffers. [19] presents a dynamic I/O scheduling at the application level using burst buffers to stage I/O and to allow computations to continue uninterrupted. They design different strategies to mitigate I/O interference, including partitioning the PFS, which reduces the effective bandwidth non-linearly. However, the strategies are basically designed for only 2 applications and their heuristics does not take into account the characteristics of the applications to better optimize the scheduling.

The study from [26] offers ways of isolating the performance experienced by applications of one operating system from variations in the I/O request stream characteristics of applications of other operating systems. While their solution cannot be applied to HPC systems, the study offers a way of controlling the coarse grain allocation of disk time to the different operating system instances as well as determining the fine-grain interleaving of requests from the corresponding operating systems to the storage system.

Closer to this work, online schedulers for HPC systems were developed such as our previous work [14], the study by Zhou et al [31], and a solution proposed by Dorier et al [11]. In [11], the authors investigate the interference of two applications and analyze the benefits of interrupting or delaying either one in order to avoid congestion. Unfortunately their approach cannot be used for more than two applications. Another main difference with our previous work is the light-weight approach of this study where the computation is only done once.

Our previous study [14] is more general by offering a range of options to schedule each I/O performed by an application. Similarly, the work from [31] also utilizes a global job scheduler to mitigate I/O congestion by monitoring and controlling jobs’ I/O operations on the fly. Unlike online solutions, this paper focuses on a decentralized approach where the scheduler is integrated into the job scheduler and computes ahead of time, thus overcoming the need to monitor the I/O traffic of each application at every moment of time.

As a scheduling problem, our problem is somewhat close to the cyclic scheduling problem (we refer to Hanen and Munier [17] for a survey), namely there are given a set of activities with time dependency between consecutive tasks stored in a DAG that should be executed on $p$ processors. The main difference is that in cyclic scheduling there is no consideration of a constant time between the end of the previous instance and the next instance.

6 Conclusion

Performance variation due to resource sharing in HPC systems is a reality and I/O congestion is currently one of the main causes of degradation. Current storage systems are unable to keep up with the amount of data handled by all applications running on an HPC system, either during their computation or when taking checkpoints. In this document we have presented a novel I/O scheduling technique that offers a decentralized solution for minimizing the congestion due to application interference. Our method takes advantage of the periodic nature of HPC applications by allowing the job scheduler to pre-define each application’s I/O behavior for their entire execution. Recent studies [12] have shown that HPC applications have predictable I/O patterns even when they are not completely periodic, thus we believe our solution is general enough to easily include the large majority of HPC applications.

We conducted simulations for different scenarios and made experiments to validate our results. Decentralized solutions are able to improve both total system efficiency and application dilation compared to dynamic state-of-the-art schedulers. Moreover, they do not require a constant daemon capable of monitoring the state of all applications, nor do they require a change in the current I/O stack. One particularly interesting result is for scenario 1 with 10 identical periodic behaviors (such as what can be observed with periodic checkpointing for fault-tolerance). In this case the periodic scheduler shows a 30% improvement in SysEfficiency. Thus, system wide applications taking global checkpoints could benefit from such a strategy.

Future work: we believe this work is the initialization of a new set of techniques to deal with the I/O requirements of HPC system. In particular, by showing the efficiency of the periodic technique on simple pattern, we expect to open a door to multiple extensions. We give here some examples that we will consider in the future. The next natural directions is to take more complicated periodic shapes for applications (an instance could be composed of sub-instances) as well as different point of entry inside the job scheduler (multiple IO nodes). This would be modifying the Insert-In-Pattern procedure and we expect that this should work well as well. Another future step would be to study how variability in the compute or I/O volumes impact a periodic schedule or the impact of non periodic applications. Finally we plan to model burst buffers and to show how to use them conjointly with periodic schedules.

Our method is used for minimizing the congestion caused by concurrent I/O accesses. However, the methodology and concepts are general and can be applied to any resource sharing problem. We will continue to investigate the causes for performance degradation in HPC applications and adapt our findings to each case.

Acknowledgement

Part of this work was done when Guillaume Aupy and Valentin Le Fèvre were at Vanderbilt University. The authors would like to thank Anne Benoit and Yves Robert for helpful discussions.