docHerramientas para la Gestión de la Localidad en Microkernels para
download 
Demanda Transcripción
Herramientas para la Gestión de la Localidad en Microkernels para
Herramientas para la Gestión de la Localidad en Microkernels para Memoria Compartida Marisa Gil, Xavier Martorell, Yolanda Becerra, Ernest Artiaga, Albert Serra, Nacho Navarro Departament d'Arquitectura de Computadors Universitat Politècnica de Catalunya (UPC) Gran Capità s/n, Campus Nord, D6, 08071, Barcelona, Spain [email protected] Abstract: Muchas aplicaciones paralelas se programan hoy en día utilizando paquetes de threads. El grado de paralelismo que puede explotar eficientemente una aplicación depende de la sobrecarga de utilizar threads. Hoy, que se trabaja sobre microkernels y librerías de threads de usuario, el coste de creación, destrucción y cambio de contexto está muy optimizado. Pero hay un coste que no se ha considerado suficientemente hasta ahora: el coste de traer los datos y el código a las memorias próximas al procesador y memoria cache durante la ejecución de un thread, y más aún a la hora de planificar la elección del siguiente thread. En este trabajo1 presentamos el diseño de un entorno cuya realización permite la planificación de flujos sobre un microkernel como Mach 3.0 tomando en consideración el particionado de los procesadores y la gestión de la memoria a nivel de kernel, de librerías y de servidores. 1. Introducción Muchas aplicaciones paralelas se programan hoy en día utilizando paquetes de threads. La poca sobrecarga que introduce la gestión de threads a nivel usuario mueve a los programadores a explotar el paralelismo natural de las aplicaciones. Pero hay que considerar también la gestión de los threads de kernel (procesadores virtuales) que soportan a los de usuario y su planificación sobre los procesadores físicos. El grado de paralelismo que puede explotar eficientemente una aplicación depende de la sobrecarga de utilizar threads. Hoy, que se trabaja sobre microkernels y librerías de threads de usuario, el coste de creación, destrucción y cambio de contexto está muy optimizado. La planificación de procesadores empieza a aparecer explícita en algunos sistemas y se basa en la planificación espacial, que permite a una aplicación disfrutar de una partición de la máquina y decidir, dentro de su grupo de procesadores, las políticas de planificación de flujos más adecuadas. En esta línea, en un trabajo anterior [GIL94a], hemos desarrollado “scheduler-activations” en el kernel de Mach [ACCE86], completado con nuevas políticas la librería CThreads [COOP88] y dotado al entorno de un servidor de procesadores. Pero, desafortunadamente, la sobrecarga no se limita al coste de la planificación flujos-procesadores, sino que hay otro coste que no se ha considerado suficientemente hasta ahora: el de traer los datos y el código a las memorias próximas al procesador y memoria cache durante la ejecución de un thread, y más aún a la hora de planificar la elección del siguiente thread. Este coste puede ser substancial tanto en copias entre módulos de memoria, como en fallos en la cache de un multiprocesador con coherencia de caches. Más aún hoy que la diferencia de velocidad entre los procesadores y la memoria se va agrandando. Necesitamos un entorno que facilite la reducción de este coste ejecutando los threads allí donde se encuentre la memoria a la que van a acceder. Para ello necesitamos controlar la asignación de memoria y sus políticas de gestión de forma que todos los niveles de gestión cooperen para que la aplicación tenga cargada en la memoria física más conveniente los datos y códigos de los threads que correrán en el procesador asociado. Las políticas actuales que siguen estas ideas de afinidad se basan en técnicas de “footprint” [BLAC90][GUPT91] y en las propuestas de “memory-conscious scheduling” [MARK92a]. Pero nos encontramos que los microkernels actuales, muy eficientes en la gestión de las abstracciones que ellos ofrecen, como los threads de kernel que aprovechan los multiprocesadores, dejan la gestión de 1. Este trabajo ha sido subvencionado por la Comisión Interministerial de Ciencia y Tecnología (CICYT), bajo el contrato TIC94-0439 “Cooperación entre el microkernel y las aplicaciones para explotar el paralelismo en sistemas multiprocesadores”. la creación de trabajos, la entrada/salida, los sistemas de ficheros y la paginación en manos de servidores externos que provienen del entorno UNIX y que secuencializan los servicios al no estar ellos convenientemente paralelizados. Necesitamos acompañar la ejecución de las aplicaciones paralelas con mecanismos y políticas adecuados dentro y fuera del kernel. En nuestro trabajo, partimos del concepto de particionado de los recursos y de mecanismos dentro del kernel y políticas en servidores para: • Ofrecer un entorno completo de ejecución, compuesto de librerías y servidores, que permita la ejecución de aplicaciones paralelas directamente sobre el microkernel, evitando la dependencia y sobrecarga actuales debida a la emulación de sistema redireccionando los servicios hacia el servidor UNIX. • Gestionar la asignación de procesadores (processor sets) desde un punto de vista global de la máquina y ofrecer un particionado espacial. • Cargar convenientemente en el espacio virtual disperso de la task, las regiones de datos y de código de forma que minimicen las colisiones entre procesadores. • Gestionar a nivel usuario la asignación de memoria (memory sets) y políticas de acercamiento de los datos a los flujos y viceversa. Controlar los fallos de páginas y la planificación de la memoria física. • Gestionar la entrada/salida, ofreciendo paralelismo y eficiencia. El funcionamiento actual se hace a través del servidor de UNIX, que considera que los procesos tienen un solo flujo, provocando mucha contención. • Instrumentar todos esos niveles de forma que extraigamos información de depuración para las aplicaciones y estadísticas que permitan la adaptación automática de las políticas de gestión a los recursos disponibles. 2. Planificación Con el abaratamiento de los componentes y la aparición de máquinas masivamente paralelas, surge la tendencia en los multiprocesadores de mecanismos y políticas de planificación espacial, además de la tradicional planificación temporal. Consideramos conveniente la existencia de un planificador que gestione la asignación de procesadores de la máquina a las aplicaciones que los soliciten. Es el CPU server. Partiendo de este particionado de la máquina, se puede permitir, y es muy conveniente para la ejecución eficaz de las aplicaciones, el hecho de que el usuario (el programa en ejecución) conozca y utilice de la forma más adecuada la submáquina que le ha sido asignada. El máximo rendimiento lo conseguirá si logra que la concurrencia de la aplicación se adapte al paralelismo real (procesadores) que le ha asignado el sistema. Respaldamos las propuestas de mapeo uno a uno de flujos de usuario sobre procesadores físicos [MARK92b][GOTT92][EDLE92]. Conviene también que la planificación dentro del kernel no vaya en contra de los deseos de la aplicación. Eliminar el tiempo compartido de propósito general, contrario a la planificación necesaria dentro de una única aplicación. Para ello, los eventos que ocurran dentro del kernel y que necesiten una replanificación de los flujos de ejecución, serán notificados al usuario mediante un mecanismo eficiente: las upcalls. Hemos añadido los mecanismos necesarios y la política de “scheduler-activations” a la planificación de procesadores del kernel de Mach 3.0 [LOEP93]. Como hemos dicho ya, no podemos dejar que la gestión de la memoria vaya en contra de la óptima ejecución de los flujos. Por lo tanto, nuestra propuesta es que la aplicación misma pueda gestionar su memoria. Aparece entonces la necesidad de asegurar una cierta cantidad de memoria de forma que la aplicación ajuste su ejecución a ese recurso e indique al sistema la forma más correcta de planificarlo. Nos parece conveniente la aparición de una abstracción nueva de kernel: el memory set, que permita también una planificación espacial del recurso memoria, hasta ahora gestionado con políticas globales de paginación y memoria virtual que provoca que las aplicaciones no sólo dependan de sus patrones de acceso a memoria, sino que estén a expensas de lo que hacen las demás aplicaciones que corren en la misma máquina, provocando tiempos de acceso a los datos erráticos e impredecibles. En esta línea, estamos desarrollando los mecanismos a nivel de kernel y a nivel de usuario (librerías y servidores) para dotar al entorno de las siguientes capacidades: • Poder cargar las zonas de memoria de la aplicación de forma que esté todo preparado allí donde correrán los flujos de ejecución (son las técnicas de “memory conscious scheduling”). • Lanzar la ejecución de los threads allí donde ya estén, o probablemente estén sus datos por haber corrido anteriormente allí (técnicas de “footprint”). • En máquinas de arquitectura NUMA, situar los datos en las memorias más rápidas, más cercanas al procesador. • Que el programador o el compilador puedan dar pistas (hints) sobre cuál será la gestión futura más conveniente de la memoria de la aplicación. Por ejemplo, información para que el paginador pueda hacer “prefetching” de datos y código. • Que la aplicación pueda dar indicaciones para la selección de páginas a reemplazar de memoria virtual, y fijar en memoria física aquellas que no interese paginar durante un tiempo, siempre dentro de su partición de la máquina (memory set), sin poner en peligro a las demás aplicaciones. • Permitir la coexistencia de varias políticas de gestión de memoria en una máquina, gracias siempre al particionado espacial, que da a cada usuario la posibilidad de decidir sobre la política de su submáquina y los parámetros más adecuados a su aplicación. En los siguientes apartados mostramos las posibilidades que nos ofrece la nueva tecnología microkernel, en especial el microkernel Mach 3.0, y la propuesta de un entorno eficiente para la ejecución de aplicaciones paralelas. En el apartado 3 presentamos extensamente la gestión de memoria en un microkernel como Mach, ya que es un tema poco conocido y nada documentado. Esta gestión es el punto central de nuestro trabajo actual. En el apartado 4 describimos el entorno que hemos desarrollado. En el Apartado 5 describimos una aplicación ejemplo. En el apartado 6 presentamos los mecanismos de evaluación de la ejecución de aplicaciones en nuestro entorno. 3. Gestión de la memoria 3.1. Gestión de la memoria en Mach: 3 niveles El sistema de gestión de memoria en Mach se basa en paginación y soporta memoria virtual. Una de las metas de Mach ha sido diseñar un sistema de gestión de memoria realmente portable para multiprocesadores, intentando reducir al máximo la parte de la gestión dependiente de la arquitectura. Por ello, la gestión de memoria aparece dividida en tres módulos. El primero, llamado pmap, se ejecuta en el kernel y es el único que depende de la arquitectura. Se encarga de la gestión de la MMU (configura sus registros, las tablas de páginas de hardware y recibe todos los fallos de página). El segundo módulo es código de kernel independiente de la máquina, y se refiere al procesamiento de los fallos de página, la gestión de los mapeos de direcciones y el reemplazo de páginas. El tercero se ejecuta como proceso de usuario y se llama gestor de memoria o paginador externo. Se encarga de la parte lógica del sistema de gestión de memoria, fundamentalmente el soporte en disco. Existe un gestor por defecto (default memory manager). El kernel y los gestores de memoria se comunican a través de un protocolo bien definido. 3.2. Espacio de direcciones La gestión del espacio de direcciones virtual se corresponde con el segundo módulo, y es el kernel el que se encarga de ella. Un espacio de direcciones virtual está asociado a una task y se crea y se destruye al mismo tiempo que la task propietaria. Puede verse como un conjunto de direcciones virtuales válidas referenciables por un thread que se ejecute dentro de la task. Consiste en un conjunto indexado y disperso de páginas de memoria, que el kernel agrupa internamente en regiones, de forma transparente al usuario. Cada región está formada por un conjunto de páginas virtuales contiguas que tienen los mismos atributos. Una región está definida por su dirección base y su tamaño. La agrupación de páginas en regiones permite que la tabla lógica de páginas no se incremente de forma desmesurada, ya que se puede determinar si una dirección está en uso o no a través de las regiones. Es decir: una dirección virtual sólo es válida si pertenece a una región definida. Para cada página se puede especificar un atributo de herencia. Inicialmente, el espacio de direcciones de una nueva task sólo contendrá aquellas páginas marcadas como heredables en la task que la ha creado. El resto de este nuevo espacio de direcciones será inválido. La llamada al sistema vm_inherit, puede modificar los atributos de herencia de un rango de memoria. Otros atributos asociados a página son los de protección, referentes al tipo de acceso permitido. Viene especificada como una combinación de los valores de lectura/escritura/ejecución, y necesitan soporte del hardware para poder ser aplicados. El atributo de máxima protección, especifica la máxima permisividad que se podrá tener sobre esa página, y, una vez establecido, sólo se podrá modificar hacia valores más restrictivos. El de protección actual, puede modificarse mientras respete el valor máximo permitido. La llamada vm_protect modifica estos atributos de protección. 3.3. Memory object Una abstracción relacionada con el uso del espacio de direcciones virtual es el memory object. Está dentro del tercer nivel, y se encargan de él los gestores de memoria. Un memory object, es la unidad de soporte para almacenamiento. Lógicamente puede verse como un recipiente para datos indexado por byte. Puede ser una página o un conjunto de páginas, pero también puede ser un fichero u otras estructuras de datos más especializadas. Los memory objects pueden mapearse en una porción del espacio de direcciones que no esté en uso, formando una nueva región, y de este modo acceder a él como se haría a cualquier dirección de memoria. La llamada que permite hacer esto es vm_map, y necesita como parámetros las características de la nueva región (posición, tamaño, protección, herencia, y offset dentro del objeto), así como el port que representa al memory object que soporta a la región. Si este port es nulo, será el default memory manager el encargado de esta nueva región, y el que provea las páginas solicitadas, inicializadas con ceros. El comportamiento de esta llamada en este caso, es equivalente al de la llamada vm_allocate, en la cual, el kernel decide de forma transparente qué objeto en el default memory manager soportará a la nueva región. Así, siempre que se establece un nuevo rango de memoria en un espacio de direcciones, se especifica un memory object, ya sea de forma implícita (para ser gestionado por el default memory manager) o de forma explícita, que dará soporte a ese rango. Otro parámetro de vm_map permite decidir si se quiere que el acceso a esa porción del objeto pueda ser compartido para lectura y escritura, o si, por el contrario, se quiere una copia privada, de manera que las modificaciones que se hagan no afecten al objeto original. En este último caso, el kernel creará un nuevo objeto, gestionado por el default memory manager, para que soporte la copia, que se hará usando la técnica de optimización copy-on-write. Cada memory object tiene que estar controlado por un gestor de memoria, que puede ser el default memory manager del sistema o uno externo. Cada uno puede implementar su propia semántica, que determine dónde almacenar las páginas que no están en memoria y llevar a cabo sus propias políticas que implementen, por ejemplo, memoria compartida entre tasks no relacionadas, o aporten sus propias reglas sobre lo que ocurre con los objetos después de sacarlos de memoria (por ejemplo, podría mantener una cache para los objetos referenciados últimamente, intentando ahorrar accesos al almacén de soporte). La llamada al sistema que sirve para invalidar cualquier rango de memoria es vm_deallocate. El kernel soporta otras manipulaciones explícitas de memoria mediante llamadas como vm_copy, vm_write o vm_read. La gestión de las páginas libres del sistema la lleva a cabo un thread de kernel, el pager daemon, que comprueba periódicamente el estado de la memoria. Cuando no hay suficientes páginas libres, se selecciona una página antigua que, si es necesario, se enviará al gestor encargado del memory object al que pertenece, con el objetivo de que éste la pase al almacén de soporte. 3.4. Gestor externo de memoria Los gestores externos de memoria son las tasks de usuario que controlan los memory objects, y permiten que el usuario elija la política que quiere que se siga en la gestión de una región de su espacio de direcciones. Por ejemplo, a través de estos gestores se puede implementar memoria compartida entre tasks no relacionadas o también memoria distribuida compartida, siendo estos paginadores los que se encarguen de mantener la coherencia. El default memory manager ofrece memoria compartida, pero no soporta memoria distribuida compartida. El gestor de memoria por defecto del sistema es, en la mayoría de los aspectos, simplemente un gestor de memoria externo. Provee almacén de soporte para la memoria anónima (vm_allocate, copia de memoria...). La ejecución del default memory manager tiene como propiedad importante, que no puede provocar fallos de página, ya que ningún otro gestor de memoria puede ofrecerle paginación. Por ello, sus datos, su código, y las páginas que recibe a través de mensajes se fijan en memoria. Para que un proceso pueda mapear un objeto1, debe comunicarse con el paginador que lo gestiona para obtener el port que representa a ese objeto (abstract memory object). Esta comunicación se debe realizar a través de funciones ofrecidas por el paginador para establecer la conexión. Entonces, el cliente ya puede utilizar la llamada vm_map. Se necesita asociar un port más al objeto, para que se pueda llevar a cabo el protocolo entre el kernel y el gestor de memoria. Este es el memory cache control port, creado por el kernel cuando un cliente mapea por primera vez el objeto. Será el port a través del cual el kernel recibirá los mensajes que el gestor le envíe relacionados con el memory object. Una vez creado, el kernel enviará un mensaje al abstract memory object port, pasándole derechos de envío al memory cache control port, y esperará la respuesta del gestor, que podrá ser de confirmación o de rechazo de la conexión. Las siguientes llamadas vm_map sobre el mismo objeto en el mismo host no provocarían ninguna comunicación entre el kernel y el gestor, porque la asociación ya existiría. Pager port Pager paging file memory object object_create (1) return(object_port) (2) Task Loader bin file vm_write (6) address space memory object port (4) region (3) vm_map (5) memory_object_init memory cache control port Mach 3.0 Figura 1: Inicialmente, se crea un objeto vacío que soportará el espacio de direcciones de la task, se mapea una porción del objeto en la región de la task y se llena de código y datos del fichero binario. El primer acceso que el cliente haga al objeto, provocará un fallo de página, ya que todavía no hay ninguna página del objeto en memoria. La rutina de gestión de la excepción hará una petición de datos al gestor encargado del objeto. Las peticiones de datos que hace el kernel son a través de mensajes, que el paginador puede contestar con otro mensaje que contenga los datos, con un mensaje de error, o con uno en el que diga que los datos no están disponibles, y que debe ser el kernel el que provea las páginas. Puede ocurrir que el kernel decida limpiar alguna página, es decir, enviar al paginador encargado de ella las modificaciones, por ejemplo, antes de sacarla de memoria física. En este caso, enviará la página en un mensaje al gestor como datos out-of-line (que mapeará en su espacio de direcciones). Además hará que la página física pase a estar asociada con el default memory manager; así, si en un tiempo razonable el gestor no ha movido las páginas a su destino, el kernel podría sacarlas de memoria a través del default manager que la llevará al fichero de paginación, aunque el gestor original seguiría teniéndola en su espa1. El protocolo que se describe es el especificado en la versión MK4. cio de direcciones. Pero, normalmente, el gestor de memoria podrá hacer el tratamiento correspondiente a la página (posiblemente copiarla en algún dispositivo o sistema de ficheros) y después utilizar la llamada vm_deallocate para liberar el espacio físico que ocupaba en su espacio de direcciones (como cualquier memoria recibida como datos out-of-line). También puede pasar que sea un gestor el que desee actualizar o recuperar alguna de las páginas gestionadas por él, y entonces pida al kernel que inicie este protocolo. Cuando ninguna task tenga ya mapeado un memory object determinado, el kernel informará de ello al gestor que se encarga de él, pero antes sacará de memoria todas las páginas modificadas. También puede ser un gestor el que decida finalizar el mapeo de uno de sus objetos, enviando un mensaje al kernel, que descartará todas las páginas residentes en memoria de ese objeto. 4. Entorno de ejecución de aplicaciones paralelas A continuación vamos a presentar el entorno propuesto para la ejecución de aplicaciones paralelas. Task Parent CPU Server Pager OSF/1 Server Parallel Application Application Manager Region Memory Object I/O Server Mach 3.0 Processor set Regions pages Processors Page Fault Figura 2: Servidores del entorno de ejecución de aplicaciones paralelas sobre Mach 3.0. 4.1. Gestor de aplicaciones paralelas Los sistemas operativos tradicionales proporcionan herramientas para la carga de programas y su posterior control (tratamiento de excepciones, fallos de página, etc.). Con este mismo objetivo, nuestro entorno incluye un servidor dedicado a la gestión básica de las aplicaciones paralelas. El primer paso necesario para ejecutar una aplicación paralela directamente sobre un microkernel consiste en leer el contenido de un fichero ejecutable, construir a partir de él un proceso (task) y ofrecerle un entorno de ejecución sólido. Dentro de este entorno de ejecución el gestor de aplicaciones dispone quién se ocupa de la memoria del proceso, quién se ocupa de los procesadores asignados al proceso y quién se ocupa de la entrada / salida que pueda realizar. Además el mismo gestor se encarga del tratamiento por defecto de las excepciones de la aplicación. En nuestra implementación actual, el gestor de aplicaciones entiende el formato de ficheros mach object (macho), con lo que le es posible construir un espacio de direcciones completo conteniendo código, datos inicializados, datos no inicializados y pila. El gestor utiliza el paginador para crear estas cuatro regiones de memoria tal y como están descritas en el fichero ejecutable. A continuación mapea la información contenida en el fichero en las regiones de código y datos inicializados y simplemente pone a cero las regiones de datos no inicializados y pila. Como gestor de excepciones por defecto, este servidor indica al sistema que él va a recibir las notificaciones de las excepciones provocadas por las aplicaciones. Queda abierta además la posibilidad de que una aplicación concreta pueda gestionarse ella misma sus excepciones. En caso necesario el gestor de aplicaciones puede asignar procesadores y preparar la entrada/salida estándard a la aplicación. Estos dos últimos pasos, opcionalmente, puede realizarlos también la propia aplicación. 4.2. Pager Hemos implementado un paginador externo con el objetivo de poder controlar la memoria del espacio de direcciones de una task, y poder decidir las políticas que se aplican en cada uno de los niveles de la gestión de memoria. El cargador de aplicaciones que hemos implementado, nos permite especificar el proceso que gestionará el espacio de direcciones de una task, ya que utiliza la llamada vm_map para cargar en memoria el código, los datos y la pila de las tasks. Para poder extender este control a la memoria reservada dinámicamente, las tasks en nuestro entorno no deben utilizar la llamada vm_allocate, ya que ésta asocia la nueva memoria al default memory manager, sino reservar la memoria con vm_map y utilizar el mismo gestor que se encarga del resto de su memoria. Es posible que la aplicación y el kernel colaboren con el gestor del espacio de direcciones para decidir la política más adecuada en cada caso. La aplicación puede dar pistas sobre el uso que va a hacer de la memoria, y el kernel, ante un fallo de página, puede detectar quién lo ha producido. De esta manera, el gestor puede intentar predecir cómo van a ser referenciadas las páginas y aplicar él la política de reemplazo adecuada, incluso utilizando pre-fetching en la paginación. En esta línea, sería útil disponer de una herramienta que permitiera que el gestor pudiera reubicar dinámicamente el código y los datos, en función de las pistas aportadas por la aplicación y el kernel [ORR92][ORR94]. Para optimizar la ejecución, el paginador debe ser un proceso privilegiado, que pueda fijar su propio espacio de direcciones en memoria física. De este modo, evitamos que él mismo sufra el proceso de paginación, que podría afectar a páginas gestionadas por él, que, en ese momento, tuviera en su espacio de direcciones para manipularlas. Esto haría que el gestor perdiera el control sobre ellas, ya que serían paginadas por el encargado del espacio de direcciones del gestor. También hay que evitar la influencia entre aplicaciones, debida a la paginación provocada por cada una de ellas. 4.3. Cpu server Para dar soporte a la posibilidad de una planificación basada en políticas de espacio compartido necesitamos una utilidad para asignar procesadores a aplicaciones y permitir así el particionado del multiprocesador y la coexistencia de varios modelos de programación. Las aplicaciones paralelas que desean sacar un alto rendimiento a la máquina necesitan saber cuántos procesadores están disponibles, cuántos pueden pedir en este instante, qué procesadores son, etc. Hemos llevado a cabo la realización de un servidor de procesadores o CPU server, es decir, un proceso privilegiado (una task) que se encarga de gestionar los procesadores físicos en favor de las aplicaciones que se los pidan. Los clientes de este servidor son aplicaciones paralelas que corren sobre un multiprocesador de memoria compartida. Los clientes suelen ser una task con varios threads concurrentes (pero en la realización actual está abierto que pueda ser también una aplicación que incumba a varias tasks). El interfaz de las llamadas al servidor es al principio muy sencilla; se compone únicamente de tres llamadas. La primera es para solicitar un determinado número de procesadores, la segunda es para devolverlos y la tercera para pedir información. Mach ofrece la posibilidad de agrupar procesadores físicos y virtuales para que éstos últimos se ejecuten sobre los primeros; el objeto de kernel que los reúne es el processor set o grupo de procesadores. La aplicación que necesite procesadores en exclusiva tiene que crear uno o varios processor set propios y a continuación pedir al servidor que le inserte procesadores en uno de esos processor sets. La aplicación paralela decide también qué threads se ejecutarán en cada grupo de procesadores, asignando y desasignando sus threads a sus processor set. El servidor mantiene disponibles, para otorgar a cualquier task que le llama, hasta el número máximo de procesadores de la máquina menos uno, que es el procesador master y que es mejor no asignar en exclusiva a nadie (de hecho, no puede salir del default processor set). El server no desbanca procesadores a las aplicaciones; son éstas las que los liberan en cuanto ya no los necesitan o acaban. El CPU server mantiene el estado de los procesadores en una tabla. En ella relaciona los procesadores físicos con el pset al que están actualmente asignados y qué task solicitó la asignación. Los procesadores asignados al default pset, sin contar al master, están disponibles para ser reasignados. Debido a que no todas la peticiones de servicio se pueden atender inmediatamente, el CPU server ha sido realizado con la posibilidad de creación dinámica de flujos que atiendan peticiones de reasignación de procesadores. El usuario tiene la posibilidad de solicitar que no se le sirva su petición hasta que todos los procesadores que ha solicitado le hayan sido asignados. 4.4. I/O server Para que las aplicaciones se ejecuten en un entorno completo, hace falta proporcionarles entrada/salida. Nuestra propuesta incluye un servidor de entrada/salida que ofrece los servicios básicos de UNIX (open, close, read, write, etc.). Las aplicaciones se montan con una librería de acceso al servidor de entrada/salida. La librería se comunica con el I/O server a través de paso de mensajes. Cada vez que la aplicación realiza una llamada a la librería, ésta envía un mensaje al servidor, que accede al fichero o dispositivo y devuelve el resultado o un error. El servidor puede trabajar sobre el subsistema OSF/1, obteniendo las ventajas de la entrada/ salida de UNIX o puede acceder a los dispositivos directamente a través de Mach. El hecho de que la librería ofrezca un interfaz de entrada/salida compatible con UNIX trae consigo la rápida portabilidad de un mayor número de aplicaciones con las que poder evaluar nuestro entorno. 5. Aplicaciones El objetivo final de todo sistema operativo (y, por supuesto, también de aquellos basados en un microkernel) es ofrecer un entorno para la ejecución de aplicaciones. En concreto, nuestro trabajo está centrado en la ejecución de aplicaciones paralelas en sistemas multiprocesadores. Así pues, se han escogido muestras de diversos tipos de aplicaciones con el objetivo de evaluar la bondad del entorno ofrecido por el microkernel. El esfuerzo se ha orientado en dos sentidos: • En primer lugar, procurar que el microkernel, dentro de la sencillez, facilite a la aplicación todos los recursos que ésta pueda necesitar para su ejecución. • En segundo lugar, estudiar las modificaciones que conviene hacer a las aplicaciones actuales con el fin de aprovechar al máximo el nuevo entorno, aumentando así su rendimiento. Las aplicaciones sobre las que se ha trabajado incluyen un programa de generación de fractales (en el que hay que realizar cálculos intensivos, pero bastante independientes unos de otros), un servidor (que combina entrada/salida con cálculo), etc. 5.1. Generación de fractales El programa fractal genera un conjunto de Mandelbrot y lo muestra por pantalla. El algoritmo es sencillo: consiste en obtener las dimensiones de la ventana donde se va a dibujar (determinadas por el usuario al redimensionar la ventana de la aplicación, en tiempo de ejecución) y se aplica al punto correspondiente a cada píxel la fórmula iterativa que determina su color. Los cálculos que afectan a un punto son independientes del resto de puntos, con lo cual son fácilmente paralelizables. La sincronización se necesita en el momento de pintar los puntos. Por motivos de eficiencia, una vez obtenido el color de un punto, no se dibuja, sino que se almacenan en un buffer; y sólo cuando esté lleno se pintan los píxels correspondientes. Esto se aprovecha para distribuir los datos de manera que el sistema pueda explotar la localidad. En resumen, cada vez que se redimensiona la ventana, el proceso es el siguiente: obtener las nuevas dimensiones de la ventana por cada punto de la ventana calcular su color acumularlo en el buffer si el buffer está lleno, vaciarlo pintando los puntos En el diseño del programa (figura 3) se pueden distinguir tres tipos de threads. El thread principal se encarga de recibir los eventos de X y lanzar los threads calculadores. Estos realizan los cálculos y pasan el resultado al thread visualizador, que es el único que llama a las rutinas de dibujo. Cada vez que se recibe un evento indicando el redimensionado de la ventana, el thread principal crea cierto número de threads calculadores. Cada uno de estos nuevos threads irá cogiendo fragmentos de ventana y calculando el color de los píxels. El resultado se irá acumulando en buffers. Cada uno de estos buffers se reparte por colores, de manera que los puntos del mismo color van a parar a la misma zona. Cuando una de estas zonas está llena, se cede el control al visualizador, que la vuelca en un buffer propio y llama a las rutinas de dibujo. thread principal Xt loop() creación de flujo datos ventana buffers threads calculadores resize X event thread visualizador XtDrawPoints() procesadores Figura 3: Estructura básica de datos y flujos que intervienen en la generación de fractales. Hay diversas posibilidades para implementar el acceso a buffers. Una de ellas sería tener un único buffer. De este modo, los threads calculadores deberían utilizar técnicas de exclusión mutua para acceder a cada zona del buffer. La opción que hemos tomado es tener tantos buffers como procesadores (virtuales o físicos, dependiendo del entorno). De este modo, cada thread calculador podría acceder al buffer correspondiente a su procesador sin necesidad de exclusión mutua. El caso representado en la figura anterior corresponde a una situación en la que cada thread calculador se encuentra sobre un procesador (virtual o físico). Esta distribución facilita que los datos utilizados por el código que se ejecuta en cada procesador, vayan situándose en las cache o en memorias locales, facilitando que el sistema aproveche la afinidad de memoria y se acelere, por tanto, la ejecución de la aplicación. 5.2. Otras aplicaciones Otro tipo de aplicaciones que consideramos características para la ejecución paralela en nuestro entorno son los servidores o aplicaciones similares, en las que el número de threads es bastante estático y longevo. En esta línea hemos diseñado una aplicación cuyo comportamiento es el de un productor/consumidor y un servidor sintético que combina threads estáticos con otros que se crean dinámicamente, como benchmark para tomar medidas. Su descripción se puede leer en [GIL94c][GIL94a]. 6. Toma de medidas Junto con el objetivo de conseguir un buen entorno de ejecución para aplicaciones paralelas, es muy importante tener en cuenta las posibilidades que ha de ofrecer dicho entorno para evaluar su ejecución. Por ello, se han estudiado los mecanismos que ofrecen la arquitectura y el sistema operativo, se han incorporado herramientas de medición y, finalmente, se ha instrumentado el kernel y se han realizado medidas del interior del sistema operativo. 6.1. Soporte de la arquitectura y el sistema operativo La versión multiprocesador del microkernel Mach sobre arquitectura Intel permite la medición de tiempos con alta precisión minimizando a la vez la perturbación introducida en el código que se desea medir. En este sentido al compilar el kernel se puede especificar que uno de los procesadores se utilice única y exclusivamente como contador. En este caso las aplicaciones van a disponer de un procesador menos para ejecutarse, pero como contrapartida se podrán tomar medidas bastante precisas (del orden de 0.5 microsegundos de precisión utilizando un procesador i486 a 33 Mhz.). Dicho contador está aislado dentro de una página física en el espacio virtual del kernel y la gran ventaja es que se mapea en los demás espacios de direcciones de modo que pueden acceder a ella para leerlo sin necesidad de hacer una llamada a sistema. 6.2. Herramientas de medición: Jewel La técnica de dedicar un procesador a la toma de medidas fue introducida en Mach por el grupo de desarrollo de la herramienta JEWEL (Just a nEW Evaluation tooL) [LANG92]. Esta herramienta ha sido desarrollada en GMD (German National Research Center for Computer Science). Utilizando Jewel, las aplicaciones utilizan memoria compartida para consultar el tiempo y dejar sus trazas. Éstas son generadas por unas macros en C proporcionadas por Jewel y que deben introducirse dentro del código fuente de las aplicaciones que se desean medir. Jewel está formado por dos procesos principales: el collector y el evaluator. La aplicación instrumentada comparte un buffer con el collector. La aplicación deja la traza en el buffer y el collector la va recogiendo y la envía al evaluator. El proceso evaluator puede ejecutarse en otro ordenador, ya que la comunicación entre collector y evaluator se realiza mediante sockets. Esta característica ayuda también a no introducir alteraciones, en forma de aumento de carga, en la máquina donde se realizan las mediciones. El proceso evaluator presenta los datos ordenados según el tiempo en que han ocurrido y en formato texto. Se puede a su vez utilizar para suministrarlos a otras aplicaciones que permitirían la visualización gráfica de los resultados e incluso presentar la evolución que sufre la aplicación a lo largo del tiempo. 6.3. Instrumentación del kernel para la toma de medidas Parte de nuestro trabajo ha consistido en introducir modificaciones en el código del kernel con el objetivo de tomar medidas. Éstas pueden clasificarse en dos tipos: frecuencia con que se ejecuta un código del kernel o pasa algún evento y tiempo empleado por las operaciones sencillas que ejecuta el kernel, como los cambios de contexto de bajo nivel o la creación de threads. En cuanto a las primeras, se ha hecho un estudio para determinar qué contadores de eventos ya existían dentro del kernel y se han introducido nuevos contadores. Por ejemplo, ya existían los contadores de número de threads creados, número de pilas creadas, etc. A éstos se han añadido contadores por procesador sobre número de veces que se realiza un cambio de contexto en cada procesador, número de veces que un thread se bloquea en cada procesador, aciertos en footprints, número de fallos de página por procesador, etc. Inicialmente los contadores internos del kernel sólo podían consultarse desde el kernel debugger. Sin embargo, es mucho más cómodo consultarlos mediante una llamada a sistema. Para ello se ha aprovechado la llamada host_info añadiéndole una nueva opción que extrae el valor de los contadores dejándolos en una estructura de usuario (struct host_extended_info). En cuanto a la toma de medidas de coste de las operaciones internas al kernel, éste se ha modificado para que tome el tiempo al entrar y salir de la secuencia de código que se quiere medir. Para tomar el tiempo se utiliza el contador incrementado por el procesador dedicado, con lo cual la alteración en la ejecución es mínima. Dicha toma de tiempo consiste simplemente en consultar el valor del contador y depositarlo en una variable global del kernel. Esta variable contiene los valores del contador al entrar y salir de la secuencia de código. Existe una pareja de valores almacenada por cada secuencia de código que se quiere medir. La información almacenada en estas variables se extrae del kernel a través de una llamada a sistema, utilizando un mecanismo muy similar a la llamada host_info. De esta forma se han tomado medidas del tiempo que consumen la rutina de creación de threads (thread_create), la de recálculo de prioridades de un thread (thread_quantum_update) y la de cambio de contexto (switch_context). 7. Conclusiones y trabajo futuro Hoy, que se trabaja sobre microkernels y librerías de threads de usuario, el coste de creación, destrucción y cambio de contexto está muy optimizado. La planificación de procesadores se apoya en la planificación espacial. Sin embargo, hay un coste que no se ha considerado todavía suficientemente: el coste de traer los datos y el código a las memorias próximas al procesador. Presentamos un entorno que facilita la reducción de este coste mediante la planificación de los threads allí donde se encuentre la memoria a la que van a acceder, basado en técnicas de “footprint” y en las propuestas de “memory-conscious scheduling”. Respaldamos las propuestas de mapeo uno a uno de flujos de usuario sobre procesadores físicos. Hemos añadido los mecanismos necesarios y la política de “scheduler-activations” a la planificación de procesadores del kernel de Mach 3.0, los mecanismos que permitan aplicar “memory conscious scheduling” y “footprint”, situar los datos en las memorias más rápidas, dar pistas (hints) sobre cuál será la gestión futura más conveniente de la memoria de la aplicación, dar indicaciones para la selección de páginas a reemplazar de memoria virtual, y permitir la coexistencia de varias políticas de gestión de memoria. Estamos desarrollando y portando aplicaciones reales sobre este entorno e instrumentando el kernel y los servidores para la extracción de medidas. Las herramientas están listas, el siguiente paso es la definición y evaluación de las políticas. 8. Referencias y bibliografía [ACCE86] “Mach: A New Kernel Foundation for UNIX Development”, Mike Accetta et al., Proceedings of the Summer 1986 Usenix Conference, July 1986. [BLAC90] “Scheduling and Resource Management Techniques for Multiprocessors”, David L. Black, PhD Thesis, Carnegie Mellon University, July 1990. [BOYK93] “Programming under Mach”, J. Boykin, D. Kirschen, A. Langerman, S. LoVerso, AddisonWesley Publishing Company, 1993. [COOP88] “CThreads”, Eric C. Cooper and Richard P. Draves, CMU-CS-88-154, School of Computer Science, Carnegie Mellon University, June 1988. [CROV91] “Multiprogramming on Multiprocessors”, M. Crovella, P. Das, C. Dubnicki, T. LeBlanc and E. Markatos, Third IEEE Symposium on Parallel and Distributed Processing, December 1991, Technical Report 385, Computer Science Department, University of Rochester, New York, February 1991. [EDLE92] Jan Edler, comunicación personal, junio 1992. [GIL94a] “Cooperación entre la aplicación y el kernel para la planificación de flujos, en sistemas multiprocesadores, como soporte al paralelismo”, Tesis doctoral, Departament d’Arquitectura de Computadors, Universitat Politècnica de Catalunya, Mayo 1994. [GIL94b] “Towards User-level Parallelism with Minimal Kernel Support on Mach”, Marisa Gil, Toni Cortés, Angel Toribio, Nacho Navarro, DAC/UPC Report RR-94/07, 1994. [GIL94c] “The Enhancement of a User-Level Thread Package Scheduling on Multiprocessors”, Marisa Gil, Xavier Martorell, Nacho Navarro, 2nd International Conference on Software for Multiprocessors and Supercomputers, SMS TPE'94, Moscow. [GOLU91] “Moving the Default Memory Manager out of the Mach Kernel”, David B. Golub, Richard P. Draves, Proceedings of the Usenix Mach Symposium, Nov. 1991. [GOTT92] Allan Gottlieb, comunicación personal, junio 1992. [GUPT91] “The Impact of Operating System Scheduling Policies and Synchronization Methods on the Performance of Parallel Applications”, Anoop Gupta, A. Tucker and S. Urushibara, ACM SIGMETRICS, May 1991, Performance Evaluation Review, Vol.19 Num.1, 1991. [LANG92] “JEWEL: Design and Implementation of a Distributed Measurement System”, F. Lange, R. Kröger, M. Gergeleit, IEEE Trans. on Parallel and Distributed Systems, Vol. 3, No 6., Nov. 1992. [LOEP93] “OSF Mach Kernel Interfaces”, Keith Loepere, Open Software Foundation and Carnegie Mellon University. April, 1993. [LOEP93] "MACH 3 Kernel Principles", Keith Loepere, Open Software Foundation and Carnegie Mellon University. April, 1993. [MARK92a] “Memory-Conscious Scheduling in Shared Memory Multiprocessors”, E. P. Markatos, T. J. Leblanc, 1992. [MARK92b] Evangelos. P. Markatos, comunicación personal, junio 1992. [ORR92] “OMOS - An Object Server for Program Execution”, Douglas B. Orr, Robert W. Mecklenburg, UUCS-92-033, July 1992. [ORR94] “Dynamic Program Monitoring and Transformation Using the OMOS Object Server”, Douglas B. Orr, Robert W. Mecklenburg, Peter J. Hoogenboom and Jay Lepreau, in “The Interaction of Compilation Technology and Computer Architecture” , Chapter 1, Kluwer Academy Publishers, Ed. Lilja and Bird, Feb. 1994. [RASH87] “Machine-Independent Virtual Memory Management for Paged Uniprocessor and Multiprocessor Architectures”, R. Rashid, A. Tevanian, jr, et al., Technical Report CMU-CS87-140, Oct. 1987. [TANE92] “Modern Operating Systems”, Andrew S. Tanenbaum, Prentice-Hall International, 1992, ISBN 0-13-595752-4. [YOUN90] “The X Window System: Programming and Applications with Xt, Motif Edition”, Douglas Young, Prentice Hall, 1990, ISBN 0-13-497074-8.
