X-Git-Url: https://bilbo.iut-bm.univ-fcomte.fr/and/gitweb/loba-papers.git/blobdiff_plain/69768dd70773e43e60a13d06dad73a65c00dfb85..bcf6cef9fa1df52f632849a68fc08e41f6163bb1:/supercomp11/supercomp11.tex diff --git a/supercomp11/supercomp11.tex b/supercomp11/supercomp11.tex index 249b676..81ee704 100644 --- a/supercomp11/supercomp11.tex +++ b/supercomp11/supercomp11.tex @@ -2,9 +2,12 @@ \usepackage[utf8]{inputenc} \usepackage[T1]{fontenc} \usepackage{mathptmx} +\usepackage{amsmath} \usepackage{courier} \usepackage{graphicx} +\newcommand{\abs}[1]{\lvert#1\rvert} % \abs{x} -> |x| + \begin{document} \title{Best effort strategy and virtual load @@ -39,14 +42,14 @@ algorithm~\cite[section~7.4]{bertsekas+tsitsiklis.1997.parallel} is certainly the most well known algorithm for which the convergence proof is given. From a practical point of view, when a node wants to balance a part of its load to some of its neighbors, the strategy is not described. In this -paper, we propose a strategy called \texttt{best effort} which tries to balance +paper, we propose a strategy called \emph{best effort} which tries to balance the load of a node to all its less loaded neighbors while ensuring that all the nodes concerned by the load balancing phase have the same amount of load. Moreover, asynchronous iterative algorithms in which an asynchronous load balancing algorithm is implemented most of the time can dissociate messages concerning load transfers and message concerning load information. In order to increase the converge of a load balancing algorithm, we propose a simple -heuristic called \texttt{virtual load} which allows a node that receives an load +heuristic called \emph{virtual load} which allows a node that receives an load information message to integrate the load that it will receive later in its load (virtually) and consequently sends a (real) part of its load to some of its neighbors. In order to validate our approaches, we have defined a simulator @@ -70,17 +73,19 @@ where computer nodes are considered homogeneous and with homogeneous load with no external load. In this context, Bertsekas and Tsitsiklis have proposed an algorithm which is definitively a reference for many works. In their work, they proved that under classical hypotheses of asynchronous iterative algorithms and -a special constraint avoiding \texttt{ping-pong} effect, an asynchronous +a special constraint avoiding \emph{ping-pong} effect, an asynchronous iterative algorithm converge to the uniform load distribution. This work has -been extended by many authors. For example, -DASUD~\cite{cortes+ripoll+cedo+al.2002.asynchronous} propose a version working -with integer load. {\bf Rajouter des choses ici}. +been extended by many authors. For example, Cortés et al., with +DASUD~\cite{cortes+ripoll+cedo+al.2002.asynchronous}, propose a +version working with integer load. This work was later generalized by +the same authors in \cite{cedo+cortes+ripoll+al.2007.convergence}. +{\bf Rajouter des choses ici}. Although the Bertsekas and Tsitsiklis' algorithm describes the condition to ensure the convergence, there is no indication or strategy to really implement the load distribution. In other word, a node can send a part of its load to one or many of its neighbors while all the convergence conditions are -followed. Consequently, we propose a new strategy called \texttt{best effort} +followed. Consequently, we propose a new strategy called \emph{best effort} that tries to balance the load of a node to all its less loaded neighbors while ensuring that all the nodes concerned by the load balancing phase have the same amount of load. Moreover, when real asynchronous applications are considered, @@ -94,17 +99,17 @@ message at each neighbor at each iteration. Latter messages contains data that migrates from one node to another one. Depending on the application, it may have sense or not that nodes try to balance a part of their load at each computing iteration. But the time to transfer a load message from a node to another one is -often much nore longer that to time to transfer a load information message. So, +often much more longer that to time to transfer a load information message. So, when a node receives the information that later it will receive a data message, it can take this information into account and it can consider that its new load is larger. Consequently, it can send a part of it real load to some of its -neighbors if required. We call this trick the \texttt{virtual load} mecanism. +neighbors if required. We call this trick the \emph{virtual load} mechanism. So, in this work, we propose a new strategy for improving the distribution of the load and a simple but efficient trick that also improves the load -balacing. Moreover, we have conducted many simulations with simgrid in order to +balancing. Moreover, we have conducted many simulations with SimGrid in order to validate our improvements are really efficient. Our simulations consider that in order to send a message, a latency delays the sending and according to the network performance and the message size, the time of the reception of the @@ -114,7 +119,7 @@ In the following of this paper, Section~\ref{BT algo} describes the Bertsekas and Tsitsiklis' asynchronous load balancing algorithm. Moreover, we present a possible problem in the convergence conditions. Section~\ref{Best-effort} presents the best effort strategy which provides an efficient way to reduce the -execution times. In Section~\ref{Virtual load}, the virtual load mecanism is +execution times. In Section~\ref{Virtual load}, the virtual load mechanism is proposed. Simulations allowed to show that both our approaches are valid using a quite realistic model detailed in Section~\ref{Simulations}. Finally we give a conclusion and some perspectives to this work. @@ -126,11 +131,11 @@ conclusion and some perspectives to this work. \label{BT algo} In order prove the convergence of asynchronous iterative load balancing -Bertesekas and Tsitsiklis proposed a model +Bertsekas and Tsitsiklis proposed a model in~\cite{bertsekas+tsitsiklis.1997.parallel}. Here we recall some notations. Consider that $N={1,...,n}$ processors are connected through a network. Communication links are represented by a connected undirected graph $G=(N,V)$ -where $V$ is the set of links connecting differents processors. In this work, we +where $V$ is the set of links connecting different processors. In this work, we consider that processors are homogeneous for sake of simplicity. It is quite easy to tackle the heterogeneous case~\cite{ElsMonPre02}. Load of processor $i$ at time $t$ is represented by $x_i(t)\geq 0$. Let $V(i)$ be the set of @@ -141,7 +146,7 @@ consider that the load is described by a continuous variable. When a processor send a part of its load to one or some of its neighbors, the transfer takes time to be completed. Let $s_{ij}(t)$ be the amount of load that -processor $i$ has transfered to processor $j$ at time $t$ and let $r_{ij}(t)$ be the +processor $i$ has transferred to processor $j$ at time $t$ and let $r_{ij}(t)$ be the amount of load received by processor $j$ from processor $i$ at time $t$. Then the amount of load of processor $i$ at time $t+1$ is given by: \begin{equation} @@ -151,18 +156,18 @@ x_i(t+1)=x_i(t)-\sum_{j\in V(i)} s_{ij}(t) + \sum_{j\in V(i)} r_{ji}(t) Some conditions are required to ensure the convergence. One of them can be -called the \texttt{ping-pong} condition which specifies that: +called the \emph{ping-pong} condition which specifies that: \begin{equation} x_i(t)-\sum _{k\in V(i)} s_{ik}(t) \geq x_j^i(t)+s_{ij}(t) \end{equation} for any processor $i$ and any $j \in V(i)$ such that $x_i(t)>x_j^i(t)$. This -condition aims at avoiding a processor to send a part of its load and beeing +condition aims at avoiding a processor to send a part of its load and being less loaded after that. Nevertheless, we think that this condition may lead to deadlocks in some cases. For example, if we consider only three processors and that processor $1$ is linked to processor $2$ which is also linked to processor $3$ (i.e. a simple -chain wich 3 processors). Now consider we have the following values at time $t$: +chain which 3 processors). Now consider we have the following values at time $t$: \begin{eqnarray*} x_1(t)=10 \\ x_2(t)=100 \\ @@ -172,7 +177,7 @@ x_3(t)=99.99\\ In this case, processor $2$ can either sends load to processor $1$ or processor $3$. If it sends load to processor $1$ it will not satisfy condition (\ref{eq:ping-pong}) because after the sending it will be less loaded that -$x_3^2(t)$. So we consider that the \texttt{ping-pong} condition is probably to +$x_3^2(t)$. So we consider that the \emph{ping-pong} condition is probably to strong. Currently, we did not try to make another convergence proof without this condition or with a weaker condition. @@ -180,16 +185,61 @@ condition or with a weaker condition. \section{Best effort strategy} \label{Best-effort} -\textbf{À traduire} Ordonne les voisins du moins chargé au plus chargé. -Trouve ensuite, en les prenant dans ce ordre, le nombre maximal de -voisins tels que tous ont une charge inférieure à la moyenne des -charges des voisins sélectionnés, et de soi-même. - -Les transferts de charge sont ensuite fait en visant cette moyenne pour -tous les voisins sélectionnés. On envoie une quantité de charge égale -à (moyenne - charge\_du\_voisin). - -~\\\textbf{Question} faut-il décrire les stratégies makhoul et simple ? +In this section we describe a new load-balancing strategy that we call +\emph{best effort}. The general idea behind this strategy is that each +processor, that detects it has more load than some of its neighbors, +sends some load to the most of its less loaded neighbors, doing its +best to reach the equilibrium between those neighbors and himself. + +More precisely, when a processor $i$ is in its load-balancing phase, +he proceeds as following. +\begin{enumerate} +\item First, the neighbors are sorted in non-decreasing order of their + known loads $x^i_j(t)$. + +\item Then, this sorted list is traversed in order to find its largest + prefix such as the load of each selected neighbor is lesser than: + \begin{itemize} + \item the processor's own load, and + \item the mean of the loads of the selected neighbors and of the + processor's load. + \end{itemize} + Let's call $S_i(t)$ the set of the selected neighbors, and + $\bar{x}(t)$ the mean of the loads of the selected neighbors and of + the processor load: + \begin{equation*} + \bar{x}(t) = \frac{1}{\abs{S_i(t)} + 1} + \left( x_i(t) + \sum_{j\in S_i(t)} x^i_j(t) \right) + \end{equation*} + The following properties hold: + \begin{equation*} + \begin{cases} + S_i(t) \subset V(i) \\ + x^i_j(t) < x_i(t) & \forall j \in S_i(t) \\ + x^i_j(t) < \bar{x} & \forall j \in S_i(t) \\ + x^i_j(t) \leq x^i_k(t) & \forall j \in S_i(t), \forall k \in V(i) \setminus S_i(t) \\ + \bar{x} \leq x_i(t) + \end{cases} + \end{equation*} + +\item Once this selection is completed, processor $i$ sends to each of + the selected neighbor $j\in S_i(t)$ an amount of load $s_{ij}(t) = + \bar{x} - x^i_j(t)$. + + From the above equations, and notably from the definition of + $\bar{x}$, it can easily be verified that: + \begin{equation*} + \begin{cases} + x_i(t) - \sum_{j\in S_i(t)} s_{ij}(t) = \bar{x} \\ + x^i_j(t) + s_{ij}(t) = \bar{x} & \forall j \in S_i(t) + \end{cases} + \end{equation*} +\end{enumerate} + +\section{Other strategies} +\label{Other} + +\textbf{Question} faut-il décrire les stratégies makhoul et simple ? \paragraph{simple} Tentative de respecter simplement les conditions de Bertsekas. Parmi les voisins moins chargés que soi, on sélectionne : @@ -223,69 +273,69 @@ C'est l'algorithme~2 dans~\cite{bahi+giersch+makhoul.2008.scalable}. In order to test and validate our approaches, we wrote a simulator using the SimGrid -framework~\cite{casanova+legrand+quinson.2008.simgrid}. The process -model is detailed in the next section (\ref{Sim model}), then the -results of the simulations are presented in section~\ref{Results}. +framework~\cite{casanova+legrand+quinson.2008.simgrid}. This +simulator, which consists of about 2,700 lines of C++, allows to run +the different load-balancing strategies under various parameters, such +as the initial distribution of load, the interconnection topology, the +characteristics of the running platform, etc. Then several metrics +are issued that permit to compare the strategies. + +The simulation model is detailed in the next section (\ref{Sim + model}), then the results of the simulations are presented in +section~\ref{Results}. \subsection{Simulation model} \label{Sim model} -\begin{verbatim} -Communications -============== - -There are two receiving channels per host: control for information -messages, and data for load transfers. - -Process model -============= - -Each process is made of 3 threads: a receiver thread, a computing -thread, and a load-balancer thread. - -* Receiver thread - --------------- - - Loop - | wait for a message to come, either on data channel, or on ctrl channel - | push received message in a buffer of received messages - | -> ctrl messages on the one side - | -> data messages on the other side - +- - - The loop terminates when a "finalize" message is received on each - channel. - -* Computing thread - ---------------- - - Loop - | if we received some real load, get it (data messages) - | if there is some real load to send, send it - | if we own some load, simulate some computing on it - | sleep a bit if we are looping too fast - +- - send CLOSE on data for all neighbors - wait for CLOSE on data from all neighbors - - The loop terminates when process::still_running() returns false. - (read the source for full details...) - -* Load-balancing thread - --------------------- - - Loop - | call load-balancing algorithm - | send ctrl messages - | sleep (min_lb_iter_duration) - | receive ctrl messages - +- - send CLOSE on ctrl for all neighbors - wait for CLOSE on ctrl from all neighbors +In the simulation model the processors exchange messages which are of +two kinds. First, there are \emph{control messages} which only carry +information that is exchanged between the processors, such as the +current load, or the virtual load transfers if this option is +selected. These messages are rather small, and their size is +constant. Then, there are \emph{data messages} that carry the real +load transferred between the processors. The size of a data message +is a function of the amount of load that it carries, and it can be +pretty large. In order to receive the messages, each processor has +two receiving channels, one for each kind of messages. Finally, when +a message is sent or received, this is done by using the non-blocking +primitives of SimGrid\footnote{That are \texttt{MSG\_task\_isend()}, + and \texttt{MSG\_task\_irecv()}.}. + +During the simulation, each processor concurrently runs three threads: +a \emph{receiving thread}, a \emph{computing thread}, and a +\emph{load-balancing thread}, which we will briefly describe now. + +\paragraph{Receiving thread} The receiving thread is in charge of +waiting for messages to come, either on the control channel, or on the +data channel. When a message is received, it is pushed in a buffer of +received message, to be later consumed by one of the other threads. +There are two such buffers, one for the control messages, and one for +the data messages. The buffers are implemented with a lock-free FIFO +\cite{sutter.2008.writing} to avoid contention between the threads. + +\paragraph{Computing thread} The computing thread is in charge of the +real load management. It iteratively runs the following operations: +\begin{itemize} +\item if some load was received from the neighbors, get it; +\item if there is some load to send to the neighbors, send it; +\item run some computation, whose duration is function of the current + load of the processor. +\end{itemize} +Practically, after the computation, the computing thread waits for a +small amount of time if the iterations are looping too fast (for +example, when the current load is zero). - The loop terminates when process::still_running() returns false. - (read the source for full details...) -\end{verbatim} +\paragraph{Load-balancing thread} The load-balancing thread is in +charge of running the load-balancing algorithm, and exchange the +control messages. It iteratively runs the following operations: +\begin{itemize} +\item get the control messages that were received from the neighbors; +\item run the load-balancing algorithm; +\item send control messages to the neighbors, to inform them of the + processor's current load, and possibly of virtual load transfers; +\item wait a minimum (configurable) amount of time, to avoid to + iterate too fast. +\end{itemize} \subsection{Validation of our approaches} \label{Results} @@ -332,5 +382,6 @@ Taille : 10 100 très gros %%% ispell-local-dictionary: "american" %%% End: -% LocalWords: Raphaël Couturier Arnaud Giersch Abderrahmane Sider -% LocalWords: Bertsekas Tsitsiklis SimGrid DASUD +% LocalWords: Raphaël Couturier Arnaud Giersch Abderrahmane Sider Franche ij +% LocalWords: Bertsekas Tsitsiklis SimGrid DASUD Comté Béjaïa asynchronism ji +% LocalWords: ik isend irecv