200 líneas de código para mejorar el rendimiento

Yo prefiero dejar estas cosas para los que saben

Que el peor "virus" de todos es la insensatez propia.

Parece tener buena pinta pero solo es para casos puntuales de mucha carga y multitarea segun veo (cosa que a mi me vendria de maravilla siendo como soy ).

Pero dejaros de experimentos que aun os vendreis luego a quejaros de ello ¬¬.
Si quereis experimentar tener a mano dese grub2 otro kernel estable con el que salir de apuros y seguir con el dia a dia.

Si el codigo proporcionado supera el testeo y se ve viable para uso general sera incorporado en futuras revisiones del kernel. Simple y llanamente, el kernel es algo MUY delicado. No pocos hemos visto hasta 3 o 4 revisiones seguidas de un kernel en un solo dia por temas puntuales y ser impacientes xD

Yo tenía pensado probarlo en una máquina virtual (tomando una snapshot previa) para ver si notaba la mejora, pero todavía no tengo muy claro como hacerlo (estoy MUY verde en temas de núcleo). Lo que tenía claro era que ni de coña lo iba a probar en mi equipo habitual.

No pocos hemos visto hasta 3 o 4 revisiones seguidas de un kernel en un solo dia por temas puntuales y ser impacientes xD

Debeis ser muy muy pocos, si... que yo sepa eso no ha pasado nunca.

- ferdy

PD: Me he comprobado a mano los dos últimos años, porque no tengo a mano un linux-2.6.git, pero creo que desde que se usa Git, no ha ocurrido nunca.

Para los que lo quieran probar no es muy difícil, el parche se aplica bien sobre 2.6.37-rc2, tan solo es cuestión de migrar la configuración (quitando los drivers, la diferencia en la configuración es de 12-15 CONFIG_ nuevos y la mayoría son autoexplicativos) y de ver si los parches especificos de la distro que usen (donde aplique), son compatibles con el .37-rc2, aparte de activar la opción correspondiente: SCHED_AUTOGROUP.

Yo por mi parte no he podido probar este parche más a fondo ya que el .37-rc2 me da algunos problemas con el aufs (probablemente no sea problema del kernel) y con el bluetooth en la fase de udev-settle (systemd se queda casi 2 minutos a que termine ), así que yo espero a un -rc3 o a un backport hacia .36 para probar este parche que se ve prometedor.

El poder del Software Libre

Supongo que para la 2.6.38 se incluirá si todo va bien, pues si ya están con las RCs del .37 no deberían añadir nada nuevo a esta rama.

Muy interesante.

a ver quien será el primer eoliano que lo pruebe.

Informándome un poco más sobre el parche, creo que puedo quitar la palabra "prometedor" de mi ultimo post. En pocas palabras no estoy de acuerdo con Linus de poner una politica automatica de manejo de procesos en el kernel cuando eso deberia ser cosa del userspace, aparte de que por el momento solo hace uso de los procesos iniciados desde una tty para hacer las agrupaciones (para un usuario normal de escritorio que raramente usa el terminal para ejecutar cosas este parche no lo ayuda en nada) y para finalizar creo que probar la eficacia del parche con un benchmark de un make -j64 de las fuentes del kernel (una carga de CPU totalmente ridícula e irreal) no demuestra nada concluyente.

En resumen este parche no tiene nada que ver con mejorar el rendimiento o latencia como hacen ver los medios, el único uso que le veo es evitar que un proceso con múltiples subprocesos (make -j64 o similar ) lanzado desde terminal afecte negativamente el rendimiento de los demás procesos al adueñarse de todo el tiempo de CPU.

En mi caso ya he descartado el usar este parche y voy a seguir usando nice y schedtool en los procesos que generan mucha carga para la CPU para ajustar su prioridad. Ojo, esto es solo mi opinión personal y no vengo a desanimar a los que quieran probar el parche o alternativas en userspace y les resulte bien en su caso de uso especifico. Saludos.

Al parecer lo que hace es mejorar la organización de los procesos agrupándolos.
Si usamos procesos grandes como firefox, video en HD o compilaciones y queremos cambiar de un proceso a otro el kernel distribuye mucho mejor la carga con este nuevo algoritmo, sin notar ese molesto retardo en cambiar de una ventana a otra que se tiene algunas veces.

Para acabar solo matizar que este algoritmo como últimamente viene pasando está optimizado para multi-hilos es decir cuantos mas nucleos y más hyperthread tenga el procesador mejor funcionara, bueno los hyperthread relativamente.

http://www.muylinux.com/2010/11/19/%C2% ... -el-kernel

Donato escribió:http://www.muylinux.com/2010/11/19/%C2%BFrecordais-el-milagroso-parche-de-las-200-lineas-de-codigo-podeis-lograr-lo-mismo-en-2-minutos-sin-parchear-el-kernel

Curiosamente venía a dar esta noticia que acabo de leer. De hecho, según he leido, siguiendo este proceso se consiguen casi mejores resultados. De todas formas, después de lo que ha comentado codestation, he perdido un poco la ilusión por el parche .