La discusión sobre este parche específico tuvo lugar en la lista de correo del equipo kernel de Ubuntu:
https://lists.ubuntu.com/archives/kernel-team/2010-November/013498.html
Pero permítanme tratar de elaborar aún más genéricamente la mejor forma para que cualquier parche llegue al kernel de Ubuntu ...
Primero, es la política preferida del Equipo del Kernel de Ubuntu que los parches se envíen y acepten en sentido ascendente antes de ser incorporados al kernel de Ubuntu. Es una gran carga de mantenimiento para el equipo del kernel de Ubuntu tener que mantener fuera de los parches del árbol. Además, si el parche beneficiará a toda la comunidad de Kernel, primero debería ser ascendente.
Una vez que el parche ha sido aceptado en sentido ascendente, eventualmente llegará al kernel de Ubuntu automáticamente. También se puede realizar una solicitud de selección o extracción si así lo desea, consulte la página, KernelPatches , para obtener más información.
Si el parche debe aplicarse como una SRU ( actualización de versión estable ) a una versión anterior de Ubuntu, es mejor que el parche sea aceptado en el árbol 2.6.xy estable ascendente correspondiente. Como parte de nuestro proceso normal de SRU de kernel, continuamente cambiamos de versión al último kernel estable ascendente. Por lo tanto, nuevamente obtendríamos el parche automáticamente.
Acabo de leer el hilo lkml y espero poder ofrecer alguna información, aunque no se trata de instalar el parche en Ubuntu. Como dice una publicación en la lista de Ubuntu vinculada, de todos modos probablemente estará en 2.6.38.
El parche agrupa automáticamente el proceso basado en TTY. Hay mucha discusión / argumento sobre el lkml que dice que esto significa que no es relevante para el uso típico de escritorio, que no hace ninguna diferencia para las aplicaciones interactivas. Los casos de prueba se basan en "iniciar una tarea intensiva de CPU desde un terminal y luego observar la capacidad de respuesta de otra tarea". Compilando un kernel e intentando ver un video, por ejemplo.
Eso no quiere decir que no sea bueno, pero los titulares generales de "capacidad de respuesta de escritorio mejorada en un orden de magnitud" podrían ser engañosos si nunca ejecuta tareas intensivas de CPU conectadas a un TTY. ¡Pero podría estar equivocado, por supuesto!
Hubo algunas menciones de formas de lograr un resultado muy similar al agregar a sus scripts de bash y permitir que todos los usuarios creen grupos de c. Esto solo funcionará si los núcleos Ubuntu actuales tienen cgroups habilitados. Las publicaciones relevantes son:
Obviamente, esto no responde a la pregunta, pero podría usarse para determinar si el parche es tan mágico como se esperaba.
fuente
El énfasis es mío. La única forma en que lo obtendrá de forma compatible es esperando que Ubuntu lo incorpore al núcleo de Ubuntu. Como esto realmente solo está llegando a la lista de correo del núcleo, es nuevo hasta el punto de que todas las pruebas son bastante anecdóticas e imagino que pasará algún tiempo antes de que esté listo para ser implementado en masa.
En algún lugar entre el próximo lanzamiento y mucho tiempo sería mi suposición sin educación.
Pero si usted es un niño (o niña) grande y puede hacer frente a un núcleo roto si las cosas salen mal (es decir, sabe cómo usar grub), puede parchear y compilar su propio núcleo.
Descargue un parche. Existen diferentes versiones, pero la mejor en sí fue publicada a continuación por otro usuario: http://pavlinux.ru/krnl/sched_autogroup-2.6.36.patch.bz2
Descargue la fuente del núcleo para la versión a la que se dirige su parche. En este caso 2.6.36. Puede obtener fuentes de kernel de vainilla (que es original, no modificado por el equipo del kernel de Ubuntu) de kernel.org y extraerlo.
Guarde el parche en algún lugar y aplíquelo
cdingresando en el directorio de origen del núcleo y ejecutando:patch -p1 < /path/to/patch(necesita elpatchpaquete para esto ... que creo que viene como partebuild-essentialsi no está instalado de manera predeterminada)Y luego continúe con el resto del proceso de compilación "anticuado" ... Realmente no me molestaría con los métodos más nuevos, ya que están dirigidos a fuentes de kernel sancionadas por Ubuntu / Debian ... Además, la forma antigua parece más fácil ( a mi).
Construir núcleos no es difícil, pero puede estropearlo si se desvía demasiado del camino aceptado. Y no obtendrá soporte oficial si las cosas salen mal.
Alternativamente, surgen más y más núcleos con el parche incorporado (o al menos en el árbol de origen, en espera de la próxima versión).
Nota: ambos núcleos (y probablemente otros también) se desvían un poco de la forma en que Ubuntu hace los núcleos. Puede encontrar (como lo hice cuando me mudé a Liquorix) que el escalado de frecuencia de la CPU deja de funcionar o la suspensión se rompe. Por lo general, hay soluciones y soluciones, pero es probable que no obtenga soporte de AskUbuntu o el resto de la comunidad de Ubuntu, ya que no podemos verificar todos los núcleos.
fuente
Puede usar un simple "hack" publicado por un desarrollador de RedHat en una lista de correo, que no requiere parchear el kernel para obtener lo mismo. Lea sobre esto aquí: Alternativa al "parche de kernel de 200 líneas que hace maravillas" que puede usar de inmediato
fuente
A partir del 2011-01-18, Linux 2.6.38-rc1 incluye dicho parche.
Vea las noticias relacionadas de Phoronix y la publicación de Linus .
A partir del 2011-01-29, la compilación diaria de Natty Narwhal se envía con Linux 2.6.38.
Entonces, actualmente hay dos soluciones:
fuente
Acabo de retomar esta discusión ahora y es muy interesante. He escrito una pequeña publicación de blog sobre cómo habilitar el parche cgroup en Ubuntu 10.10.
Realmente no he probado si funciona o no, ¡así que los comentarios serían geniales!
fuente