\newpage
%===========================================================================
%       x.13 > Caracter\'\i sticas de openMosix
%===========================================================================
\pagestyle{empty}
\begin{latexonly}
\ifpdf
 \begin{figure}[htbp]
%       \includegraphics[bb = -350 150 0 0, scale=1]{./TuXes/tux-peeping.jpg}
 \end{figure}
 \vspace{5in}
\else
 \begin{figure}
%       \includegraphics[-300,650][0,0]{./TuXes/tux-peeping}
 \end{figure}
\fi
\hfill\line(1,0){400}
\end{latexonly}
\topmargin 1in
\section{CARACTERISTICAS DE OPENMOSIX}
\begin{latexonly}
\line(1,0){400}
\newpage
\end{latexonly}
\topmargin 0in
\pagestyle{fancy}
%========================cita===============================================
\begin{latexonly}
\hspace{1in}\textcolor{blue_omosix}{{\em We all know Linux is great... }}

\hspace{1in}\textcolor{blue_omosix}{{\em it does infinite loops in 5 seconds.}}

\hspace{4in}\textcolor{blue_omosix}{{\em Linus Torvalds}}
\vspace{.5in}
\end{latexonly}
%============================================================================
\subsection{Pros de openMosix}
\begin{itemize}
        \item No se requieren paquetes extra
        \item No son necesarias modificaciones en el c\'odigo
\end{itemize}
%------------------------------------------------------------------------------------
\subsection{Contras de openMosix}
\begin{itemize}
        \item Es dependiente del kernel
        \item No migra todos los procesos siempre, tiene limitaciones de funcionamiento
        \item Problemas con memoria compartida
\end{itemize}

Adem\'as los procesos con m\'ultiples {\em threads} no ganan demasiada eficiencia

Tampoco se obtendr\'a mucha mejora cuando se ejecute un solo proceso, como por ejemplo el navegador.
%---------------------------------------------------------------------------------------------------------
\subsection{Subsistemas de openMosix}
\hspace{0.5in}Actualmente podemos dividir los parches de openMosix dentro del kernel en cuatro grandes subsistemas, ve\'amoslos.
%-------
\subsubsection*{Mosix File System (MFS)}
\hspace{0.5in}El primer y mayor subsistema (en cuanto a l\'\i neas de c\'odigo) es MFS que te permite un acceso a sistemas de ficheros (FS) remotos (i.e. de cualquier otro nodo) si est\'a localmente montado. 

El sistema de ficheros de tu nodo y de los dem\'as podr\'an ser montados en el directorio {\em /mfs} y de esta forma se podr\'a, por ejemplo, acceder
al directorio {\em /home} del nodo 3 dentro del directorio {\em /mfs/3/home} desde cualquier nodo del cluster.
%-------
\subsubsection*{Migraci\'on de procesos}
\hspace{0.5in}Con openMosix se puede lanzar un proceso en una computadora y ver si se ejecuta en otra, en el seno del cluster.

Cada proceso tiene su \'unico nodo ra\'\i z (UHN, {\em unique home node}) que se corresponde con el que lo ha generado.

El concepto de migraci\'on significa que un proceso se divide en dos partes: la parte del usuario y la del sistema.

La parte, o \'area, de usuario ser\'a movida al nodo remoto mientras el \'area de sistema espera en el ra\'\i z.

openMosix se encargar\'a de establecer la comunicaci\'on entre estos 2 procesos.
%------
\subsubsection*{Direct File System Access (DFSA)}
\hspace{0.5in}openMosix proporciona MFS con la opci\'on DFSA que permite acceso a todos los sistemas de ficheros, tanto locales como remotos. Para m\'as informaci\'on dir\'\i gase a la secci\'on de {\em Sistema de ficheros} de las FAQs (preguntas m\'as frecuentes) del presente documento.
%------
\subsubsection*{Memory ushering}
\hspace{0.5in}Este subsistema se encarga de migrar las tareas que superan la memoria disponible en el nodo en el que se ejecutan. Las tareas que superan dicho l\'\i mite se migran forzosamente a un nodo destino de entre los nodos del cluster que tengan suficiente memoria como para ejecutar el proceso sin necesidad de hacer {\em swap} a disco, ahorrando as\'\i\ la gran p\'erdida de rendimiento que esto supone. El subsistema de {\em memory ushering} es un subsistema independiente del subsistema de equilibrado de carga, y por ello se le considera por separado.
%---------------------------------------------------------------------------------------------------------
\subsection{El algoritmo de migraci\'on}
\hspace{0.5in}De entre las propiedades compartidas entre Mosix y
openMosix podemos destacar el mecanismo de migraci\'on, en el que
puede migrar-se cualquiera proceso a cualquier nodo del cluster de
forma completamente transparente al proceso migrado. La migraci\'on
tambi\'en puede ser autom\'atica: el algoritmo que lo implementa tiene
una complejidad computacional del orden de O(n), siendo {\em n} el
n\'umero de nodos del cluster.

Para implementarlo openMosix utiliza el modelo {\em
fork-and-forget}\footnote{hace fererencia a que el sistema cuando reconoce un subproceso se encarga de ejecutarlo en otro nodo, en paralelo, sin ningun efecto ni notificaci\'on al propietario del mismo}, desarrollado en un principio dentro de Mosix para m\'aquinas PDP11/45 empleadas en las fuerzas a\'ereas norteamericanas. La idea de este modelo es que la distribuci\'on de tareas en el cluster la determina openMosix de forma din\'amica, conforme se van creando tareas. Cuando un nodo est\'a demasiado cargado, y las tareas que se est\'an ejecutando puedan migrar a cualquier otro nodo del cluster. As\'\i\  desde que se ejecuta una tarea hasta que \'esta muere, podr\'a migrar de un nodo a otro, sin que el proceso sufra mayores cambios.

Podr\'\i amos pensar que el comportamiento de un clsuter openMosix es como una m\'aquina NUMA, aunque estos clusters son mucho m\'as baratos. 
%---------------------------------------------------------------------------------------------------------
\subsubsection*{El nodo ra\'iz}
\hspace{0.5in}Cada proceso ejecutado en el cluster tiene un \'unico nodo ra\'\i z, como se ha visto. El nodo ra\'\i z es el nodo en el cual se lanza originalmente el proceso y donde \'este empieza a ejecutarse.

Desde el punto de vista del espacio de procesos de las m\'aquinas del cluster, cada proceso (con su correspondiente PID) parece ejecutarse en su nodo ra\'\i z. El nodo de ejecuci\'on puede ser el nodo ra\'\i z u otro diferente, hecho que da lugar a que el proceso no use un PID del nodo de ejecuci\'on, sino que el proceso migrado se ejecutar\'a en \'este como una hebra del kernel. La interacci\'on con un proceso, por ejemplo enviarle se\~{n}ales desde cualquier otro proceso migrado, se puede realizar exclusivamente desde el nodo ra\'\i z.

El usuario que ejecuta un proceso en el cluster ha accedido al cluster desde el nodo ra\'\i z del proceso (puesto que ha logado en \'el). El propietario del proceso en cuesti\'on tendr\'a control en todo momento del mismo como si se ejecutara localmente.

Por otra parte la migraci\'on y el retorno al nodo ra\'\i z de un
proceso se puede realizar tanto desde el nodo ra\'\i z como desde el
nodo d\'onde se ejecuta el proceso. Esta tarea la puede llevar a
t\'ermino el administrador de cualquiera de los dos sistemas. 
%---------------------------------------------------------------------------------------------------------
\subsubsection*{El mecanismo de migrado}
\hspace{0.5in}{\bf La migraci\'on de procesos en openMosix es completamente transparente}. Esto significa que al proceso migrado no se le avisa de que ya no se ejecuta en su nodo de origen. 
Es m\'as, este proceso migrado seguir\'a ejecut\'andose como si siguiera en el nodo origen: si escribiera o leyera al disco, lo har\'\i a en el nodo origen, hecho que supone leer o grabar remotamente en este nodo. 
%---------------------------------------------------------------------------------------------------------
\subsubsection*{?`Cu\'ando podr\'a migrar un proceso?}
\hspace{0.5in}Desgraciadamente, no todos los procesos pueden migrar en cualquiera circunstancia. El mecanismo de migraci\'on de procesos puede operar sobre cualquier tarea de un nodo sobre el que se cumplen algunas condiciones predeterminadas. \'Estas son: 
\begin{itemize}
        \item el proceso no puede ejecutarse en modo de emulaci\'on VM86 
        \item el proceso no puede ejecutar instrucciones en ensamblador propias de la m\'aquina donde se lanza y que no tiene la m\'aquina destino (en un cluster heterog\'eneo)
        \item el proceso no puede mapear memoria de un dispositivo a la RAM, ni acceder directamente a los registros de un dispositivo
        \item el proceso no puede usar segmentos de memoria compartida
\end{itemize}

Cumpliendo todas estas condiciones el proceso puede migrar y ejecutarse migrado. No obstante, como podemos sospechar, openMosix no adivina nada. openMosix no sabe a priori si alguno de los procesos que pueden migrar tendr\'an algunos de estos problemas.

Por esto en un principio openMosix migra todos los procesos que puedan hacerlo si por el momento cumplen todas las condiciones, y en caso de que alg\'un proceso deje de cumplirlas, lo devuelve de nuevo a su nodo ra\'\i z para que se ejecute en \'el mientras no pueda migrar de nuevo.

Todo esto significa que mientras el proceso est\'e en modo de emulaci\'on VM86, mapee memoria de un dispositivo RAM, acceda a un registro o tenga reservado/bloqueado un puntero a un segmento de memoria compartida, el proceso se ejecutar\'a en el nodo ra\'\i z, y cuando acabe la condici\'on que lo bloquea volver\'a a migrar.

Con el uso de instrucciones asociadas a procesadores no compatibles entre ellos, openMosix tiene un comportamiento diferente: solo permitir\'a migrar a los procesadores que tengan la misma arquitectura. 
%---------------------------------------------------------------------------------------------------------
\subsubsection*{La comunicaci\'on entre las dos \'areas}
\hspace{0.5in}Un aspecto importante en el que podemos tener inter\'es es en c\'omo se realiza la comunicaci\'on entre el \'area de usuario y el \'area de kernel.

En alg\'un momento, el proceso migrado puede necesitar hacer alguna llamada al sistema. Esta llamada se captura y se eval\'ua 

\begin{itemize}
        \item si puede ser ejecutada al nodo al que la tarea ha migrado, o
        \item si necesita ser lanzada en el nodo ra\'\i z del proceso migrado
\end{itemize}

Si la llamada puede ser lanzada al nodo d\'onde la tarea migrada se ejecuta, los accesos al kernel se hacen de forma local, es decir, que se atiende en el nodo d\'onde la tarea se ejecuta sin ninguna carga adicional a la red.

Por desgracia, las llamadas m\'as comunes son las que se han de ejecutar forzosamente al nodo ra\'\i z, puesto que {\em hablan} con el hardware. Es el caso, por ejemplo, de una lectura o una escritura a disco. En este caso el subsistema de openMosix del nodo d\'onde se ejecuta la tarea contacta con el subsistema de openMosix del nodo ra\'\i z. Para enviarle la petici\'on, as\'\i\  como todos los par\'ametros y los datos del nodo ra\'\i z que necesitar\'a procesar.

El nodo ra\'\i z procesar\'a la llamada y enviar\'a de vuelta al nodo d\'onde se est\'a ejecutando realmente el proceso migrado:

\begin{itemize}
        \item el valor del \'exito/fracaso de la llamada 
        \item aquello que necesite saber para actualizar sus segmentos de datos, de pila y de {\em heap}
        \item el estado en el que estar\'\i a si se estuviera ejecutando el proceso al nodo ra\'\i z
\end{itemize}


Esta comunicaci\'on tambi\'en puede ser generada por el nodo ra\'\i z. Es el caso, por ejemplo, del env\'\i o de una se\~{n}al. El subsistema de openMosix del nodo ra\'\i z contacta con el subsistema de openMosix del nodo d\'onde el proceso migrado se ejecuta, y el avisa que ha ocurrido un evento as\'\i ncono. El subsistema de openMosix del nodo d\'onde el proceso migrado se ejecuta parar\'a el proceso migrado y el nodo ra\'\i z podr\'a empezar a atender el c\'odigo del \'area del kernel que corresponder\'\i a a la seņal as\'\i ncrona.

\hspace{0.5in}Finalmente, una vez realizada toda el operativa necesaria de la \'area del kernel, el subsistema de openMosix del nodo ra\'\i z del proceso env\'\i a al nodo donde est\'a ejecut\'andose realmente el proceso migrado el aviso detallado de la llamada, y todo aquello que el proceso necesita saber (anteriormente enumerado) cuando recibi\'o la se\~{n}al, y el proceso migrado finalmente recuperar\'a el control.

Por todo esto el proceso migrado es como s\'\i\  estuviera al nodo ra\'\i z y hubiera recibido la se\~{n}al de \'este. Tenemos un escenario muy simple donde el proceso se suspende esperando un recurso. Recordemos que la suspensi\'on esperando un recurso se produce \'unicamente en \'area de kernel. Cuando se pide una p\'agina de disco o se espera un paquete de red se resuelto como en el primero caso comentado, es decir, como un llamada al kernel.

Este mecanismo de comunicaci\'on entre \'areas es el que nos asegura que

\begin{itemize}
        \item la migraci\'on sea completamente transparente tanto para el proceso que migra como para los procesos que cohabiten con el nodo ra\'\i z
        \item que el proceso no necesite ser reescrito para poder migrar, ni sea necesario conocer la topologia del cluster para escribir una aplicaci\'on paralela
\end{itemize}

No obstante, en el caso de llamadas al kernel que tengan que ser enviadas forzosamente al nodo ra\'\i z, tendremos una sobrecarga adicional a la red debida a la transmisi\'on constante de las llamadas al kernel y la recepci\'on de sus valores de vuelta.

Destacamos especialmente esta sobrecarga en el acceso a sockets y el acceso a disco duro, que son las dos operaciones m\'as importantes que se habr\'an de ejecutar en el nodo ra\'\i z y suponen una sobrecarga al proceso de comunicaci\'on entre la \'area de usuario migrada y la \'area de kernel del proceso migrado.
