hpcs-17-subord

git clone https://git.igankevich.com/hpcs-17-subord.git
Log | Files | Refs

commit 2b0e9079abc5d283fac6274d7d4402a3ed68fa87
parent 2f8badc0cbe5e2469cccc82851bfb98f2a404272
Author: Ivan Gankevich <igankevich@ya.ru>
Date:   Sat, 25 Feb 2017 14:00:30 +0300

Tune figures.

Diffstat:
src/body.tex | 46+++++++++++++++++++++++++---------------------
1 file changed, 25 insertions(+), 21 deletions(-)

diff --git a/src/body.tex b/src/body.tex @@ -97,11 +97,11 @@ subordinates and so provides task atomization to archive fault tolerance. The main purpose of scheduler is to continue or restore execution while failures occur in daemons hierarchy. There are three types of such failures. -\begin{itemize} +\begin{enumerate} \item Failure of at most one node. - \item Failure of more than one node but less than total number of node. + \item Failure of more than one node but less than total number of nodes. \item Failure of all nodes (electricity outage). -\end{itemize} +\end{enumerate} By dividing kernels on principals and subordinate we create restore points. Each principal is, mainly, a control unit, with a goal. To archive it, principal make @@ -128,38 +128,42 @@ exists and available, finding process will stop, as current subordinate kernel will assume that the kernel found will take principal restoration process. \begin{figure} - \caption{First scenario of restoration after principle fails} - \includegraphics[scale=0.33]{img/sc1} + \centering + \includegraphics{img/sc1} + \caption{First scenario of restoration after principle fails.} \label{fig:sc1} \end{figure} \begin{figure} - \caption{Restoration after only one subordinate fails} - \includegraphics[scale=0.33]{img/sc12} + \centering + \includegraphics{img/sc12} + \caption{Restoration after only one subordinate fails.} \label{fig:sc12} \end{figure} In comparison with first scenario, the second one is more complicate yet -frequent. While on principal-to-subordinate layer scheduler act same ~\ref{fig:sc12}, then we -move to daemons layer one more variant added. In kernel hierarchy principal -kernels mostly a dual kernel. For a higher level kernels it seems like a -subordinate, for rest lower kernels it is a principal. Thus, we need to add to -our restoration scope only a state of principals principle. As a result, we add -to variants from first scenario situation,a one where principals principal also -is gone. Since scheduler through daemons knew all kernels state before it begin -a restoration process, first it will check state of principals principle. If -it's gone ~\ref{fig:sc12}, all subordinates will be started accordingly to hierarchy once again, -despite their states. +frequent. While on principal-to-subordinate layer scheduler act +same~\ref{fig:sc12}, then we move to daemons layer one more variant added. In +kernel hierarchy principal kernels mostly a dual kernel. For a higher level +kernels it seems like a subordinate, for rest lower kernels it is a principal. +Thus, we need to add to our restoration scope only a state of principals +principle. As a result, we add to variants from first scenario situation,a one +where principals principal also is gone. Since scheduler through daemons knew +all kernels state before it begin a restoration process, first it will check +state of principals principle. If it's gone~\ref{fig:sc12}, all subordinates +will be started accordingly to hierarchy once again, despite their states. \begin{figure} - \caption{Simultaneous fail of one of subordinates, which lies inside subordinates butch, and his principle} - \includegraphics[scale=0.33]{img/sc2} + \centering + \includegraphics{img/sc2} + \caption{Simultaneous failure of a subordinate and its principal.} \label{fig:sc2} \end{figure} \begin{figure} - \caption{The condition for restarting an execution subtree} - \includegraphics[scale=0.33]{img/sc3} + \centering + \includegraphics{img/sc3} + \caption{The condition for restarting an execution subtree.} \label{fig:sc3} \end{figure}