21 de diciembre de 2009

¡ADSL!

Si, hamijos, yo todavía era usuario de módems de 56 KB: es decir, de 5 KB/s. Por fin ha llegado a mi casa el ADSL. Naturalmente, ya había probado el ADSL en otros sitios, y sabía lo que era, pero nunca lo había podido tener en mi ordenador personal.

Usar una línea de 56 KB a día de hoy acaba desarrollándote una serie de manías, o más bien técnicas de supervivencia. Por ejemplo, para conectarte a una red MSN -lo cual tomaba más de medio minuto, a diferencia de las redes Jabber, cuyo login es instantáneo- tenía que paralizar el resto de tráfico de red: Descargas, actualizaciones, cargas de página, etc. Y cuando volvías a reiniciar las descargas, no era raro que te desconectaras automáticamente por dios vaya a saber qué timeout. Para navegar por Internet en general los 56 KB eran suficientes, pero hay que evitar imágenes -pulsando Escape- y flash pesado para que así puedan terminar de cargarse otras. Y mientras se cargaban, tenías que paralizar las descargas si querías verlas en tiempo razonable o si no querías que llegara algún timeout. Todo esto crea una serie de manías y hábitos, arranques y paradas constantes de todo tipo de programas-. Por supuesto, poco, muy poco youtube. Y casi nada de P2P. Y las actualizaciones de las distros podían tardar semanas de ser grandes (entre parada y rearranque de la descarga se perdía mucho tiempo).

El cambio a ADSL, a pesar de llevar solo unas horas, está provocando que redescubra Internet. De repente, puedo escuchar radio por internet, descubrir qué es eso de los podcasts, tener un programa de P2P abierto con el que robar a George Lucas mientras hago cualquier otra cosa, permitir que Kopete se conecte automáticamente sin tener que preocuparme de si hay algo abierto o no. Acostumbrado como está uno a la paciencia que se desarrolla con los 56 KB, el ADSL le excita a uno excesivamente los sentidos. Pero hasta eso lo puede solucionar uno fácilmente visitando Youtube y viendo cualquier video de Serrat, que tiene la virtud de serenar a la gente.

Asi que si son ustedes pacededores de los 56 KB -según Google analytics, 141 visitaron este blog en el último mes- les sugiero que tengan paciencia y confien en el FSM, pero no esperen que siga compartiendo su sufrimiento.

18 de diciembre de 2009

El culebrón MySQL

El asunto de la compra de Sun y el entorpecimiento de la transacción por parte de la Comisión Europea ha dado lugar a una pequeña telenovela que, aunque está a puntito de acabarse, ha dado mucho juego. Los dos últimos capítulos han sido la petición pública de 'Monty', uno de los creadores de MySQL para impedir la adquisición por poner el futuro de la base de datos en duda (aun teniendo en cuenta la posibilidad de forks), y el compromiso posterior anunciado por Oracle de seguir mejorando MySQL (que no contenta al tal Monty, pero muy probablemente contente a la CE).

Yo ya afirme aquí que las reticencias de la CE ante la compra era absurdas, que el hecho de que MySQL sea software libre impide que pueda ser asesinada. Cierto que pueden crear dificultades, pero ¿impedir que MySQL siga existiendo de una u otra forma? Nunca. Sin embargo, eso no impide que esté tan ciego para no comprender los miedos del tal Monty y de la CE.

Oracle es una empresa que en gran medida basa su negocio en vender licencias de su base de datos propietaria. Es obvio que Oracle no va a tener ningún interés en regalar gratis algo que compita con su gallina de los huevos de oro, mientras que la anterior MySQL y Sun si que lo tenían. No esperen que Oracle ponga muchas ganas para matarse a sí misma. Hay empresarios estúpidos que han asesinado empresas debido a su incompetencia, pero Ellison no es de los que se dejan matar, sino de los que matan. De momento, tengan muy en cuenta que todas esas promesas que ha hecho Oracle incluyen al final del texto, como quien no quiere la cosa, que solo son válidos durante cinco años. Ya veríamos que es lo que pasa tras esos cinco años.

Pero es que ni tan siquiera durante ellos me fiaría en absoluto de Oracle, veremos lo que queda de la promesa una vez que la EC de visto bueno y se haya llevado a cabo la transacción y los ojos de los reguladores fijen su vista en otros asuntos. Es muy posible que hagan un gran trabajo con Java y OpenSolaris, pero con MySQL yo no tengo ninguna razón para creer que vayan a permitir que evolucione rápidamente. Mírense en el espejo y pregúntense, ¿que harían ustedes en lugar de Oracle? Reconózcanlo: aprovechar el control del proyecto para dificultar su evolución, con un control mucho mayor del que hubiera tenido si no hubieran comprado Sun. Si no harían eso es que, al igual que a mi, no les queda bien el traje de tiburón empresarial .

Y no me contento con eso de que MySQL y Oracle son dos mundos totalmente diferentes. Aunque ciertamente es un hecho muy popular e indiscutible que como base de datos MySQL está a años luz de Oracle, eso no significa que no pueda haber competencia. Hace nueve años e incluso menos, Linux era -hoy podemos decirlo bien alto ;)- una puñetera mierda, un kernel cutre, lento e inestable, incluso frente a NT, que la gente usaba solo porque era gratis o muy friki. A día de hoy, ha asesinado por la espalda a casi todos los Unix, se codea en la cima con los pocos que quedan (prácticamente solo Solaris y AIX) e incluso a estos los supera ampliamente en ventas y velocidad de evolución. MySQL puede ser cutre hoy, pero evolucionaba (aun evoluciona) rápidamente y puede plantear problemas más que serios a Oracle.

Incluso hoy se los presente. Se dice de que MySQL no quita mercado a Oracle, que su mercado es otro, por ejemplo, las miles y miles de bases de datos de webs simples esparcidas por todo Internet, pero no es cierto. Si todas esas miles y miles bases de datos no están en manos de Oracle no es porque ese no sea "su mercado", sino porque MySQL se lo ha arrebatado antes de que pudiera hacer algo. El tal Monty tambien asegura que hay gente que algunas personas que se han pasado de Oracle a MySQL, y no hay razón para creer que no haya gente con necesidades particulares -en las que las excelencias de Oracle no sean un requisito- que efectivamente lo haya hecho. No olvidemos, sobre todo el factor precio: Si para una aplicación hipotética de una empresa hipotética MySQL es un 30% más lento que trabajando con Oracle, pero el coste de las licencias de Oracle es el doble, la empresa podría decantase por MySQL. La mera existencia de MySQL hace que el mercado fuerce a Oracle a poner precios a la baja en ciertos segmentos. ¿Cuanto dinero pierde Oracle por ofrecer gratuitamente su Express Edition? ¿Para qué existe esa versión, si no es para competir con cosas como MySQL?

Resumiendo: En mi opinión, es necesario un fork de MySQL (como MariaDB, del tal Monty), al margen de lo que Oracle haga o prometa hacer. Es necesaria una versión que se desarrolle en un entorno verdaderamente libre. De hecho, creo que hubiera sido mejor que la CE no hubiera puesto trabas a Oracle, porque hubiera facilitado la creación y prosperidad de ese fork, mientras que con las nuevas condiciones quizás tengamos que esperar cinco años de incertidumbre.

16 de diciembre de 2009

Recomendación: Gráficos QT

Si están interesados en QT -y, aunque no lo estén, si están interesados en el subuniverso gráfico libre-, les recomiendo que se paren a leer este larguísimo pero magnífico post sobre los gráficos de QT.

13 de diciembre de 2009

libdispatch en el kernel

Resulta curioso que a veces una misma idea florezca con diferentes formas al mismo tiempo sin que entre cada aparición haya aparentemente ninguna relación. Digo esto porque en la próxima versión de Linux va a añadirse un curioso sistema con ideas similares a las del sistema Grand Central Dispatch de OS X pero aplicado exclusivamente al kernel, y no parece que haya ninguna relación entre ambos.

En realidad, la idea -llamada workqueues- existe desde hace muchos años. Conceptualmente se trata de algo similar a GCD -lo que viene siendo un pool de threads-: Un subsistema (por darle un nombre) al que diferentes partes del kernel pueden enviar "trabajos" que se completarán posteriormente. Generalmente, los "trabajos" son creados drivers que tras gestionar una interrupción y recibir los datos pertinentes, envían al subsistema de workqueues un puntero de una función y otro de unos datos para que el resto del trabajo, menos urgente que la gestión de la interrupción, se vaya ejecutando según se pueda, mientras que el driver queda libre para recibir nuevas interrupciones. El kernel ejecuta este trabajo desde los threads del kernel events/N (uno para cada CPU). La novedad en esta versión, y lo que hace que recuerde el sistema de GCD, es una óptima gestión en múltiples CPUs.

Y es que cada driver tiene workqueue al que envían múltiples trabajos, y en el sistema actual todos los trabajos de un mismo workqueue se envian a una sola CPU. Eso implica que si un driver produce una gran cantidad de trabajos, el sistema actual lo ejecutará en una sola CPU, mientras que el resto de CPUs podría estar libre y desaprovechándose. La similitud del nuevo sistema que se incluirá en 2.6.23 con GCD es que es capaz de distribuir los trabajos entre múltiples CPUs según se necesite.

(Aunque, siendo escrupulosos, hay que resaltar que las workqueues no son utilizadas solamente por drivers. Tambien pueden utilizarse por otras partes del kernel, por ejemplo Btrfs para descomprimir los datos; a día de hoy utiliza una cosa rara basada en zlib para que se utilicen todas las CPUs, pero lo previsible es que acabe pasándose a workqueues, ahora que el sistema ya expande el trabajo entre varias CPUs él mismo)

3 de diciembre de 2009

Lo que trae Linux 2.6.32

Resumen de las novedades más importantes del kernel Linux v2.6.32, que acaba de salir hoy: Reescritura de la parte de la VM encargada de enviar los datos al disco, considerables mejoras de Btrfs, muchas mejoras en los drivers gráficos, KSM (deduplicación de memoria en sistemas virtualizados), límites blandos en el controlador de memoria, soporte de la arquitectura S+Core, mejoras en la herramienta perf y otras muchas cosas. La lista completa, aquí, como siempre.

· Reescritura de la parte de la gestión de memoria encargada de escribir los datos al disco ("per-backing-device based writeback"): En el contexto de Linux, "writeback" puede definirse como el proceso de escribir la memoria "sucia" (memoria perteneciente a archivos modificados) del caché de páginas al disco. La cantidad de datos que pueden necesitarse escribir de una vez puede ser inmensa -cientos de MB, o incluso GB-, y el encargado de hacer el trabajo es un thread del kernel con el nombre de "pdflush", que inicia su actividad cuando se alcanzan los límites definidos en /proc/sys/vm/* o como reacción a ciertas condiciones. Sin embargo, el actual sistema, pdflush, tiene varias desventajas, que lo hacen ineficiente en máquinas con múltiples discos y cuando se necesitan escribir grandes cantidades de datos. Jens Axboe (Oracle) ha diseñado un nuevo sistema que se basa en la idea de tener un thread de kernel dedicado a cada dispositivo y que maneja otro tipo de estructuras de datos que le permiten tomar mejores decisiones. Los threads "pdflush" son reemplazados con otros llamados "flush-MAJOR" (Major es el id "major" del dispositivo), que se crean cuando se escribe algo al disco y desaparecen automáticamente si no hay nada que hacer.

Este sistema tiene mejor rendimiento en muchos tipos de carga. En un benchmark de dos procesos haciendo escrituras secuenciales en un archivo de 32 GB ubicado en un volumen LVM con 5 discos "stripped", XFS fue un 40% más rápido, y Btrfs 26% más rápido. Una carga basada en el benchmark ffsb que hace escrituras aleatorias fue un 8% más rápido sobre una sola unidad SATA típica. En un test en discos SSD sobre XFS fue un 20% más rápido, con un ratio de transferencia que se mantiene estable en 1GB/segundo, mientras que pdflush solo conseguía hacer 750 MB/s y con continua fluctuación de la velocidad. Las escrituras aleatorias a múltiples archivos tambien han mejorado, asi como las escrituras aleatorias mediante mmap(). En un test de un proceso escribiendo secuencialmente vs otro haciéndolo aleatoriamente pasó de unos pocos MB/s a 120 MB/s. Resumiendo, que el rendimiento mejora en muchos campos.

· Mejoras de Btrfs: En esta versión hay mejoras considerables en Btrfs:

· -ENOSPC: Hasta ahora, Btrfs no ha tenido verdadera capacidad de gestionar correctamente las situaciones en que el sistema se queda sin espacio libre (error -ENOSPC en varias funciones POSIX), debido a que estas situaciones son más dificiles de manejar en un sistema de archivos basado en técnicas COW que en uno tradicional donde simplemente se reescriben los bloques. En esta versión, Josef Bacik (Red Hat) ha añadido la infraestructura necesaria para solucionar ese problema. Nota: El sistema de archivos podría llenarse y, aun así, mostrar una cantidad considerable de espacio libre. Ese espacio viene de chunks de metadatos/datos que no pueden terminarse de llenar porque no hay espacio para crear su equivalente chunk de datos/metadatos. Este problema no tiene que ver con la gestión correcta de -ENOSPC, y será solucionada en futuras versiones

· Soporte adecuado de eliminación de snapshots y subvolúmenes: Usando la última versión de btrfs-progs se pueden encontrar herramientas para eliminar y renombrar snapshots y subvolúmenes sin tener que recurrir a rm -r. Este sistema es mucho más rápido, porque se hace la eliminación "caminando" el Btree. La implementación viene de manos de Yan Zheng (Oracle).

· Mejoras de rendimiento: Las escrituras secuenciales en hardware veloz se quedaban limitadas por el uso de CPU sobre los 400 MB/s, Chris Mason (Oracle) ha mejorado el código de manera que ahora es capaz de llegar a 1GB/s con la misma utilización de CPU que XFS (descontando los checksums). Hay tambien mejoras de velocidad en la escritura de grandes extents, y tambien en muchas otras cargas. Las configuraciones con múltiples dispositivos son tambien mucho más rápidas debido a los cambios en el sistema de writeback. La velocidad de fsync() tambien se ha mejorado considerablemente (soluciona un problema de lentitud de yum en Fedora 11)

· KSM (Kernel Samepage Merging), deduplicación de memoria en sistemas virtualizados: En los sistemas virtualizados, cada copia VM consume su memoria independientemente de las demás, y no puede compartirse a pesar de que una parte muy considerable es la misma en todas las instancias de un mismo SO. KSM es un sistema para compartir esa memoria. El thread del kernel ksmd escanea periódicamente areas de memoria, trata de identificar las que son idénticas, elimina las copias y solo conserva una. No toda la memoria es escaneada, solo las áreas especificadas por las utilidades de espacio de usuario mediante la llamada del sistema madvise(2) con el flag MADV_MERGEABLE.

El resultado es un dramático descenso de la memoria utilizada. En una prueba en un servidor de virtualización con KSM y 16 GB de RAM, Red Hat llegó a hacer funcionar 52 VMs con Windows XP y 1GB de memoria cada una. Este sistema fue diseñado para KVM, pero es agnóstico y puede utilizarse con cualquier otro sistema de virtualización, o incluso sin virtualización, por ejemplo en aplicaciones que por alguna extraña razón tengan varios procesos usando cada uno grandes cantidades de memoria que puede ser compartida en gran medida.

· Mejoras al subsistema gráfico: El aterrizaje de GEM y KMS en anteriores versiones ha marcado el inicio de una necesitada renovación en los drivers gráficos de Linux. En esta versión se añaden varias mejoras.

· Radeon: Soporte de KMS y aceleración 3D en r600/r700: Se Basado en las especificaciones liberadas por AMD (¡gracias!). El rendimiento 3D está lejos de ser óptimo, pero funciona lo suficientemente bien como para ser utilizado en el típico escritorio con efectos, puede tener problemas con los juegos. Con este driver incluso las últimas gráficas de AMD/ATI están soportadas, lo que significa que son las gráficas más rapidas que disponen de un driver libre. Solo Nvidia requiere aun un driver binario (algo que esperemos que solucione pronto Nouveau)

· Radeon: Soporte inicial de Salida de TV

· Radeon: Comprobador de comandos en rn50/r100/r200 (mejora la seguridad)

· Intel: Reseteo automático de la GPU en i965: La GPU es reseteada automáticamente cuando el driver detecta que ha habido un cuelgue de la misma.

· Intel: Compresión del framebuffer: Ahorra 0.5W cuando el sistema no está haciendo nada

· Intel: Control dinámico de la frecuencia del reloj: Cuando los gráficos no están haciendo gran cosa, el ratio de refresco LVDS y el de la GPU puede reducirse, y el autorefresco de la memoria puede ser inducido a un estado de energía menor.

· Intel: Mejorar la respuesta del sistema bajo presión de memoria: Cuando el sistema se está quedando sin memoria, el driver puede liberar algunos de sus buffers.

· VGA Arbitration: En sistemas multiseat (varios usuarios accediendo a un mismo servidor que tiene múltiples tarjetas gráficas y múltiples monitores) no existe un sistema para arbitrar el acceso concurrente entre múltiples procesos, el "árbitro VGA" soluciona ese problema.

· Modo de baja latencia en CFQ: En esta versión, el IO scheduler CFQ (el que se utiliza por defecto) tiene una nueva característica que lo ayuda a limitar en gran medida el impacto que un proceso escribiendo puede tener en la interactividad del sistema. El resultado final es que la experiencia en el escritorio debería estar menos impactada por el IO del sistema, pero puede causar problemas de rendimiento en los servidores, asi que la gente a la que solo la importa el rendimiento (servidores) pueden probar a desactivarla -está activada por defecto- escribiendo un 0 a /sys/class/block//queue/iosched/low_latency.

· Mejoras en perf, perf tracepoints, perf timechart, perf sched: La herramienta perf está recibiendo mucha atención y muchos parches. En los últimos meses ha sobrepasado su carácter inicial de sistema de contador de registros de rendimiento de hardware, y se ha convertido en una herramienta mucho más genérica para la enumeración, reporte, logeo, monitorización y análisis de eventos, asi que la herramienta ha sido renombrada de "Contadores de rendimiento" a "Eventos de rendimiento"

· Trapoints: En esta versión se incluye soporte para "probear" los puntos de traceado estáticos (para entendernos: una especie de printk()s ocultos con nombre y que se pueden activar y desactivar individualmente) que han sido añadidos a muchos subsistemas del kernel (tambien se pueden analizar desde systemtap). Ahora es posible analizar cargas mucho más fácilmente. Cuando debugfs está montado, perf list muestra una sección con todos los puntos de trazado disponibles en el sistema, de modo que puedes hacer cosas como perf record -e i915:i915_gem_request_wait_begin -c 1 -g para conseguir una traza inversa de las llamadas que causan una pausa en las GPUs Intel, o perf stat -a -e ext4:* --repeat 10 ./somebenchmark para tener unas estadísticas media de todos los puntos de trazado de Ext4 a lo largo de 10 ejecuciones de algún benchmark. Tambien puedes analizar llamadas de sistema, por ejemplo puedes hacer perf stat -e syscalls:sys_enter_blah, lo cual sería una especie de strace, pero con unas características adicionales que lo hacen aun más potente que éste. Puedes leer [http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/trace/tracepoint-analysis.txt;h=5eb4e487e667d1396bcede6af11e0bd5c60f0711;hb=bb72222086260695d71afe60fa105649c1ea9463 Documentation/trace/tracepoint-analysis.txt] para tener un howto de como hacer análisis de rendimiento con puntos de trazado.

· Timechart: "perf timechart" es una herramienta basada en perf diseñada para ser un mejor analizador del arranque que bootchart. Genera un gran archivo SVG al que, a diferencia de bootchart, puede hacérsele zoom para tener un gran detalle de los eventos recogidos. En [http://blog.fenrus.org/?p=5 esta entrada de blog] puede encontrarse mucha más información sobre esta herramienta.

· perf sched: Una nueva herramienta ha sido añadida para trazar/medir propiedades del gestor de procesos.

· Nuevos tracepoints: En esta versión se han añadido tracepoints para llamadas al sistema, carga/descarga de módulos, asignación y uso de skb's (socket buffer), KVM, los algoritmos de gestión de memoria, los temporizadores, el driver i915, ciertas partes de Ext4 y JBD2, y soporte de perf en SPARC.

· Límites blandos en el controlador de memoria: Los grupos de control son una especie de contenedores virtuales que se crean como directorios en un sistema de archivos virtual especial (normalmente, con la ayuda de [http://libcg.sourceforge.net/ herramientas]), y puedes añadir una cantidad arbitraria de procesos a ese grupo de control y configurarlo para que tenga una serie de características ó límites determinados de CPU y memoria para los procesos que contiene. En esta versión se añaden soporte para límites "blandos" (o tolerantes) de memoria: El proceso puede sobrepasar el límite blando mientras haya memoria (y no excedan su límite "duro"), pero si el sistema necesita memoria, extraerá memoria de los grupos que sobrepasaron su límite blando.

· Suspensión de dispositivos en tiempo de ejecución: Esta característica permite que cada dispositivo sea puesto en modo de bajo consumo o que sea "suspendido" individualmente tras un periodo de inactividad, algo que antes se hacía solamente al suspenderse el sistema. Cuando se vuelve a registrar actividad, se reactivan. Por lo general, se requiere soporte de hardware para que esta característica funcione, y los diferentes tipos de bus son quienes realmente se encargan de gestionar las peticiones de suspensión de cada dispositivo.

· Soporte de la arquitectura S+core: Esta versión añade soporte para una nueva arquitectura, [http://w3.sunplus.com/products/S%2Bcore.asp S+core]. El conjunto de instrucciones de Score soporte instrucciones de 16bits, 32bits y 64bits. Los SOCs de Score han sido utilizados en máquinas de juegos y televisores LCD.

· Soporte de Intel Moorestown y SFI (Simple Firmware Interface) y ACPI 4.0: SFI es un método para exportar tablas estáticas del firmware de una plataforma al SO - algo análogo ACPI, pero como suele hacerse en otras arquitecturas, como PPC. Se utiliza en los dispositivos MID basados en la segunda generación de la plataforma Intel Atom, cuyo nombre código es Moorestown. SFI se utiliza en esas arquitecturas porque es más simple y ligero. Para más información, ver [http://simplefirmware.org este sitio web] Al mismo tiempo, esta versión añade soporte para Moorestown, la plataforma Moblin basada en la arquitectura de bajo consumo de Intel. Moorestown consiste de dos chips: Lincroft (CPU, gráficos y controlador de memoria) y Langwell IOH. A diferencia de los PCs x86 standard, Moorestown no tiene muchos dispositivos "legacy" e.g. Moorestown no tiene i8259, i8254, HPET, legacy BIOS, ni la mayoría de puertos IO.

Tambien se ha añadido cierto soporte inicial para ACPI 4.0 (Linux es la primera plataforma en soportarlo