20 de diciembre de 2005

Razones para usar kernels precompilados (toma 2)

Hay una especie de "regla no escrita" en el mundo linuxero que dice que toda persona "debe" compilar su propio kernel, como parte de su proceso de aprendizaje o de incremento de su "estatus geek". Nada más lejos de la realidad: El kernel, al igual que el resto del software del sistema, no deberia necesitar compilarse - como cualquier software diseñado decentemente. Lo que mucha gente no sabe es que Linux 2.6 es lo suficientemente avanzado como para que un kernel precompilado funcione perfectamente sin retoques en la mayoría de sistemas

  • Razón 1: Hay un mito sobre el kernel: La gente piensa que optimizando el kernel, el sistema irá más rápido, y que si no lo haces irá lentísimo y estarás desaprovechando tu equipo.

    Vamos a ignorarlo y hacer un análisis serio. Pregunta: ¿Cuanto tiempo de CPU gasta un sistema normal ejecutando codigo en espacio de usuario y cuanto gasta ejecutando código del kernel?. sar (maravilloso programa que no debería faltar en vuestros sistemas) puede decirlo:
    20:05:01          CPU     %user     %nice   %system   %iowait     %idle
    20:05:01          all      6,23      0,00      0,50      0,25     93,03
    

    Como se puede ver en este caso, de todo el tiempo de CPU transcurrido en mi sistema en un uso típico de escritorio (email, firefox, escribir artículos malos) solo un 0.50% del tiempo de CPU ha sido utilizado por el kernel, y un 6.23% por programas de espacio de usuario (un servidor dará diferentes números, de hecho un servidor web dará porcentajes diferentes a un pc haciendo de router). Es decir, 12.46 veces más. De todos los ciclos de CPU durante el que se ejecuta "software real" (todo lo que no es tiempo "idle") el 92.57% se ejecutan en espacio de usuario, y un 7.42% en el kernel.

    Lo que quiere decir esto es que en un uso normal el sistema se pasa la mayor parte del tiempo ejecutando software en espacio de usuario, y que por lo tanto optimizar el kernel no mejorar el rendimiento del sistema de manera notable, por la simple razón de que la mayor parte del tiempo no es su código el que se está ejecutando. En las distros precompiladas tiene especialmente poco sentido: ¿Para qué optimizar para el procesador de turno el 7.42% del tiempo de ejecución si el software que se ejecuta el 92.57 del tiempo está "optimizado" para i586 o i386?.

    Esto tampoco quiere decir que la optimización no influya en absoluto: Hay ciertas funciones (como las funciones que mueven porciones de memoria de un sitio a otro) que se utilizan mucho y algunas tienen incluso optimizaciones específicas en ensamblador. Lo que quiero decir es que esperar que el optimizar el kernel vaya a acelerar notablemente un sistema típico es lo mismo que esperar que un grano de arena sea distinguible en un desierto.


  • Razón 2: Las diferencias entre procesadores puede que no justifican la optimización. Eso tampoco quiere decir que no existan esas diferencias o que no vayan a influir: Simplemente, las diferencias no son tan grandes como para justificar la optimización. Las distribuciones suelen tener un kernel i586 por defecto (excepto ubuntu y debian) y muchas kernels precompilados adicionales disponibles (para k7, para athlon64, para p4) en los repositorios. En serio, no necesitas recompilar el kernel solo porque en el kernel no añadieron una opción al gcc que tu "sabes" que en "teoria" optimiza mucho el ejecutable para tu máquina. Como ejemplo extremo está Ubuntú: Su kernel por defecto está optimizado con instrucciones de i386 (pero optimizadas para un pentium 4, esto es otro tema), y apuesto a que mucha gente ni siquiera se ha dado cuenta. Además hay que tener en cuenta una pecularidad de la plataforma x86: Todos sus procesadores se parecen "enormemente" entre si. De hecho, es la base de su éxito: Si x86 está donde está es en gran parte por no cambiar demasiado y preservar la compatibilidad lo máximo posible. En general, cuando las empresas dedicadas a CPUs preparan una nueva versión de CPU intentan copiar al máximo y dentro de las posibilidades de la nueva arquitectura el comportamiento de los procesadores anteriores, por la simple razón de que los compiladores tardan años en optimizarse para una arquitectura determinada. Eso puede suponer que al salir el producto a la calle el rendimiento sea pobre y que el producto fracase comercialmente. ¿A alguien le suena Itanium?

    Una de las principales diferencias entre los x86 (además de las diferencias fundamentales como netburst vs opteron etc) son las extensiones "multimedia": MMX, SSE, 3dnow. Estas son especialmente irrelevantes para el kernel: Existe una regla en el kernel que prohibe utilizar código en punto flotante en el kernel excepto en unos pocos lugares controlados (usarlo demasiado obligaría a guardar los contenidos del coprocesador matemático entre cambios de contexto y eso enlentecería mucho el kernel). Se utilizan en algunos puntos, pero se evitan como si tuvieran la peste

    Lo que quiero decir aquí es que esto es como los benchmarks de Intel vs AMD: "En x benchmark AMD gana a intel un 5%". Si, el AMD es más rápido, pero esa "ventaja" supone que en vez de tardar un minuto el amd lo hace en 59 segundos, que es prácticamente lo mismo. Es muy probable que no notes las optimizaciones que estes haciendo al compilar a mano el kernel. Son demasiado pequeñas. Las principales diferencias vienen casi siempre de mano los algoritmos: No hay optimización de procesador en el mundo que vaya a hacer que el kernel descarte correctamente tal o cual dato en el cache de disco o el orden correcto en el elevator del kernel, por ejemplo, y te aseguro que esa decisión va a influir muchísimo más en el rendimiento de tu máquina que cualquier optimización a nivel de procesador


  • Razón 3: Seguridad: Si descargas y compilas tu propio kernel, el día que haya un fallo de seguridad en el kernel tendrás que: 1) Enterarte. Algo que no es fácil, porque los fallos de seguridad del kernel casi nunca se reportan en barrapunto o slashdot o osnews (y si piensas que si, significa que no te has enterado de muchos fallos de seguridad o incluso de que alguien ha hackeado tu servidor gracias a uno de esos bugs y tiene instalado un rootkit en él ahora mismo, y no tengo por qué estar siendo paranoico) 2) reconfigurar 3) recompilar

    Sin embargo, si instalas un kernel precompilado, lo instalarás a partir de los paquetes de tu distro, y los sistemas de actualización de tu distro te lo actualizarán automáticamente en cuanto haya nueva actualización de seguridad. Es una opción bastante más inteligente...


  • Razón 4: Tener muchas cosas (opciones) compiladas en el kernel no daña necesariamente el rendimiento: Alguna gente se cree que tener todos los sistemas de archivos en el kernel, o la emulación de coprocesador matemático va a hacer las cosas mas lentas. ¿Por qué? No se trata mas que de un gran IF: Si algo no se usa, no tiene porque afectar al resto. El código de un dispositivo que no se tiene jamás se ejecutará. Y por supuesto la mayoría de kernels precompilados no hacen esas cosas - se modularizan las cosas exageradamente, hasta el punto que algunas distros nisiquiera compilan el sistema de archivos del sistema de archivos root / en el kernel, compilan todos como módulo y cargan el necesario en el initrd


  • Razón 5: Tener muchos módulos es útil: La gente suele compilar su kernel porque quiere "compilar solo el soporta para su hardware y quitar el resto". Esto está relacionado con el punto anterior. La pregunta es: ¿Por qué? Los módulos no utilizan nada más que espacio en el disco al menos que no se carguen. Probablemente tengas un /usr/X11R6/lib/modules/drivers/vmware_drv.o en tu sistema. ¿Recompilas las X solo para desactivar ese driver? ¿Recompilas para desactivar las librerias de accesibilidad de gnome solo porque no las necesitas? Tener 100 o los módulos que sean ahí no hace daño. Tampoco es ninguna guarrada: Es lo correcto. El objetivo del kernel es que tu hardware funcione, y el soportar más hardware del que tienes significa que podrás cambiar de hardware sin recompilar el kernel: Y esto es importante para todos, porque con USB y firewire es imposible determinar en tiempo de compilación que dispositivos vas a acabar conectando a tu equipo. La flexibilidad es una característica del software, y es buena.

    Una vez sufrí un problema relacionado con esto: No tengo un lápiz USB, asi que no tenía compilado el soporte. Pero resulta que un amigo vino con un disco duro externo USB, y como no tenia ganas de hacerle soportar la espera de compilar un kernel, tuve que iniciar en Windows. Windows paraba la transferencia a la mitad y el driver dejaba de funcionar asi que finalmente tuve que hacer esperar a mi amigo. Moraleja: Un sistema moderno tiene USB y firewire y por lo tanto no tiene una configuración de hardware estática

    Udev es quien se encarga de hacer gran parte del trabajo de configurar el hardware del sistema y cargar los modulos de tu hardware y no cargar los que no son. Si yo por ejemplo enchufo mi webcam Creative Go Plus, el kernel notifica a udev de que se ha insertado un dispositivo en el bus usb, udev mira que es mirando identificando el hardware y carga los dos ó 3 módulos de soporte básico de USB, el módulo de la camara, el módulo del chip de la camara, y el módulo de V4l. Automaticamente. Pero si no la enchufo, no las carga, y puedo hacer que udev descargue los módulos cuando desenchufo la cámara - no hay "bloatware" en ningún lado. Las máquinas se inventaron para hacer cosas por nosotros. Utilizalas para ello y utiliza un kernel precompilado y udev. Muchisima gente de la que compila su kernel a mano no activa el soporte de hotplug (necesario para udev), porque piensa "que no lo necesita". Lo cual nos lleva al siguiente punto


  • Razón 6: Configurar el kernel no es fácil y los mantenedores del paquete precompilado saben que necesitas mucho mejor que tú, aunque no lo creas: El número de opciones disponibles en la fase de configuración del kernel se multiplica en cada versión, y a día de hoy es prácticamente imposible saber configurar correctamente todas las opciones. Mi config tiene 1034 opciones diferentes entre las activadas y desactivadas. ¿Sabes configurar correctamente esas 1034 opciones? Puedes pensar que sabes, pero siendo realistas no hay nadie en el mundo que sepa configurar por si mismo un kernel por completo. Yo llevo años compilando decenas y decenas de kernels por afición al desarrollo del kernel, y aun hay muchas opciones que no se que hacen, ni si debería activarlas o no. Ni tan siquiera los hackers del kernel lo saben, ni Linus Torvalds, te lo aseguro (bueno, quizás Alan Cox...) Los que mantienen una arquitectura no se enteran de que cosas están haciendo los del soporte USB, y viceversa. Por si fuera poco, muchas opciones no están documentadas (o están mal documentadas, que es peor), algunas son peligrosas y otras no puedes saber si activarlas o desactivarlas porque simplemente te da lo mismo (como pasa con cualquier proyecto software que tenga este tamaño: nadie puede conocer 200 MB de código C, además en linux se tiene la "manía" de hacer todo extremadamente configurable hasta el punto que dudo mucho que exista un kernel más configurable) Y la configuración por defecto que trae el kernel de kernel.org está muy lejos de tener los valores por defecto ideales. Moraleja: Deja que los mantenedores de tu distribución se ocupen de la compleja tarea de configurar el kernel. Ellos tienen los recursos (varias personas, sistemas de seguimiento de bugs por si se equivocan en algo, etc) para hacerlo, tú no.

¿Y esto para que lo escribo? Para intentar evitar que la gente se pase la vida compilando kernels por "tradición". Eso no quiere decir que esté prohibido compilarles: Compilar kernels es una actividad divertida y entretenida para un geek, siempre que tenga una razón para ello (por ejemplo, que le da la gana). Lo absurdo es hacer lo que hace la gente: Compilar por que si, sin tan siquiera tener ganas, como si fuera una "obligación" a su estatus de "geek".

17 comentarios:

  1. Tio... me has convencido :D
    Yo era de esos que compilan el kernel para aumentar rendimiento... pero no lo volveré a hacer... palabrita! :D
    Voy a poner un link en mi blog a tu post (si no te importa!).
    Salu2!

    ResponderEliminar
  2. Anónimo1:12 a. m.

    Una de las razones por las que compilo mi núcleo es porque la complejidad es el mayor enemigo de la seguridad. Tener un núcleo con demasiadas opciones abre la puerta a que alguna de esas opciones, que puede que nunca esté usando, puedan ser explotadas por alguien para entrar en mi sistema.

    ResponderEliminar
  3. Esclarecio1:19 a. m.

    Claridad Absoluta, a partir de hoy tendre mas en cuenta las config de los kernels precompilados, (siempre hay que meter algun parche extra XD), pero me has convencido al 100%, Gracias por el articulo.

    ResponderEliminar
  4. Siempre puedes tener tu kernel compilado y el kernel de tu distro.
    Así si tienes problemas (no puedes enchufar el lápiz USB) "sólo" tienes que reiniciar y seleccionar el kernel "estándard" en el grub. :)

    saludos

    ResponderEliminar
  5. Anónimo11:02 a. m.

    Me parece, que has tocado a nivel muy basico el compilar tu propio kernel, quieres los motivos?.
    Hay muchos parches que dan mejor rendimiento a tu hardware, puedes crearte un kernel que realmente tenga lo que necesites y eso es optimizar no solo en velocidad, porque en un AMD 64 tal vez no lo notes, pero en un 233Mhz si. Cuando se montan maquinas dedicadas al calculo etc, cualquier milisegundo ganado en un cluster es aceptado.
    El kernel precompilado puede incluir cosas que no tengan sentido para tu equipo, o simplemente si mañana les da a los de tal distribución meter un rootkit, pues ahi lo tienes.
    Problemas de seguridad ?, necesitas un kernel nuevo?... copias el .config al nuevo kernel, compilas y listo. compilar basicamente es bastante simple
    >make clean bzImage modules modules_install;
    y punto. Que haya aplicaciones no optimizadas para tu micro no quiere decir que optimizar tu kernel sea una tonteria, porque siempre puedes optimizar tambien la aplicacion, aparte de las cientos que hay ya.

    ResponderEliminar
  6. Todo lo contrario: Un micro a 233 MHz no notará casi nada. Entre otras cosas porque es más parecido a un x86 que un amd64


    Segundo, las aplicaciones de calculo intensivo tampoco ganarán mucho, me sorprendería que se pudiera medir. Las aplicaciones de cálculo es el típico caso de aplicación que se pasa todo el día ejecutando código en espacio de usuario sin utilizar llamadas al sistema para nada. Lo que más les afectaría sería todo lo relacionado con la gestión de su espacio de direcciones (vm) y todo eso depende en gran medida de los algoritmos y las estructuras de datos del kernel

    ResponderEliminar
  7. Yo la única manera con la que he conseguido que un P100 vaya BIEN con aplicaciones de hoy dia ha sido con Gentoo compilando todo desde cero y teniendo un sistema mínimo en cuanto a chorradas y he probado muchas cosas distintas.

    Todo depende de lo que hagas, para la mayoria de la gente no sirve de nada recompilar un kernel. Y desde luego te la sopla si tienes un ordenador medianamente decente.

    ResponderEliminar
  8. Anónimo10:21 p. m.

    >simplemente si mañana les da a los de tal distribución meter un rootkit

    Estamos hablando de Software Libre, no de Hasefroch y otras cajas negras ...

    ResponderEliminar
  9. Anónimo5:23 p. m.

    Pues,aunque el artículo está muy bien,hay algunas cosas con las que no estoy de acuerdo,como la de la seguridad. Como ya han dicho el tener menos opciones aumenta el grado de seguridad,(por ejemplo,si desactivas el soporte de módulos es muy improbable que te entre un rootkit).

    No se nombró para nada el tema de la latencia,muchos kernels precompilados (o al menos los de mi distro)vienen con la latencia adecuada para un servidor,cuando en el kernel se puede adaptar ésta para un escritorio (personalmente sin datos ni nada,se nota un poco la diferencia).

    Y otra cosa si tienes una máquina antigua como un Pentium 2,etc compilar el kernel bien si da sus beneficios,puede que no a nivel de procesador,pero el hecho de quitar ciertas opciones aumenta bastante el rendimiento (es mi experiencia,puede que a otros les sea difente).

    De todas formas yo siempre tengo mi propio kernel compilado y otro precompilado por si acaso.

    ResponderEliminar
  10. Anónimo5:27 p. m.

    Con respecto a lo de que Linus no conoce todos los aspectos del kernel,no es él (entre otros pocos más) el que decide que parches y mejoras se introducen finalmente en el kernel (corríjanme si me equivoco)? Pues deberá conocerlo en ese caso digo yo....

    ResponderEliminar
  11. Si desactivas el soporte de módulos, es igualmente fácil que te metan rootkits (por /dev/mem concretamente)


    No, Linus no aprueba todos los parches. Linus no es un Dios, para eso están los mantenedores. En todo el tema de red por ejemplo, el que decide o deja de decidir es Dave Miller y Linus esa parte ni se molesta en mirarla

    ResponderEliminar
  12. Hello Blogger:)

    Congratulations for developing such an great site. Unforgettable experience. Well done.

    Regards,
    home make at money work

    ResponderEliminar
  13. Normalmente los kernels por default estan compilados para x86 genérico, lo creas o no lo creas agregar la arquitectura de tu procesador si aumenta el desemeño.

    Yo como usuario de gentoo compilo mi kernel en cuanto portage me avisa que hay un nuevo kernel estable :).

    ResponderEliminar
  14. Primero de todo felicidades por tu argumentacion, pero que tu me digas que no quieres perder el tiempo en compilar el kernel, pues me parece perfecto. Que me digas que no se nota pues tu mismo.

    Todo depende del ordenador y las caracteristicas que tenga, porque si da la casualidad de que tu ordenador con un generico va de lujo no quiere decir que otro tambien valla bien.

    Y por otra parte yo solo por ganar la velocidad de arranque del sistema, al no tener que cargar todos esos modulitos inutiles ya me vale la pena.

    Como ya digo todo depende.

    ResponderEliminar
  15. Anónimo10:56 a. m.

    Tienes mucha razón, la verdad es que compilar no se nota nada, yo ayer me pegué el trabajo de optimizar un nucleo para mi core2 duo y la diferencia de velocidad es ridícula! quité el soporte de radio, del puerto de juegos, de puerto paralelo, de isdn, de ppp, de tabletas digitalizadoras .. cientos de cosas que ya casi ni recuerdo, y aparte de que me costó un rato enorme (y tener que borrar algunos paquetes al vuelo porque me estaba quedando sin espacio), luego al reiniciar el resultado fue prácticamente idéntico. Comprobé con uname -r que el kernel usado era el custom y efectivamente así lo era.

    A los que tengáis ubuntu con un core2, y penséis que vais a arrancar el pc más rápido por compilar, ni os lo penséis, el precompilado va de maravilla

    ResponderEliminar
  16. Hola enhorabuena por el artículo. Lo leí en el foro de linuxmint y me ha convencido para no volver a compilar núcleos…

    ResponderEliminar
  17. Anónimo6:12 p. m.

    si pero.....no crees que para obtener la version mas estable del kernel en una distribucion linux tienes que compilarlo por tu cuenta?
    las versiones mas recientes traern mejoras e rendimieto, soporte de hardware y parches de seguridad cuando las distros como ubuntu por ejemplo no se mueven de la misma version, la 14.04 trae el kernel 3.13 no? cuando ahora esta la version 3.17.2 y en el gestor de actualizaciones NADA! no aparece nada!!!

    instale un kernel precompilado los .deb en la pagina oficial y me daba errores de sonido graficos etc. asi que A COMPILAR!

    ResponderEliminar