| Arador | A continuación pasamos a la siguiente charla |
|---|
| Arador | damos paso a Martin Bligh, que nos va a hablar de VM y NUMA |
|---|
| Arador | Es uno de los autores del kernel 2.6 junto con Linus Torvalds |
|---|
| Arador | Trabaja en IBM. |
|---|
| Arador | La charla se traducira a español en #redes y a holandes en #taee |
|---|
| Arador | Preguntas y comentarios en #qc |
|---|
| Arador | Bienvenido, Martin |
|---|
| Arador | <mblight> Gracias - para mantenerlo en un limite de tiempo adecuado, voy a hacer algunas simplificaciones - nada demasiado importante, pero podeis preguntar si se me pasa algo |
|---|
| Arador | NUMA = non-uniform memory architecture = arquitectura de memoria no uniforme |
|---|
| Arador | en la que basicamente tenemos una máquina SMP con características no uniformes - cpus, memoria, y buses de E/S que no estan igualmente distanciados los unos de los otros |
|---|
| Arador | La razón para hacer esto es que es muy dificil (y caro) construir una maquina SMP plana de mas de 4 procesadores |
|---|
| Arador | una vez que empiezas a construir una máquina tan grande, tienes que empezar a desacelerar los buses del sistema, etc, para aguantar el tamaño |
|---|
| Arador | se puede conseguir una máquina mas grande, mas rápida, teniendo algunos recursos mas cercanos a unos que a otros |
|---|
| Arador | Si no haces esas decision, terminas con una máquina en la que *todo* se vuelve lento, en vez de solo unos pocos recursos |
|---|
| Arador | Normalmente definimos esas agrupaciones como "nodos" - una máuina tipica podría tener 4 cpus por nodo, y memoria local para cada procesador |
|---|
| Arador | con esa anticipación, hemos vendido sistemas NUMA por precios mucho mas bajos (2000$ o asi) |
|---|
| Arador | y hemos conseguido mucho mas interés en el mercado |
|---|
| Arador | A menudo, las máuinas que son ligeramente no-uniformes (ej: ligeramente NUMA) se venden como SMP por razones de simplicidad |
|---|
| Arador | las grandes máquinas de compañias como SGI ahora tienen 512 procesadores o más |
|---|
| Arador | Podría ayudar si se contemplara la máquina como un grupo de tipicas máquinas SMP, conectadas por una interconexion muy rápida |
|---|
| Arador | algo parecido a una conexión de red, excepto en que las transferencias que pasan por ese bus son transparentes para el sistema operativo |
|---|
| Arador | Sin duda, algunos sistemas previos fueron construidos exactamente así - el viejo hardware de Sequent NUMA-Q usa un chipset estándar 450NX 4x, con una interfaz NUMA "mágica" en el bus del sistema de cada nodo para interconectarlos, y pasar tráfico entre ellos |
|---|
| Arador | La medida tradicional para medir como de NUMA (como de no-uniforme) es una máuina es tomar un simple radio de la latencia de memoria de acceso a la memoria local contra la memoria remota |
|---|
| Arador | es decir si puedo hacer accesos a la memoria local (memoria en el mismo nodo que la CPU) en 80 ns, y un acceso remoto (cpu en un nodo diferente de la memoria) en 800ns, la relación se expresaría como 10:1 |
|---|
| Arador | Desafortunadamente, hace mucho mas dificil trabajar a la aplicación - toda la intercomunicacion y balanceado de carga ahora tiene que ser mas explicito, y mas complejo |
|---|
| Arador | algunas aplicacions grandes (ej: servidores de bases de datos) no se dividen en multiples nodos facilmente |
|---|
| Arador | en ese tipo de situaciones, la gente usa a menudo máquinas NUMA |
|---|
| Arador | Otro efecto beneficioso de usar una máquina NUMA es que los problemas de balanceado, etc, se resuelven una sola vez a nivel de sistema operativo, en vez de en cada aplicacion que tiene que funcionar sobre la máquina |
|---|
| Arador | Tambien abstraemos el conocimiento del hardware en el SO, de manera que las aplicaciones sean mas portables |
|---|
| Arador | hay varios niveles de soporte NUMA que podemos tener: |
|---|
| Arador | 1. Pretender que el hardware es SMP, ignorando la localidad y las características NUMA |
|---|
| Arador | 2. Soporte implícito - el SO intenta usar recursos locales donde sea posibnle, y agrupar aplicaciones y recursos relevantes tan cerca como sea posible |
|---|
| Arador | 3. Soporte explícito - proveer una API al espacio de usuario, donde la aplicación puede especificar (de una manera abstracta) al SO que quiere |
|---|
| Arador | En el kernel 2.6.0, estamos verdaderamente en el nivel 2. Tenemos algún soporte básico para algunas cosas del nivel 3. |
|---|
| Arador | El nivel 1 funciona, pero no tiene muy buen rendimiento |
|---|
| Arador | eso es lo que hice cuando porté por primera vez Linux a la plataforma NUMA-Q |
|---|
| Arador | El primer paso para dar soporte a NUMA es intentar asignar memoria local a las CPUs en las que la aplicación está ejecutandose. |
|---|
| Arador | hacemos eso por defecto en linux cuando el kernel lama a __alloc_pages (el principal asignador de memoria) |
|---|
| Arador | si nos quedamos sin memoria en el nodo local, automaticamente se asigna memoria de otro nodo, que es mas lento |
|---|
| Arador | el soporte de NUMA está activado por CONFIG_NUMA, que depende de CONFIG_DISCONTIGMEM |
|---|
| Arador | aunque la memoria en efecto podría no ser discontigua (como 'discontigmem' sugiere) - eso es simplemente histórico |
|---|
| Arador | Asique en vez de tener 3 zonas de memoria para el sistema (ej: ZONE_DMA, ZONE_NORMAL, ZONE_HIGHMEM), tenemos 3 zonas para cada nodo ... aunque muchas de ellas a menudo esten vacias (no tienen memoria en ellas) |
|---|
| Arador | Para cada página física de memoria en un sisztema linux tenemos una estructura 'struct page' de control, que agrupamos en un array llamado mem_map, que es un bloque contiguo de memoria |
|---|
| Arador | en sistemas NUMA, lo dividimos en un array por nodo (lmem_map[node]) |
|---|
| Arador | pero esencialmente todavía tenemos una estructura page por cada página de memoria |
|---|
| Arador | dividir ese array nos da varias ventajas - una de ellas es simplicidad en el código |
|---|
| Arador | otra es que podemos asignar esas estructuras de control de la propia memoria de los nodos mejorando los tiempos de acceso |
|---|
| Arador | En un sistema tipico, podriamos tener 16 GB de RAM, y 4 nodos (cada nodo tiene 4 GB de memoria) |
|---|
| Arador | eso finaliza con rangos de direcciones físicas de 0-4GB en el nodo 0, 4-8 en el nodo1, 8-12 en el nodo2, y 12-16 en el nodo 3 |
|---|
| Arador | en un sistema de 32 bits, eso representa un pequeño problema - toda la memoria permanente del kernel se asigna del primer GB de memoria física |
|---|
| Arador | desafortunadamente, eso es bastante dificil de arreglar - muchos drivers asumen que la direccion física para la memoria del kernel (ZONE_NORMAL) cabe en un unsigned long (32 bits) |
|---|
| Arador | asique no podemos expandir fácilmente esa memoria por el sistema ... ese es un problema de rendimiento que aun tenemos |
|---|
| Arador | Alguans cosas (ej los arrays lmem_map) se relocalizan con unos trucos especiales en tiempo de carga, pero la mayoría de las estructiras (ej: entradas para el dcache, y el cache de inodos) residen todos en el nodo 0 todaia |
|---|
| Arador | Una de las cosas que hacemos para reducir el tráfico entre nodos se que en vez de un solo demonio global de swap (kswapd) para hacer reemplazo de páginas, tenemos un demonio por nodo, cada uno escaneando las páginas de su nodo |
|---|
| Arador | eso nos da mucho mejor rendimiento, y menor trafico de itnerconexión durante el reemplazo de memoria |
|---|
| Arador | tambien podemos replicar copias de datos de solo lecura a cada nodo |
|---|
| Arador | por ejemplo, podemos copiar el kernel binario a cada nodo, y tener las cpu en cada nodo solo mapeando su propia copia local - esto solo usa un pequeño extra de memoria y evita un monton del ancho de banda de interconexion |
|---|
| Arador | Dave Hansen ha creado tambien un parche para replicar los datos de usuario de solo lectura (ej: el texto de la libc, y programas como gcc) en cada nodo, que tiene un beneficio similar |
|---|
| Arador | eso nos da de un 5% a un 40% de incremento de rendimiento, dependiendo de que parches estemos usando con el, y de que benchmark |
|---|
| Arador | replicar los datos de lectura y escritura sería dificil (mantener varias copias sincronizadas en escritura) y probablemente no merece la pena |
|---|
| Arador | la VM del 2.6 tambien tiene listas LRU (las listas usadas menos recientemente de las que se han accedido recientemente páginas de memoria) por cada nodo |
|---|
| Arador | en vez de una lista global |
|---|
| Arador | no solo nos da un acceso mas localizado a la información, sino que tambien nos permite romper el pagemap_lru_lock |
|---|
| Arador | que es el bloquedo controlando las listas LRU - antes de que rompieramos eso, nos pasabamos el 50% del tiempo del sistema durante la compilacion del kernel solamente en ese bloqueo |
|---|
| Arador | una vez roto, el tiempo es tan pequeño que es inmedible |
|---|
| Arador | OK... esa es la mayor parte de las grandes cosas de la VM...ahora viene el gestor de procesos |
|---|
| Arador | no tiene mucho sentido en asignar memoria local al nodo a un proceso si el proceso migra instantaneamente a otro nodo |
|---|
| Arador | asique cogimos el scheduler O(1) en el 2.6, y lo modificamos |
|---|
| Arador | con el scheduler O(1), hay 1 lista de tareas por cada cpu |
|---|
| Arador | en el modo SMP plano, cada cpu ejecuta las tareas de su propia lista, y ocasionalmente las balanceamos entre diferentes listas |
|---|
| Arador | pero en un sistema NUMA, no queremos migrar los procesos si es posible |
|---|
| Arador | queremos dejarlas en el nodo local - para conservar los caches calientes y la memoria local |
|---|
| Arador | Asi que cambiamos el algoritmo de balanceo estándar para que balanceara solamente entre las listas de las cpus de un mismo nodo |
|---|
| Arador | y añadimos otro algoritmo de balanceo, que es mucho mas conservativo, para balancear procesos entre nodos |
|---|
| Arador | Asi que rara vez balanceamos entre nodos |
|---|
| Arador | Sin embargo, en el momento del exec() de un proceso, el proceso tiene muy poco estado (efectivamente le hemos dicho que lo sobreescriba con un nuevo proceso) |
|---|
| Arador | asi que en el tiempo de ejecucion, tambien hacemos un rebalanceado entre nodos, y ponemos el proceso ejecutado en el nodo menos cargado |
|---|
| Arador | eso hace mucho balanceado por nosotros, y es libre de hacerlo |
|---|
| Arador | el codigo que hay en 2.6 para soportar el gestionado de procesos NUMA es todaia muy simple, y necesita mucho trabajo |
|---|
| Arador | mi principal plan para el futuro es conservar los estados de RSS (resident set size de emoria) de cada proceso tanto en cada nodo como global |
|---|
| Arador | entonces podemos usar esa informacion para hacer mejores decisiones - si la mayoría de la memoria de un proceso está en el nodo X, deberíamos intentar migrar ese proceso al nodo X |
|---|
| Arador | para conseguir buen rebalanceo, tambien queremos tener en cuenta cuanta CPU está usando - va a tener mas efecto rebalancear una tarea si está usando ams CPU |
|---|
| Arador | pero es mas barato migrar si utiliza mucho menos cache (que medimos aproximadamente con el RSS) |
|---|
| Arador | Asique terminamos con un calculo para la migracion que es algo como "porcentaje de la cpu/ (rss remoto - rss local)" |
|---|
| Arador | ok...suficiente scheduler...ahora un poco de ES |
|---|
| Arador | si tenemos un SAN (area de red de almacenamiento) con una conexion E/S en el desde cada nodo (ej: fibra) |
|---|
| Arador | entonces tiene sentido usar MPIO (multi-path IO) que este al corriente de NUMA |
|---|
| Arador | simplemente intentamos enrutar el trafico IO sobre la interfaz IO local, y recibir el trafico en esa misma interfaz |
|---|
| Arador | eso obviamente curta un monton de trafico sobre la interconexion principal |
|---|
| Arador | Sin una interfaz debería morir en el nodo loca, siempre podemos acabar usando el adaptador IO de otro nodo remoto en su vez |
|---|
| Arador | por otro lado, muchas maquinas (especialmente las maquinas AMD64) no tienen este tipo de configuracion |
|---|
| Arador | en contra, la mayoría del IO solamente se conecta a un nodo |
|---|
| Arador | para encajar bien con eso, necesitamos de verdad retocar el gestor de procesos, y ejecutar las tareas que necesiten IO en el nodo mas cercano a los recursos IO que esten accediendo |
|---|
| Arador | y ejecutar las tareas que usen CPU, etc en otros nodos |
|---|
| Arador | todavia no tenemos soporte para eso en Linux, pero lo podriamos añadir facilmente durante 2.6 |
|---|
| Arador | Oh, y los mismos principios se aplican aqui para ES de redes y ES de disco |
|---|
| Arador | aunque el ES de red es un poco mas complejo, porque tenemos que saber que hacer para cada direccion IP para la máquina, etc |
|---|
| Arador | La única seccion que me queda por cubrir es tocar un poco las APIs de espacio de usuario |
|---|
| Arador | lo que referi antes como "nivel 3" |
|---|
| Arador | presentarmos alguna informacion de la topología de la maquina numa por sysfs |
|---|
| Arador | ej: los grupos de que cpus estan en que nodo (y que nodos contienen que cpus) |
|---|
| Arador | tambien presentaremos informacion de memoria en base a los nodos (a la /proc/meminfo) |
|---|
| Arador | de maneras que se peuda monitorizar cuanta memoria libre/asignada hay en que nodo, y que se se ha asignado |
|---|
| Arador | tambien hay mapeos para que buses PCI estan en que nodo |
|---|
| Arador | y unos parches fuera del arbol que permiten a los usuarios especificar de que nodo debería asignarse memoria (aun no terminado, pero lo estará en los proximos meses) |
|---|
| Arador | Andi Kleen y Matt Dobson setan trabajando en eso |
|---|
| Arador | podemos usar sys_sched_affinity de Robert Love para signar procesos a CPUs especificas, y por lo tanto a nodos |
|---|
| Arador | Ok....preguntas? |
|---|
| Arador | <sydb> si cuando estes tomando preguntas: Estoy interesado en saber como el Numa de Linux se compara con otros SOs propietarios (eJ: AIX)...tambien, es NUMA una excusa mientras que el SMP real escala de forma barata? Quien está usando NUMA Linux y porque? |
|---|
| Arador | Creo que la principal diferencia entre SOs como AIX y PTX de Sequent (en terminos de soporte te NUMA) es que no tenemos mucha de las cosas de espacio de usuario hechas |
|---|
| Arador | no estoy tan seguro de que sea tan importante como las cosas específicas - tenemos que portar grandes aplicaciones como DB2 y Oracle para que lo usen |
|---|
| Arador | preferiría que el SO hiciera buenas decisiones para las aplicaciones donde fuera posible |
|---|
| Arador | el asunto de la gestión de procesos en otros SOs es probablemente tambien ams sofisitcada |
|---|
| Arador | necesitamos hacer mejores cosas como agrupaciones de tareas - ejecutar threads del mismo proceso en el mismo nodo, donde sea posible |
|---|
| Arador | en referencia a que NUMA sea una excusa mientras que SMP scala... |
|---|
| Arador | no, realmente no - hay cuestiones fundamentales que lo hacen imposible |
|---|
| Arador | cuando mas grande se hace el bus (mas cpus y mas memoria), simplemente no lo puedes ejecutar tan rapido |
|---|
| Arador | eso es fisica...no podemos hacer mucho ahi ;-) |
|---|
| Arador | asique termianmos dividiendolo en pequeños buses, y los interconectamos |
|---|
| Arador | ...quien está usando Linux NUMA y porque? |
|---|
| Arador | principalmente gente que tiene grandes maquinas como servidores de bases da datos - hemos vendido muchas de nuestras plataformas x440 (basado en ia32) |
|---|
| Arador | es una manera de conseguir una maquina grande con un coste efectivo |
|---|
| Arador | aunque sería mucho mas fácil de programar si tuvieramos chips de 64 bits ;) |
|---|
| Arador | <sydb> hay la suficiente gente trabajando en NUMA en Linux para alcanzar a la competición? Merece la pena incluir a tanta gente? |
|---|
| Arador | primero, linux no tiene competición ;-) |
|---|
| Arador | Pero seriamente...en verdad no, . Necesitamos a gente que lo pruebe en diferentes arquitecturas |
|---|
| Arador | Me gustaría ver mas trabajo en AMD, especialmente por el scheduler |
|---|
| Arador | en un sistema con una cpu por nodo, el concepto de migrar tareas "dentro" de un nodo tiene sentido |
|---|
| Arador | Erich Fotch tiene parches para arreglarlo ... pero han estado ahi durante tres meses o asi y nadie los ha probado. Triste. |
|---|
| Arador | <sydb> ¿Puedes hacer NUMA con hardware no NUMA (emulado o por ethernet) para abrir el desarrollo? |
|---|
| Arador | <sydb> lol |
|---|
| Arador | En verdad no - parte de lo que realmente es complejo sobre NUMA es hacer una maquina que pueda hacer un acceso *transparente* la memoria remota Y conservar los caches coherentes |
|---|
| Arador | estoy muy interesado en lo que se llama clustering SSI - "single system image clustering" - eso es una sola imagen de SO ejecutandose a traves de un cluster tradicional |
|---|
| Arador | sin embargo, es un problema MUY dificil de solventar bien ;-) |
|---|
| Arador | <athkhz> Que tal anda NUMA en otras arquitecturas como PPC970? |
|---|
| Arador | No hay maquinas NUMA del PPC970 que yo conozca |
|---|
| Arador | pero me gustaría ver una - sería una gran aqruitectura ;-) |
|---|
| Arador | Mandame una cuando la hagas |
|---|
| Arador | Sin embargo...el PPC970 es la hermana pequeña de del POWER4+ |
|---|
| Arador | el Regatta (P690) es del hardware de mas alto nivel de IBM, y es NUMA |
|---|
| Arador | no se vende comO NUMA, pero lo es |
|---|
| Arador | asique...ya casi tenemos lo que quieres :-) |
|---|
| Arador | <clsk> Cual es tu opinion personalsobre microkernels vs macrokernels? (perdon si es muy offtopic) |
|---|
| Arador | Tengo practicamente la misma opinion que Linus - los microkernels son bonitos, pero muy ineficientes el la practica. Los kernels convencionales funcionan SI ejecrcitas buenas disciplinas de programacion |
|---|
| Arador | Es un poco como la programacion OO - intenta forzarte en un modelo estricto, pero *puedes* escribir codigo muy bien modularizado en C si lo intentas |
|---|
| Arador | <Arador> ¿Porque se dice que los athlones son un pequeño sistema NUMA? |
|---|
| Arador | Creo que tiene dos sentidos...pequeños en lo que se refiere a que normalmente tienen pocas CPUS (la interconexion solo puede ser como mucho 8x al menos que alguien haga un switch) |
|---|
| Arador | y pequeño porque tienen un ratio de latencia de acceso a la memoria (como se describi antes) |
|---|
| Arador | NUMA-Q es 10:1... x440 es 4:1 ... x86_64 es sobre 1.6:1 a 2.5_1 dependiendo de como sea de grande el sistema |
|---|
| Arador | <pepita> tiene algo que ver openmosix? |
|---|
| Arador | supogno que te refieres al tema de SSI - si. Openmosiz es una implementacion de SSI |
|---|
| Arador | tambien está OpenSSI, Aunque no me gusta ninguna de las dos ;-) |
|---|
| Arador | <sydb> cuanto menor sea el ratio, mejor no? |
|---|
| Arador | Hablando breve...si |
|---|
| Arador | Sin embargo, como Sun ha mostrado en el pasado...podemos conseguir 1:1 simplemente enlenteciendo el acceso local |
|---|
| Arador | el objetivo de NUMA no es darte memoria remota mas lenta - es darte acceso local *mas* rapido |
|---|
| Arador | Preferiria un local:remoto de 80ns:160ns a uno de 120ns:150ns, aunque los ratios en el ultimo parezcan mejor |
|---|
| Arador | <pepita> porque no te gusta los clusteres SSI? Que tienen de malo? |
|---|
| Arador | Me *gustan* los clusteres SSI en general...pero no sus implemetnaciones ;-) |
|---|
| Arador | mucho codigo invasivo reescrito... |
|---|
| Arador | demasiado rebalanceo entre nodos, en algunas implementaciones. Es un tema muy largo para adentrarse ;-) |
|---|
| Arador | <clsk> Armadillo pregunta: NUMA es que tipo de interconextor en una red hipercubica y que tipo de protocolos de red especiales usa, o se gestiona todo por el hardware? |
|---|
| Arador | no hay una interconexion especifica usada.... los NUMA-Qs con los que trabajo suelen funcionar con algo llamado SCI |
|---|
| Arador | pero absicamente, es todo transparence y gestionado por el hardware, asique al SO no le importa mucho |
|---|
| Arador | podrías usar ethernet como transporte si se necesitara |
|---|
| Arador | Pero necesitarias mucho mas que un dispositivo ethernet standard para hacer acceso a memoria remoto y coherencia de cache ;-) |
|---|
| Arador | Dejaré terminar a los traductores ;-) OK...eso es todo amigos ;-) |
|---|
| EMPE[log] | plas plas plas plas plas plas plas |
|---|
| EMPE[log] | plas plas plas plas plas plas plas |
|---|
| krocz | Gracias Arador |
|---|
| EMPE[log] | BRILLANTE Arador |
|---|
| EkInOxIo | wow !!! |
|---|
| EMPE[log] | te la comistes entera |
|---|
| krocz | CLAP CLPA CLAP |
|---|
| EMPE[log] | :D |
|---|
| EkInOxIo | Arador , Gracias !!!! |
|---|
