Sistemas operativos Desafos para la Gestin de Recursos de la GPU

Abstracto
La unidad de procesamiento grfico (GPU) se est convirtiendo en una muy potente
plataforma para acelerar los grficos y datos en paralelo aplicaciones de clculo intensivo.
Supera significativamente procesadores de varios ncleos tradicionales en el rendimiento
y la energa eficiencia. Sus mbitos de aplicacin tambin varan ampliamente de sistemas
integrados a los sistemas de computacin de alto rendimiento. Sin embargo, el apoyo de
sistemas operativos no es la adecuada, careciendo modelos, diseos, y los esfuerzos de
aplicacin de los recursos de la GPU gestin para entornos multitarea.
Este documento identifica un modelo de gestin de recursos de la GPU para proporcionar
una base para la investigacin de los sistemas operativos usando GPU la tecnologa. En
particular, se presentan los conceptos de diseo para la GPU manejo de los recursos. Una
lista de los desafos que los sistemas operativos tambin se proporcionan para destacar la
orientacin futura de esta investigacin dominio, incluyendo ideas especficas de
programacin de GPU para la vida real sistemas de tiempo. Nuestra evaluacin preliminar
demuestra que el rendimiento del software de cdigo abierto es competitivo con el de
software propietario, y por lo tanto, los sistemas operativos re - bsqueda puede
comenzar a investigar el manejo de recursos GPU.
1 Introduccin
El rendimiento y la energa son las principales preocupaciones para los sistemas
informticos de hoy en da. En la dcada de 2000, los fabricantes de chips han competido
en la frecuencia de reloj de continuar las mejoras de rendimiento en sus lneas de
productos. Por ejemplo, el procesador Intel Pentium 4 fue el primer producto comercial
que supera una velocidad de reloj de 3 GHz en 2002. Esta carrera rendimiento en
velocidad de reloj, sin embargo, lleg a su fin debido a los problemas de energa y de calor
que impiden que el diseo de chips de aumentar pulsos de reloj en la tecnologa de un
solo ncleo clsica. Desde finales de la dcada de 2000, las mejoras de rendimiento han
seguido viniendo a travs de innovaciones en la tecnologa multi-core, en lugar de
aumentos de las tasas de reloj. Este cambio de paradigma fue un gran avance para lograr
un alto rendimiento con bajo consumo de energa. Hoy en da, estamos entrando en la era
" many-core , con el fin de cumplir con los requisitos de rendimiento adicionales de
aplicaciones de datos en paralelo y de clculo intensivo emergentes. No slo las
aplicaciones de computacin de alto rendimiento (HPC), sino tambin aplicaciones
embebidas, tales como vehculos autnomos [39, 41] y los robots [26], se benefician de la
potencia de los procesadores de mltiples ncleos para procesar una gran cantidad de
datos obtenidos a partir de su funcionamiento entornos.
La unidad de procesamiento grfico (GPU) se ha convertido en una de las plataformas ms
potentes que abarca el concepto de procesadores de mltiples ncleos. La figura 1 ilustra
las tendencias de rendimiento recientes del GPU conocido y arquitecturas de CPU de
NVIDIA e Intel. El mximo rendimiento de un solo chip del estado de la tcnica la
arquitectura GPU supera 1,500 GFLOPS, mientras que la de un microprocesador
tradicional es de alrededor de 100 GFLOPS, en el mejor. Esta ventaja de rendimiento no
trivial de la GPU viene de cientos de ncleos de procesamiento integrados en un chip. La
GPU tambin es ms preferible que la CPU en el rendimiento por vatio. En concreto, la
GPU es de aproximadamente 7 veces ms energa y eficiente que la CPU actual. Un
anuncio reciente de los sitios de supercomputacin TOP500 revelados [ 40 ] de que tres de
los cinco principales supercomputadoras comprenden grupos GPU y mejoras de
rendimiento significativas son proporcionados por estas agrupaciones de la GPU para
aplicaciones cientficas [ 38 ] . Sistemas de almacenamiento a gran escala tambin se
benefician de la GPU [1, 9, 19]. De hecho, el servicio de computacin en la nube Amazon
EC2 aprovecha racimos de GPU para construir sus centros de datos. En el dominio de
sistemas embebidos, una nueva versin del vehculo autnomo de Carnegie Mellon [41]
equipa cuatro GPUs de NVIDIA para mejorar su potencia de clculo necesaria para las
tareas de conduccin autnomas, incluyendo la percepcin basada en la visin y la
planificacin de movimientos. Un estudio de caso de Stanford [39] revel que la GPU
puede acelerar las aplicaciones de visin artificial para la conduccin autnoma de 40
veces en comparacin con la ejecucin de la CPU. Un rpido crecimiento de la
computacin de uso general en la GPU, tambin conocido como GPGPU, se apoya en los
avances recientes en la tecnologa de programacin que permite a la GPU para ser
utilizado fcilmente por los problemas generales " cmputo. A pesar del xito de la
tecnologa de GPU, los sistemas operativos son compatibles con el software de los
productos bsicos [6, 28, 33] es muy limitado para la gestin de los recursos de la GPU.
Conceptos multi -tarea, tales como la equidad, la asignacin de prioridades, y el
aislamiento, no se admiten en absoluto. La comunidad de investigadores ha desarrollado
varios enfoques para la gestin de los recursos de la GPU recientemente. En particular, las
contribuciones notables incluyen TimeGraph [17] que proporciona capacidades de
priorizacin y el aislamiento, y el germen [2] con el apoyo de la justicia, para aplicaciones
GPU multi-tarea. A pesar de la escasa informacin de los detalles de hardware de la GPU a
disposicin del pblico, estos estudios hacen esfuerzos para desarrollar GPU primitivas de
gestin de recursos a nivel de controlador de dispositivo. Sin embargo, su funcionalidad
est limitada a las cargas de trabajo especficas. Tambin hay otros proyectos de
investigacin sobre la gestin de recursos de la GPU disponibles en las capas superiores
del controlador de dispositivo, incluyendo planificadores de CPU [ 8 ] , monitores de
mquinas virtuales [ 7 , 11, 12 , 20 ], y los programas del espacio de usuario [ 3 , 10, 36 ] ,
pero su rendimiento y las capacidades bsicas se limitan a software materia prima
subyacente . Creemos que la investigacin debe explorar los sistemas operativos y
abordar los problemas de gestin de recursos de la GPU para habilitar la tecnologa de
GPU en varios dominios de aplicacin. Este documento identifica varias direcciones hacia
los desafos de los sistemas operativos para la gestin de recursos de la GPU. En la
actualidad, nos falta an un modelo de gestin de recursos de la GPU fundamental que
podra ser la base de los esfuerzos de investigacin futuros. La informacin que falta del
software de cdigo abierto es particularmente un problema crtico para explorar el diseo
y la aplicacin de la gestin de los recursos de la GPU sistemas. En este trabajo,
presentamos las ideas iniciales y las posibles soluciones a estos problemas abiertos.
Tambin demuestran que el software de cdigo abierto ahora est listo para ser utilizado
de manera fiable para la investigacin. El resto del artculo est organizado de la siguiente
manera. Las premisas detrs de este trabajo se describen en la Seccin 2. Seccin 3
presenta el estado del modelo de programacin de GPU de arte, y en la seccin 4
introduce un modelo de gestin de recursos de la GPU bsica para el sistema operativo. La
seccin 5 ofrece desafos de sistemas operativos para la gestin de los recursos de la GPU,
incluyendo una evaluacin preliminar del software de cdigo abierto existente. Las
conclusiones finales de este trabajo se presentan en la Seccin 6.
2 Nuestras suposiciones del sistema
Este documento considera los sistemas heterogneos compuestos por CPUs multi-core y
GPU. Existen varias arquitecturas GPU hoy. Mientras que muchos microprocesadores
tradicionales diseados sobre la base de la arquitectura de CPU X86 compatibles a travs
de muchas generaciones en las ltimas dcadas, las arquitecturas de GPU tienden a
cambiar en aos. NVIDIA ha lanzado la arquitectura Fermi [30] a partir de 2011, el apoyo a
los dos programas de grficos y computacin. Este documento se centra en la arquitectura
Fermi, pero el concepto tambin es aplicable a otras arquitecturas. Tambin asumimos
una a bordo GPU. Aunque Intel proporciona una nueva arquitectura basada en X86,
llamado Sandy Bridge [13], que integra la GPU en un chip, GPUs en un tablero siguen
siendo ms populares hoy en da. En el trabajo futuro, sin embargo, vamos a estudiar las
implicaciones de las GPU de a bordo y en el chip desde el punto de vista de los sistemas
operativos. Dado un modelo de GPU de a bordo, se supone que la CPU y la GPU funcionan
de forma asncrona. En otras palabras, los contextos de CPU y contextos GPU se procesan
por separado. Una vez que los programas de usuario lanzar un trozo de cdigo en la GPU
para ser acelerada, que se descarga de la CPU. Los programas de usuario pueden
continuar ejecutndose en la CPU mientras que este pedazo de cdigo se procesa en la
GPU, y pueden incluso poner en marcha otra pieza de cdigo en la GPU antes de la
finalizacin del anterior cdigo GPU. La GPU pone en cola la solicitud de lanzamiento, y
ejecuta el cdigo ms tarde, cuando est disponible.
3 Modelo de programacin
La GPU es un dispositivo para acelerar particular, cdigo de programa en lugar de una
unidad de control como la CPU. Los programas de usuario, por tanto, iniciar la ejecucin
de la CPU, y los pedazos de lanzamiento de cdigo, a menudo referido como kernels1
GPU, en la GPU para ser acelerado. Hay por lo menos tres pasos principales para
programas de usuario que debe tomar para acelerar en la GPU.
1 Asignacin de memoria: En primer lugar, los programas de usuario se deben asignar
espacios de memoria en la memoria del host y el dispositivo que se requieren para el
clculo. Hay varios tipos de memoria de la GPU: comunitaria, local, global, constantes, y el
montn.
2 Copiar datos: Los datos de entrada se deben copiar desde el ordenador a la memoria del
dispositivo antes de que el ncleo de la GPU se inicia en la GPU. Por lo general, los datos
de salida tambin se copian de nuevo desde el dispositivo a la memoria del host para
devolver el resultado calculado para programas de usuario.
3 Lanzamiento Kernel: Cdigo del programa acelerado por GPU debe ser lanzado desde la
CPU a la GPU en tiempo de ejecucin, como la propia GPU no es una unidad de control.
Las fases de asignacin de memoria no es probable acceder a la GPU, y deben gestionar
las regiones de direccin de memoria del dispositivo disponible para cada solicitud. Copie
los datos y las fases de kernel- lanzamiento, por el contrario, necesitan tener acceso a la
GPU para mover datos entre el host y la memoria del dispositivo, y el lanzamiento de
cdigo de programa GPU. La Figura 2 ilustra un ejemplo que muestra un breve flujo de
ejecucin de la GPU acelerada multiplicacin de matrices, es decir, A [ ] B [ ] = C [ ]. La
imagen del ncleo GPU debe ser cargada en la memoria del host. Dos buffers de entrada,
A [ ] y B [ ], deben tambin tienen valores vlidos para el clculo, mientras que un bfer de
salida C [ ] puede estar vaco. La imagen del ncleo suele estar cargado en el inicio. Dado
que la GPU utiliza la memoria del dispositivo para el acceso de datos, los espacios de datos
se deben asignar en la memoria del dispositivo. Los buffers de entrada se copian en estos
espacios de datos asignados en la memoria del dispositivo a travs del bus PCI. Despus
de que los datos de entrada estn dispuestos en la memoria del dispositivo, el ncleo de
la GPU se inicia la ejecucin. Los datos de salida son generalmente copian de nuevo en la
memoria del host. Este es un flujo genrico para acelerar el programa en la GPU. La
programacin de la GPU requiere que el dispositivo y las partes de acogida. La parte del
dispositivo contiene ncleos codificados por las instrucciones de la GPU, mientras que la
parte de acogida es ms como un hilo principal que se ejecuta en la CPU para controlar las
copias de datos y los lanzamientos del kernel. La parte de host puede ser escrito en un
lenguaje de programacin existente, tales como C y C + +, pero debe estar alineada con
una interfaz de programacin de aplicaciones (API) definida por el marco de programacin
para comunicar con la parte del dispositivo. Los siguientes son los marcos de
programacin GPU bien conocidos:
Open Graphics Language (OpenGL) proporciona un conjunto de funciones de
biblioteca que permiten a las aplicaciones de espacio de usuario para programar
GPU shader y subirlo a la GPU para acelerar el procesamiento de grficos 2D/3D.
Open Computing Language (OpenCL) es un lenguaje de programacin similar a C
con el apoyo de las funciones de la biblioteca. Se puede paralelizar programas
conceptualmente en cualquier dispositivo, como las GPUs, Cell BE, y CPUs multi-
core.
Compute Unied Device Architecture (CUDA) tambin es un lenguaje de
programacin similar a C con soporte funciones de biblioteca. Se puede paralelizar
programas como OpenCL, pero est dedicado a la GPU.
Hybrid Multicore Parallel Programmin (HMPP) es una extensin del compilador
pragma para paralelizar programas conceptualmente en cualquier dispositivo.
OpenMP tambin emplea este estilo de programacin, pero est dedicado a CPUs
multi-core.
El procesamiento de grficos suele ser ms complicado de lo que la computacin en
general. Un pipeline de grficos comprende decenas de escenarios, donde los datos de
vrtices vienen de un extremo de la tubera, consigui procesar en cada etapa, y el cuadro
rendido sale por el otro extremo. Algunas etapas son programables y otros no lo son. Por
ejemplo, vertex y pixel shaders son programables, pero rasterizacin y conversin de
formato son las funciones fijas. La informtica general, por su parte, utiliza slo las
unidades de sombreado, tambin conocido como computacin (o CUDA cores). Depende
de los programas de espacio de usuario para cargar cdigo GPU. El cdigo de la GPU se
puede compilar en tiempo de ejecucin o sin conexin. Programas de computacin a
menudo se compilan sin conexin, slo paralelizados en ncleos de computacin,
mientras que los programas de grficos necesitaran compilacin en tiempo de ejecucin,
ya que utilizan muchos shaders para operaciones grficas. Una vez compilado como
binarios de cdigo GPU, sin embargo, que se cargan en la GPU en tiempo de ejecucin de
la misma manera. Por lo tanto, la pila de software no necesita ninguna modificacin en el
sistema operativo.
4 Modelo de Gestin de Recursos
En esta seccin, se presenta un modelo bsico de la gestin de los recursos de la GPU,
particularmente a lo largo de la pila del sistema Linux, con capacidad para el conductor del
propietario NVIDIA [28], el controlador de cdigo abierto de PathScale [33], y el
controlador de cdigo abierto de Linux [6]. De Windows Display Driver Model (WDDM)
[35] tambin pueden ser aplicables a nuestro modelo, ya que NVIDIA podra compartir el
90% de cdigo entre Linux y Windows [34]. Como se mencion en la Seccin 2, la
siguiente discusin supone la arquitectura Fermi de NVIDIA [30], pero tambin es
conceptualmente aplicable a la mayora de las arquitecturas de GPU de hoy.
4.1 Sistema de Pila
La arquitectura de la GPU define un conjunto de comandos de GPU para habilitar el
controlador de dispositivo y el motor de tiempo de ejecucin de espacio de usuario para
el control de las copias de datos y los lanzamientos del kernel. El controlador de
dispositivo proporciona primitivas para los programas de espacio de usuario para enviar
comandos GPU para la GPU, y el motor de tiempo de ejecucin de espacio de usuario
proporciona una API especfica para escribir programas de usuario, abstrayendo las
primitivas de bajo nivel en el controlador de dispositivo. Una llamada al sistema ioctl a
menudo se utiliza como interfaz entre el controlador y el motor de tiempo de ejecucin.
Comandos GPU diferentes instrucciones GPU de que ncleos cdigo GPU, y hay muchos
tipos de comandos de la GPU. El controlador de dispositivo enva comandos GPU para
manejar los recursos de la GPU, incluyendo contextos de la GPU y las unidades de gestin
de la memoria del dispositivo, mientras que el motor de tiempo de ejecucin genera
comandos de GPU para controlar los flujos de ejecucin de los programas de usuario, por
ejemplo, las copias de datos y los lanzamientos del kernel.
La Figura 3 ilustra la pila del sistema en nuestro modelo de gestin de los recursos de la
GPU. Las aplicaciones llaman a funciones de biblioteca de API que proporciona el motor
de tiempo de ejecucin. El extremo frontal del motor de tiempo de ejecucin depende del
marco de programacin, que transforma las llamadas a la API a los comandos de la GPU
que son ejecutadas por la GPU. El controlador de tiempo de ejecucin es la parte de atrs
del motor de tiempo de ejecucin que abstrae la interfaz ioctl en el controlador de
dispositivo, lo que simplifica el desarrollo de marcos de programacin. Optimizacin del
rendimiento del motor de tiempo de ejecucin puede ser unificada en esta capa. El
controlador de dispositivo es el responsable de la presentacin de los comandos de la
GPU, recibidas a travs de la llamada al sistema ioctl, a la GPU a travs del bus PCI.

4.2 Gestin de canales GPU
El controlador de dispositivo debe gestionar los canales de la GPU. El canal de la GPU es
una interfaz que sirve de puente a travs de la CPU y de los contextos de la GPU,
especialmente cuando el envo de comandos de la GPU de la CPU a la GPU. Se sujeta
directamente a la unidad de despacho dentro de la GPU, que pasa comandos GPU
entrantes a la computacin (o procesar) unidad en la que se ejecuta el cdigo de la GPU.
El canal de la GPU es la nica manera de enviar comandos GPU para la GPU. Por lo tanto,
los programas de usuario se deben asignar los canales de la GPU. Mltiples canales son
compatibles con la mayora de las arquitecturas de GPU. Por ejemplo, la arquitectura
Fermi de NVIDIA soporta 128 canales. Dado que cada contexto requiere al menos un canal
a utilizar la GPU, en la mayora de contextos 128 se les permite existir al mismo tiempo.
GPU canales son independientes entre s, y representan espacios de direcciones
separadas.
La figura 4 ilustra la forma de presentar los comandos de GPU para la GPU dentro de un
canal. El canal de la GPU utiliza dos tipos de tampones en el espacio de direcciones del
sistema operativo para almacenar comandos GPU. Uno de ellos es asignado en memoria
en el bfer de espacio de usuario, en el que el motor de tiempo de ejecucin de espacio
de usuario empuja comandos GPU. El otro tampn se utiliza directamente por el
controlador de dispositivo para enviar comandos GPU especficos que controlan la GPU,
tales como la inicializacin de estado, de sincronizacin del canal, y ajuste de modo.
Comandos GPU suelen agruparse en mltiples unidades, a menudo denominados grupos
de comandos de la GPU. No hay restricciones sobre la manera de componer grupos de
comandos de la GPU. Un solo grupo de comandos GPU puede contener slo un comando
GPU o nmeros en los miles, por lo que el espacio de memoria. Independientemente de
cuntos se presentan grupos de comandos de la GPU, la GPU los trata como ms que una
secuencia de comandos de la GPU. Sin embargo, el nmero de grupos de comandos GPU
podra afectar al rendimiento, ya que los comandos de la GPU en cada grupo se envan por
la GPU de forma rfaga. Los ms comandos GPU se incluyen en un grupo, se requiere
menos la comunicacin entre la CPU y la GPU. En cambio, podra causar el bloqueo de
larga duracin, ya que el controlador de dispositivo no puede adelantarse directamente
las ejecuciones de contextos GPU lanzadas por anteriores grupos de comandos de la GPU.
Mientras que el motor de tiempo de ejecucin empuja los comandos de la GPU en el bfer
asignado a la memoria, que tambin escribe los paquetes, cada uno de los cuales es un
(tamao y direccin) tupla para localizar el grupo de mando GPU correspondiente, en un
bfer de anillo especfico proporcionado en la memoria intermedia de sistema operativo,
a menudo referido como el bfer indirecto. El controlador de dispositivo configura el
comando unidad de despacho GPU para leer esta memoria cclica para tirar los comandos
de la GPU. Esta memoria cclica est controlada por GET y PUT punteros. Los punteros
empiezan desde el mismo lugar. Cada vez que los paquetes se escriben en el buffer, el
controlador del dispositivo se mueve el puntero del PUT a la cola de los paquetes, y enva
una seal a la unidad de mando de la GPU de despacho para tirar de los grupos de
comandos GPU localizados por los paquetes entre los punteros GET y PUT. Despus, el
puntero del GET se actualiza automticamente en el mismo lugar que el puntero del PUT.
Una vez que estos grupos de comandos de la GPU se presentan a la GPU, el controlador
de dispositivo no administra por ms tiempo, y simplemente sigue presentando la
siguiente serie de grupos de comandos de la GPU, si los hubiere. Como consecuencia de
ello, esta memoria cclica juega un papel de una cola de comandos para el controlador de
dispositivo.
Cada grupo de comandos GPU puede incluir mltiples rdenes de la GPU. Cada comando
GPU se compone de la cabecera y los datos. El encabezado contiene mtodos y el tamao
de los datos, mientras que los datos contienen los valores que se pasan a los mtodos.
Algunos mtodos son compartidos entre clculo y grficos, y otros son especficos de cada
uno. Ejecucin de comandos GPU est fuera de servicio dentro del mismo canal GPU, y los
canales de la GPU podran ser cambiados de manera implcita por la propia GPU. Cabe
sealar que el canal GPU es un camino para enviar comandos de GPU y algunas otras
estructuras para controlar la GPU. Imgenes del ncleo GPU y sus bferes de datos se
cargan en la memoria del dispositivo a travs del acceso directo a memoria (DMA),
mientras que la operacin de DMA en s es controlada por comandos de la GPU.
4.3 Gestin de Contexto GPU
Contextos GPU constan de registros de E / S asignados a la memoria y los registros de
hardware, que deben ser inicializados por el controlador de dispositivo desde el principio.
Si bien los registros de E / S mapeados en memoria se pueden leer directamente y por
escrito por el controlador de dispositivo a travs del bus PCI, registros de hardware de
GPU necesitan subunidades para ser ledo y escrito. Hay varias formas previstas para
acceder a los valores de contexto. La lectura y la escritura en la memoria mapeada
E / S de registros en la CPU es la forma ms sencilla, pero la comunicacin del bus PCI se
generan para todas las operaciones. La GPU proporciona alternativamente varias unidades
de hardware para transferir datos entre la memoria principal, la memoria del dispositivo,
y los registros de la GPU en modo rfaga.

La figura 5 muestra un modelo conceptual de la forma de gestionar el contexto GPU.
Generalmente, el contexto de la GPU se almacena en la memoria del dispositivo. Tambin
se podra almacenar en la memoria del host, ya que la GPU puede acceder tanto en el host
y la memoria del dispositivo, pero la memoria del dispositivo es muy recomendable
debido a problemas de rendimiento, es decir, la GPU tiene acceso a la memoria del
dispositivo mucho ms rpido que la memoria del host. La memoria del host se usa a
menudo para almacenar los datos de acceso de un solo uso, tales como la imagen del
programa de firmware de los microcontroladores. Algunas partes del contexto de la GPU
no son puede acceder directamente a la memoria del host. Transferencias DMA son
necesarias para gestionar estas partes del contexto de la GPU a travs de la
microcontrolador. Cabe sealar que el microcontrolador tambin contiene espacios de
memoria donde algunos datos accedidos por el contexto de la GPU se almacenan. Por lo
tanto, las transferencias de DMA son tambin necesarias para gestionar estos datos. La
GPU tiene muchos hardwares unidades distintas de la unidad de ejecucin, algunos de los
cuales son utilizados por el contexto de la GPU, pero no describe los detalles.
4.4 Gestin de la memoria
La gestin de la memoria para aplicaciones de GPU se asocia con al menos tres espacios
de direcciones. Teniendo en cuenta que un programa de usuario se inicia en la primera
CPU, la memoria intermedia de usuario se crea dentro de la memoria virtual de espacio
del usuario en la memoria del host. Este tampn se debe copiar en la memoria virtual del
sistema operativo, ya que el controlador de dispositivo debe acceder a ella para transferir
datos a la memoria del dispositivo. El destino de la transferencia de datos en la memoria
del dispositivo debe coincidir con el espacio de direcciones asignado por el programa de
usuario de antemano para el programa ncleo GPU correspondiente. Como consecuencia
de ello, hay tres espacios de direcciones asociados a la gestin de memoria: (i) la memoria
de espacio de usuario virtual, (ii) la memoria virtual del sistema operativo, y (iii) del ncleo
de la GPU de la memoria virtual.
La figura 6 muestra cmo copiar los datos de la memoria intermedia de usuario en la
memoria del host al bfer asignado en la memoria del dispositivo. El bfer de usuario
debe ser primera copia en el espacio de memoria virtual del sistema operativo accesible
para el controlador de dispositivo. Un bfer de memoria asignada se puede utilizar para
este propsito, que es soportado por el estndar POSIX como la llamada de sistema
MMAP. Una vez que el buffer est asignado a la memoria, el programa de usuario puede
usarlo bastante flexible. Otro enfoque para esta copia de datos es que el programa de
usuario se comunica con el controlador de dispositivo, el uso de las llamadas del sistema
de E / S, dado que la mayora de los sistemas operativos proporcionan una funcin para
copiar datos desde la memoria intermedia de usuario a la memoria virtual del sistema
operativo. La figura 6, sin embargo, asume el primer enfoque, que es adoptado por
Nouveau y PSCNV (y quizs driver propietario de NVIDIA). Una vez que la memoria
intermedia se copia en la memoria virtual del sistema operativo, el dispositivo controlador
transfiere al espacio de memoria del dispositivo asignado por el programa de usuario. Por
lo general, la GPU proporciona memoria virtual para cada canal de GPU para apoyar la
multitarea y la direccin de este dispositivo de memoria virtual es visible para el espacio
de usuario de modo que puede manejar a dnde enviar los datos para el clculo.
5 Sistemas Operativos Desafos
En esta seccin, consideramos los desafos de los sistemas operativos para la gestin de
recursos de la GPU. El siguiente anlisis se basa en nuestra experiencia y perspectiva de
investigacin favorita, y no cubre el rea completa de la gestin de recursos de la GPU. La
lista de desafos proporcionados en este documento debe extenderse a avanzar en la
investigacin ms sistemas operativos para la tecnologa de GPU. Sin embargo creemos
que el siguiente anlisis dar lugar a ideas de dnde estamos ya dnde ir.
5.1 GPU Scheduling
Programacin de GPU es tal vez el reto ms importante para aprovechar la GPU en
entornos multitarea. Sin programacin de GPU, los programas del ncleo de la GPU se
ponen en marcha en primer lugar en el primero en salir (FIFO), ya que la unidad de mando
GPU despacho tira grupos de comandos de la GPU en su orden de llegada. Por lo tanto, el
procesamiento de la GPU se convierte no preferente en sentido fuerte. La figura 7 ilustra
un problema tiempo de respuesta causado debido a la falta de apoyo de programacin de
la GPU, donde dos tareas con diferentes prioridades lanza cdigo GPU tres veces cada uno
como se muestra en la lnea de tiempo de CPU. El primer lanzamiento de la tarea de alta
prioridad es atendida de inmediato, ya que la GPU ha estado inactivo. Sin embargo, este
no es siempre el caso en entornos multitarea. Por ejemplo, la segunda y la tercera
lanzamientos de la tarea de alta prioridad son bloqueados por las ejecuciones anteriores
de contextos GPU lanzadas por la tarea de baja prioridad. Este problema aparece de
bloqueo debido a la naturaleza de FIFO de despacho. Por lo tanto, las tareas con el acceso
a la GPU necesitan ser programado adecuadamente para evitar interferencias en la GPU.
Concepto de diseo: El diseo de los planificadores de la GPU se divide en dos categoras.
Un mtodo implementa un planificador a nivel de controlador de dispositivo para
reordenar GPU grupos de comandos presentaciones, ya que las ejecuciones de los
contextos de la GPU son lanzados por los comandos de la GPU. Programadores GPU en el
estado de la tcnica [2, 17] estn diseados sobre la base de este enfoque. Por ejemplo,
TimeGraph [17] colas de grupos de comandos de la GPU en el dispositivo el espacio del
conductor, y configura el GPU para generar interrupciones a la CPU de la GPU en
terminaciones de cdigo GPU lanzada por grupos de comandos GPU anteriores a fin de
que el programador puede ser invocada para despachar los prximos grupos de comandos
de la GPU. Programacin de puntos son por lo tanto, crean en la GPU lmites del grupo de
comando. TimeGraph particularmente enva grupos de comandos de la GPU segn la
prioridad de las tareas, tal como se muestra en la Figura 8. La tarea de alta prioridad
puede responder de esta manera de forma rpida en la GPU mientras que la introduccin
de una sobrecarga adicional para el proceso de programacin. Se trata de un trade-off, y
se demostr que esta sobrecarga es inevitable para proteger las aplicaciones de GPU
importantes de la interferencia de rendimiento [16, 17]. Por desgracia, este enfoque
controlador de dispositivo todava sufre de la falta de carcter preventivo de
procesamiento de la GPU. En concreto, el controlador de dispositivo puede cambiar el
orden de los grupos de mando GPU presentaciones, pero no puede apropiarse
directamente contextos GPU. Por ejemplo, el ejemplo de la figura 8 muestra que el tercer
lanzamiento de la tarea de alta prioridad tiene que esperar a la finalizacin de la segunda
puesta en marcha de la tarea de baja prioridad. Para hacer que la GPU totalmente
preventiva, el cambio de contexto GPU debe ser apoyada a nivel micro, como se menciona
en [17]. El diseo e implementacin de tales microcontroladores firmware, sin embargo,
son cuestiones muy difciles. Algunas ideas podran extenderse a partir de granos de
satlite [27].Hay varios otros enfoques para la programacin de GPU. Como estudiado en
[8], el planificador de la CPU sigue siendo eficaz en el control de la ejecucin de la GPU, ya
que se puso en marcha el cdigo de la GPU de la CPU, y las interrupciones de la GPU se
reciben en la CPU. Como siempre, la gestin de recursos de la GPU est inevitablemente
grano grueso con este enfoque, debido al hecho de que el planificador de la CPU no tiene
conocimiento de las comunicaciones de comando de la GPU y los contextos de la GPU.
Tambin podemos utilizar en tiempo de compilacin y de aplicacin de programacin
enfoques [3, 10, 36], si las modificaciones y recopilaciones de programas, utilizando los
compiladores especficos, las API y algoritmos, son aceptables. La gestin de recursos de la
GPU en el nivel de controlador de dispositivo, por otro lado, es de grano ms fino, y no
hay necesidad de comprometer la generalidad de los marcos de programacin.
Programacin Algoritmo: Suponiendo que los planificadores de la GPU se proporcionan, la
siguiente pregunta es: qu programacin se desean algoritmos? Creemos que al menos
dos algoritmos de planificacin se requieren debido a la jerarqua de la CPU y la GPU. En
primer lugar, insistimos en que el algoritmo de planificacin de la CPU debe tener en
cuenta la presencia de la GPU. En particular para sistemas de tiempo real, algoritmos
plazos determinados clsicos, como Earliest Deadline First (EDF) [23], no son eficaces
como son.