Tráfico del Núcleo #119 For 21 May 2001

Esto debe poner a descansar a las acusaciones de que Linux obtuvo el destacado marcador alto de SPECweb99 sólo porque el servidor web estaba en el espacio del núcleo. Es el alto rendimiento del núcleo 2.4 que nos permitió esos resultados, el tener el servidor web en el espacio del núcleo no tuvo mucho efecto. TUX era y permanece como una base de pruebas para probar el servicio de web de alto rendimiento (y el servicio de FTP), sin el gasto de la exportación de APIs del espacio de usuario.

[sospecho que la pequeña ventaja en rendimiento de X15 se debe a diferencias sutiles en el módulo de espacio de usuario del SPECweb99: pe. mientras el código TUX estaba escrito, probado y listo para usar TUXAPI_alloc_read_objectbuf() habilitado-para-mmap(), no estaba de hecho activado. Envié a Fabio un mail indicando cómo activarlo, tal vez él pueda hacer algunas pruebas para confirmar esta sospecha?]

haciendo una medición SPECweb99 de TUX 2.0 en los últimos núcleos -ac, el 86% del tiempo es empleado en partes genéricas del núcleo, 12% del tiempo es empleado en el módulo de espacio de usuario de SPECweb99, y sólo el 2% del tiempo es empleado en código del núcleo específico de TUX.

Haciendo la misma prueba con el código original de TUX 1.0 muestra que más del 50% del tiempo de CP era empleado en el código específico de TUX.

¿esto que significa? Aproximadamente en los 6 meses desde que TUX 1.0 fue liberado, hemos movido muchas de las mejoras que sólo estaban en TUX 1.0 al núcleo genérico (muchas de las cuales fueron hechas disponibles también al espacio de usuario), y TUX en sí se volvió más y más pequeño (y usando más y más partes genéricas del núcleo). Así que X15 en efecto está ejecutando el 50% del código de TUX :-)

(aún hay una cantidad de parches pendientes para la mejora del rendimiento que no han sido integrados todavía: el parche de escalabilidad extrema del caché de páginas y el parche de los temporizadores de smp. Estos parches aceleran tanto a X15 como a TUX.)

(de hecho hay una cosa que nunca podrá ser 'exportada a espacio de usuario': aislar código binario de aplicaciones posiblemente no confiables del mismo servidor, sin degradación del rendimiento. Así que siempre tenemos que estar mentalmente abiertos para la validez de los servicios del espacio del núcleo.)

Seguramente Linux 2.4 es uno de los SO más avanzados que jamás hayan sucedido, especialmente desde el punto de vista de la optimización y la admirable economía de conceptos sobre el cual yace. Definitivamente espero que X15 ayude a reforzar el éxito de este sorprendente sistema.

TUX definitivamente ha sido mi marca a vencer de rendimiento para el desarrollo de X15, pero he tenido muchas fuentes de inspiración para la arquitectura de X15. Tal vez la más relevante sea el Servidor Web Flash (Pai, Druschel, Zwaenepoel), varias observaciones de Linus en esta lista sobre arquitectura de servidores (web) y servicios de núcleo, y la lectura de los libros de arquitectura de Hennessy & Patterson. Finalmente, pero no al último, además de algunas acaloradas discusiones, la investigación en arquitectura de micronúcleos nos ha enseñado varias lecciones de cómo lograr un modelo eficiente de interacción entre espacios de direccionamiento separados.

Si tuviera que hacer algún tipo de adivinanza con datos y señalar dónde yace el cuello de botella actual para el rendimiento del servidor web, diría que está en algún lugar entre el subsistema de memoria y el bus PCI.

El movimiento de datos ya no es más un problema con sendfile de copia-cero, ES asíncrono de red permite la calendarización de hilos realmente sin costo, y la invocación a llamadas del sistema agrega una carga muy descartable en Linux. Con lo que nos han dejado ahora es solamente ciclos de espera, los CPUs y las tarjetas de red están compitiendo por memoria y ancho de banda. Sería realmente interesante ver a dónde cambian las redes ahora ya que las máquinas más rápidas se están volviendo disponibles.

En mi lista de deseos para desarrollos futuros del núcleo yo incluiría definitivamente ES asíncrona de disco y una implementación más decente de paso de descriptores de fichero. Detallaré eso en mensajes subsecuentes.

Seguramente revisaré el impacto de los parches de Ingo en el rendimiento de TUX en algún momento de esta semana.

También quiero reiterar mi petición de ayuda para probar X15 en arquitecturas de servidores de alto desempeño.

X15 aún es código alfa muy joven y seguramente puedo mejorar su rendimiento en muchas formas.

Nuestra intención es liberar X15 con una licencia de código abierto.

Esto sucederá tan pronto como el código base se estabilice un poco, eso es cuando vayamos a beta (en dos - tres semanas).

En este momento no tenemos el tiempo...

La razón por la cual he liberado la versión binaria alfa es que mucha gente no creía que un servidor de espacio de usuario con este nivel de rendimiento fuera posible después de todo y varias afirmaciones que hice en esta lista fueron retadas.

Además aprecio de verdad la retroalimentación que he recibido hasta ahora de Ingo y otros, y tengo mucha curiosidad de saber si alguien hizo alguna evaluación de rendimiento después de todo.

he notado otra anomalía de RFC en X15. Ignora el encabezado de petición "Connection: close" pasado por un cliente HTTP/1.1. Esta conducta está en contra del RFC 2616, un servidor no debe sobrepasar la opción del cliente de una conexión no persistente. (debe haber clientes HTTP/1.1 que no tengan soporte para conexiones persistentes y lo señalen a través de "Connection: close".)

La regla es: una petición es keepalive o no-keepalive. Las peticiones HTTP/1.0 son por omisión no-keepalive. Las peticiones HTTP/1.1 son por omisión keepalive. Esta conducta por omisión puede ser sobrepasada a través de los campos de encabezado "Connection: Keep-Alive" o "Connection: close".

si compones esto, ¿impacta de alguna forma el rendimento de SPECweb99?

otra anomalía más que noté. X15 no parece manejar peticiones HTTP/1.1 entubadas propiamente, ignora la segunda petición si dos peticiones llegan en el mismo paquete.

SPECweb99 no manda peticiones entubadas, pero varios clientes web de la vida real lo hacen. (Mozilla, apt-get, etc.)

He subido una nueva versión de X15 que espero que resuelva todos los bugs relacionados con RFCs. Digo que lo espero porque no he tenido la oportunidad de probar completamente la petición de entubamiento. ¿Hay algo ahí para automatizar tales pruebas?

De lo que pude medir X15 es aún un buen 5% más rápido que TUX.

Puedes encontrar el fichero en: http://www.chromium.com/X15-Alpha-4.tgz

Por cierto: ¡La próxima versión (en una semana o más) habrá una beta e incluirá código fuente!

Soy cauteloso para usar un juego de chips Ali. Son aún menos comunes que VIA así que no han tenido la exposición para exponer problemas.

También la característica principal que estoy buscando es una máquina con 768 Meg o 1G de ram a un precio razonable. Por tanto quiero usar dimms de 256 Meg. No puedo usar un juego de chips i815 ya que topan en 512 Meg. Las tarjetas apollo pro es una de las pocas que tienen 4 ranuras dimm que permiten 1 Gig de memoria. Las tarjetas athlon sólo tienen 3 ranuras dimm así que topan en 768 Meg.

Soy cauteloso para usar dram DDR. Los juegos de chips no han estado fuera los suficiente para tener un registro de desempeño. Y la ram es demasiado cara. También el A7M266 está usando un puente sur VIA 686b de cualquier forma lo cual pienso fue la fuente de los problemas. De cualquier forma estas tarjetas solamente tienden a tener 2 ranuras de dimm DDR y el dimm DDR más grande que vende crucial es de 256 Meg. Así que estaría limitado a 512 Meg.

Tal vez tenga que morder el polvo e irme con dimms de 512 Meg. Sólo parecen estar disponibles registrado con ECC lo cual los hace que cuesten cerca del doble por mega y lo cual no me asegura que todas las tarjetas los soportan. Cuáles tarjetas madres/juegos de chips recomienda la gente para máquinas con 1Gig+ de ram.

• ¿Es simplemente que debe compilarse separadamente del núcleo y cargar a través de insmod?
• ¿Podría hacer #include de los ficheros de encabezados del núcleo en mi módulo
• ¿Si es así, cuáles?
• ¿Que tal si estos ficheros de encabezado tienen funciones integradas? (¿Importa?)

Si no lo escucho directamente de Linus, alguien puede señalarme un documento, o un hilo de la lista de correo donde esto pueda estar plasmado.

Si quieres hacer sólo binarios entonces dependes únicamente de cómo intenten interpretar tus abogados el concepto de 'enlace'. Los comentarios de Linus sobre la materia no tienen impacto ya que el núcleo no tiene todo su copyright y él ha incorporado código de cuerpos que están definitivamente opuestos a los módulos binarios.

Lo mismo aplica para código fuente bajo 'restricciones adicionales' como la GPL llama a las cosas que desactivan cosas que permiten.

Si estás liberando módulos con código bajo términos que son al menos tan libres como la GPL (vg BSD sin la claúsula de publicidad) entonces a nadie le importa. Probablemente no lo mezclaríamos con el núcleo principal debido a la falta de protección de trampas de patentes en la licencia BSD pero sospecho que no quieres eso de cualquer forma.

Parece que de repente en 2.4.4 la función "skb_cow" ya no regresa más el skb modificado, sino que regresa un entero por éxito/fracaso.

Esto significa que para los módulos de red que requieran esa función, no hay compatibilidad de código fuente entre 2.4.3 y 2.4.4.

"cuando sea posible", nosotros no hemos hecho tal compatibilidad total de código fuente. garantizado. Y muchos cambios más vienen, por ejemplo los bugs de cuotas no se pueden componer sin romper la compatibilidad a nivel de código fuente. para los sistemas de ficheros.

Puedes pensar y argumentar de otra forma, pero nuestra habilidad para romper compatibilidad a nivel de código fuente es una de nuestras fortalezas (ve el bug de rsh del socket poseído por root en solaris del año pasado para un ejemplo de porqué).

Linux en Modo Usuario está ahora arrancando en Linux PPC - puede arrancar con una imagen de disco flexible de root de Debian con init=/bin/sh y picar alrededor. Casi funciona, aunque hay algunos unos cuantos problemas.

El parche actual está disponible de http://www.tartarus.org/~chris/user-mode-linux/, hecho en contra del reciente UML de CVS (ver http://user-mode-linux.sourceforge.net).

Primero, quiero agradecer a Chris para ofrecerse como voluntario para llevar a cabo el primier transporte de UML y verlo desde el punto donde básicamente estuviera funcionando. Es una buena demostración, si alguna fuera necesaria, de que UML no es sólo i386.

Basado en lo que he aprendido de este transporte, estoy escribiendo lo que concluirá en una guía de transporte de UML. Se encontrará en http://user-mode-linux.sourceforge.net/arch-port.html cuando tenga algo listo. Estará incompleto al empezar - lo iré llenando mientras revise el código existente y mientras completo la integración del código de Chris en mi distribución.

Así, si alguien quiere transportar UML a otra arquitectura, revisen esa página (y continuar revisándolo mientras lo lleno :-). Verán que no es una gran cantidad de trabajo. UML es bastante transportable.

Adjunto está un controlador para la tarjeta Microcanal NCR Dual 700 Ya que el chip motor de esta tarjeta es el 53c700-66, que aparece bastante en otras tarjetas SCSI también, he abstaído la función del chip (mucho en la misma forma en que la función del chip 8390 es abstraída en las tarjetas de red) así que debe ser fácil de incorporar en cualquier otra tarjeta SCSI que lo utilice. Como pueden ver, el código específico de la tarjeta es cerca de 150 líneas.

El controlador del chip está lleno de características (sincronización (cuando está soportado), encolamiento de comandos de desconexiones y marcados). Controlará interfaces tanto con un sólo extremo como diferenciales y usa el nuevo manejador de errores SCSI.

Se que puedo tener dos controladores que claman ser estos chips (53c7xx y 53c7,8xx) pero si de hecho los compilas para este registro, están completamente descompuestos. El chip en sí mismo es extemadamente primitivo (no tienen la tabla de modo indirecto, la cual es la parte central de la mayoría de los controladores anteriores) así que tiene mucho más sentido darle su propio controlador.

El controlador de chip mapeado actualmente en E/S (porque las únicas tarjetas que conozco que usan el chip están mapeadas en E/S), pero también puede ser hecho como mapeado en memoria fácilmente, sólo háganmelo saber.

¿Cuál es la estructura en disco del disco dinámico de Win2k p.e. las estructuras de las bases de datos del Administrador de Disco Lógico (LDM)? - El artículo "Dentro de la Administración de Almacenamiento, Parte 2" por Mark Russinovich en la revista Windows 2000 (el texto completo está disponible libremente en: http://www.win2000mag.com/Articles/Index.cfm?ArticleID=8303) describe en detalle la disposición lógica de la base de datos LDM, pero no cubre con suficiente detalle para ir e implementarlo en Linux (sin una cierta cantidad de ingeniería en reversa).

Linux necesita entender la base de datos LDM para dar soporte a configuraciones de arranque dual de Win2k (o XP) y Linux donde hay uno o más discos dinámicos presentes en el sistema y el usuario quiere accesar sus particiones NTFS que residen en el(los) disco(s) dinámico(s) desde Linux.

Sólo decir "No usen discos dinámicos si quieren usar Linux" es en mi humilde opinión una Cosa Mala(MR) ya que un usuario podría haber comprado una computadora con Win2k preinstalado en un disco dinámico o, aún peor, podría haber estado usando solamente Win2k previamente, y entonces el usuario quiere instalar Linux también en ella. En esos casos el usuario tendría que reformatear el sistema entero y comenzar de cero a menos que Linux de soporte a discos dinámicos...