| Arador | de acuerdo, vamos a empezar |
|---|
| Arador | bienvenidos una vez mas a UMEET 2003 |
|---|
| Arador | un lugar para saber mas y entender el sistema Unix |
|---|
| Arador | Como siempre, la charla será aquí, en este canal que hemos preparado |
|---|
| Arador | en el canal #redes un grupo de voluntarios traducira del ingles a español |
|---|
| Arador | y recuerdo que las preguntas son en #qc |
|---|
| Arador | Hoy, nuestro proximo conferenciante es WIlliam Lee IRwin III de los estados unidos |
|---|
| Arador | Contribuye al kernel linux y es mantenedor de paquetes de debian y esta certificado en el nivel Master |
|---|
| Arador | William Lee irwin III, aka "wli" es uno de los desarrolladores que ayudó a implementar la caracteristica de mapeo inverso en el kernel Linux |
|---|
| DMN | Mr Irwin ha estado con nosotros en cada congreso y es licenciado en ciencias de la universidad de Purdue, donde yo me magistre en matematicas y ciencias de la computacion |
|---|
| DMN | El va a hablar de Que es PGCL? asi que.. |
|---|
| DMN | Wli empieza la presentacion... |
|---|
| DMN | Wli... |
|---|
| DMN | Me gustaria introducir el parche "pgcl" y dar a entender que es esto, que es muy util, y una idea de alto nivel de como funciona |
|---|
| DMN | Primero "pgcl" es una abreviacion de "page clustering" "Clustering de paginas" "Agrupacion de paginas o como lo querais llamar". Lo he llamado asi porque es un precedente a la idea de los antiguos sistemas operativos, pensando que ellos nunca han sido implementados en algunos de sus aspectos ( Supongo que se refiere al parche ) |
|---|
| Arador | segundo, es esencialmente un port del parche "larpage" de Hugh Dickins a 2.6. Sin embargo, mucho del contenido original choca con problemas específicos del 2.6, y debido a lo invasivo de los cambios necesitados, no era posible usar nada del viejo codigo para actualizarlo, algunas veces incluso reescrituras del algoritmo |
|---|
| Arador | Hay dos componentes importantes de pgcl |
|---|
| Arador | el primero es cambiar la definicion de una "página", y hacer una nueva distinción entre las páginas que el kernel usa para asignar y las páginas que usa el hardware de la cpu para la traduccion de las direcciones |
|---|
| Arador | en pgcl, PAGE_SIZE ahora representa lo que el asignador devuelve para una asignación de orden-0, y lo que la estructura página describe |
|---|
| Arador | hay otra noción de tamaño de página, MMUPAGE_SIZE, usada por la VM y el código específico de máquina, que describe como de grande se mapea una entrada en la tabla de páginas y se usa a menudo para interpretar las descripciones del hardware |
|---|
| Arador | Esos dos tamaños están relacionados, y PAGE_SIZE tiene que ser un multiplo potencia-de-dos de MMUPAGE_SIZE |
|---|
| Arador | Hay un segundo componente de pgcl que lo hace diferente de los precedentes en otros viejos sistemas operativos |
|---|
| Arador | es el de que pgcl "preserva la ABI". Para explicar lo que significa esto, describire que hacía un sistema operativo que acuñaba el termino "Page clustering" (clustering de paginas) y comparar las diferencias del espacio de usuario vistas en ellos y en pgcl |
|---|
| Arador | BSD, vuando se porto originalmente a los VAX, se ejecutabe en máquinas con muy poca memoria |
|---|
| Arador | el VAX no era diferente en ese aspecto, pero tenía páginas de 512B, que creaban muchos problemas con respecto al tamaño de memoria que ocupaba |
|---|
| Arador | BSD usaba una estructura de 16B para cada página, llamada cmap_t (analoga a la "struc page' de Linux), y usar una por cada 512B de ram era muy caro |
|---|
| Arador | Asique se agruparon las páginas hardware y pretendieron que esa era el tamaño de la página |
|---|
| Arador | Se hizo una distinción entre las dos nociones de página, usando macros con nombres similares a PAGE_SIZE y MMUPAGE_SIZE |
|---|
| Arador | De hecho, esto sobrevive hoy en dia en algunos BSDs libres |
|---|
| Arador | Pero esto tenía un efecto en el espacio de usuario. El espacio de usuario antes del cambio podía hacer mmap con una frontera de 512B |
|---|
| Arador | pero para ejecutar ese cambio, tenía que ser recompilado con una frotnera (limite) de 2KB o 4 KB |
|---|
| Arador | Esto es donde el trabajo de Hugh Dickins, y por lo tanto pgcl, son sustancialmente diferentes. EN vez de usar PAGE_SIZE en todos los lados en la VM, le enseña cosas que miran a las tablas de páginas para permitir hacer mmap() y hacer fallos de página a porciones de la idea de pagina del kernel |
|---|
| Arador | mmap() no es dificil de entender. SImplemente divide numeros por MMUPAGE_SIZE en vez de PAGE_SIZE |
|---|
| Arador | La gestión de los fallos de página esta muy envuelta en esto. Los manejadores de fallos encuentran una tabla de páginas y el offset alineado a MMUPAGE en el archivo al que corresponde el fallo de página |
|---|
| Arador | ahora hay que enseñarles para que usan el resto de fragmentos de la página dimensionados a MMUPAGE_SIZE de manera que no gasten memoria |
|---|
| Arador | Hay una noción que hace algo como faultahead "fallar mas adelante". En faultahead, encuentras entradas adyacentes para rellenar cuando una falta llega en la espera de que puedas evitar fallos de página en el espacio virtual cercano |
|---|
| Arador | En pgcl, esto es casi un requerimiento, al menos para la memoria anónima. O podría considerarse un requerimiento de rendimiento |
|---|
| Arador | Despues de todo este esfuerzo, pasa algo maravilloso. Los beneficios (que no he describirdo todavía) no tienen coste |
|---|
| Arador | El espacio de usuario no puede ver ninguna diferencia en absoluto cuando hace mmap |
|---|
| Arador | las aplicaciones no tienen que recompilarse de manera que sus secciones (datos, datos de solo lectura, etc) caen en los limites del PAGE_SIZE por software del kernel |
|---|
| Arador | Esto es muy importante para aplicaciones antiguas y para la flexibilidad en la eleccion de PAGE_SIZE, dado que hay que elegir algunos limites para enlazar ejecutables |
|---|
| Arador | asique ahora que sabemos lo que está haciendo pgcl, vamos a ver lo que trata conseguir |
|---|
| Arador | Originalmente, el antiguo analogo de pgcl BSD se usaba para reducir el tamaño en memoria del kernel. pgcl tambien se puede usar para eso |
|---|
| Arador | dado que las estructuras que toman nota de las páginas son mas grandes, hay menos de ellas |
|---|
| Arador | la estructura de página de Linux es grande. Es 40B en máquinas de 32 bits y 80B en las de 64 bits. Algunas veces mas, dependiendo de algunas opciones de arquitecturas específicas |
|---|
| Arador | Esto es 2.5 MB en una máquina con 256 MB, y 5 MB en una máquina de 64 bits con la misma cantidad de RAM |
|---|
| Arador | (asumiento un tamaño de PAGE_SIZE de 4KB como en el kernel principal) |
|---|
| Arador | En algunas máquinas, como las máquinas ia32 PAE, el espacio para estas estructuras de páginas es constante, mientras que la memoria total puede ser muy grande |
|---|
| Arador | Esto significa un tamaño muy grande en memoria en terminos absolutos, aunque en terminos relativos solamente es un 1% |
|---|
| Arador | Asique, para recuperar megabytes de espacio de swap, se puede usar pgcl |
|---|
| Arador | sin embargo, el objetivo de 2.4 tenía objetivos muy differentes |
|---|
| Arador | En Linux, muchos sistemas de ficheros están basados en bloques, y usamos una API del core basada en estructuras describiendo el estado IO de los fragmentos de páginas llamados buffer_heads |
|---|
| Arador | Esas estructuras solo pueden describir un estado IO (IO en progreso, IO completo, IO no hecho, etc) de trozos de memoria mas pequeños que el tamaño de página del kernel o igual a el |
|---|
| Arador | Hay un deseo general de usar bloques tan grandes como sea posible para limitar el número de peticiones de IO y de búsquedas entre las diferentes áreas del disco |
|---|
| Arador | La razón de esto es que con bloques más grandes, el IO de un área de un archivo está cubierto por un pequeño numero de áreas en el disco, asique la unidad no tendrá que esperar a rotar el plato para conseguir elsiguiente dato. |
|---|
| Arador | O al menos no tanto |
|---|
| Arador | Ahorabien el uso de la API que asume que los bloques deben ser mas pequeños que las páginas es un obstaculo para esto |
|---|
| Arador | La aproximación que toma pgcles hacer mas grande la noción del tamaño página del kernel, y entonces los bloques pueden ser tan grandes como ese tamaño |
|---|
| Arador | Me han dicho que el valor es menor, pero tambien tiene el beneficio de que puede leer sistemas de ficheros de tamaños de bloque mas grandes con tamaños de pagina mas pequeños que ese tamaño de bloque |
|---|
| Arador | otro beneficio es algo que mencione antes, "faultahead" |
|---|
| clsk | Mientras los programas tocan la memoria que han pedido mediante mmap(), ellos solo fallan lo suficiente para caber en una entrada de tabla de page (paginas) al mismo tiempo en la linea principal |
|---|
| clsk | los Cpus han estado creciendo rapidamente para lineas consecutivas de ejecucion, pero cosas como jumps (saltos) y ejecuciones han estado creciendo en su costo relativo para ejecuciones de lineas consecutivas |
|---|
| clsk | Cada fallo para llenar en un pte es una de esa excepciones la cuales han estado creciando progresivamente para controlarlas |
|---|
| clsk | Esto no fue originalmente citado como un beneficio, pero como alguien que generalmente sigue lo que VM está haciendo, yo e traceado las cuentas de fallas para varios programas mientras se ejecuta. pgcl reduce significativamente el numero de fallas tomadas. |
|---|
| clsk | Todavia hay otro beneficio, analogo a faultahead (fallos adelantados), el cual es muy natural predecir. |
|---|
| clsk | Las paginas son matenidas en varios sitios como el LRU, el radix de arboles pagecache, la lista por nodos, y VM y los algoritmos de sistemas de archivos hacen busquedas y interactan sobre estas estructuras. |
|---|
| clsk | Esto puede tomar muchas de estas estructuras de paginas linkeadas en estas estructuras para representar una cantidad de RAM, el cual los puede hacer muy profundo. |
|---|
| clsk | Por ejemplo, la raíz del arbol tiene una ramificacion de factor de algo como 64 |
|---|
| clsk | Para representar toda la memoria "cached" por un archivo de 32MB, esto requiere una raiz de arbol de nivel 3 en la linea principal. |
|---|
| clsk | Con un PAGE_SIZE de 64KB, esto solo requeriria 2 niveles. |
|---|
| clsk | Durante un writeback (escribir recursivamente) digase, mediante fsync(), la lista de todas las paginas ligados a un nodo es caminada por encima de esta |
|---|
| clsk | Con un PAGE_SIZE de 4kb, un archivo de 32MB tendria que caminar por encima de 8192 paginas. |
|---|
| clsk | Pero con un PAGE_SIZE de 64KB esto se reducido a un factor de 16 a 512. |
|---|
| clsk | Entonces, ahora que e describido todos los beneficios esperados, que he sacado de todo esto? |
|---|
| clsk | La respuesta es basicamente el camino todavia esta en un estado muy inmaduro. |
|---|
| clsk | Todavia tiene problemas de estabilidad corriendo en algunas marcas, y hay malos algoritmos que necesitan ser reemplazados. Pero, sin embargo, hay buenas noticias. |
|---|
| clsk | Algunas versiones, alrededor de 2.5.74 y 2.5.65, tiene mejor performancia que las lineas principales en tiobench; la razon por la cual esto no se a mantenido necesita investigacion algun tiempo despues que el problema de la estabilidad haiga sido solucionado. |
|---|
| clsk | El parche original mejoro la performancia en una marca simulando un load multiusuario por un 5 porciento |
|---|
| clsk | Los beneficios de las marcas de memorias han sido bien demostrados. Han sido bien portados a algunas maquinas ia32 PAE, y resultados demostrando que mejora la escalabilidad (los recursos) de PAE han sido posteado a lkml. De hecho, el primer anuncio hecho de una maquina de linux corriendo en una maquina 64HB ia32 corriendo en linux, y tambien haciendo esto en manera usable. |
|---|
| clsk | Entonces, en resumen, pgcl es una manera de sacar un factor constante de un lijero cabello de todo algoritmo en el VM sin costo con terminos de ABI. Yo estoy mirando hacia el futuro para traerlo a un estado donde es generalmente usable proximamente. |
|---|
| clsk | performancia = rendimiento |
|---|
| EMPE[log] | plas plas plas plas plas plas |
|---|
| Arador | acabo la traduccion |
|---|
| EMPE[log] | plas plas plas plas plas plas |
|---|
| EMPE[log] | plas plas plas plas plas plas |
|---|
| EMPE[log] | plas plas plas plas plas plas |
|---|
