¿Por qué los planificadores BFQ y BFS no están incluidos en el kernel oficial de Ubuntu?

Ayer leí un artículo sobre cómo acelerar Ubuntu. Una sugerencia en el artículo fue reemplazar el programador de E / S predeterminado con BFQ , que según el artículo está optimizado para un rendimiento interactivo.

Un artículo similar señala las ventajas en el rendimiento del escritorio cuando se usa el programador de procesos BFS .

Ambos planificadores están incluidos en numerosos conjuntos de parches y núcleos alternativos que se sabe que aumentan la interactividad y el rendimiento del escritorio (por ejemplo, linux-pf , liquorix-kernel y linux-ck ).

Entonces mi pregunta es : dado que Ubuntu se esfuerza por lograr una excelente experiencia de escritorio, ¿cómo es que las compilaciones del sistema operativo que no son del servidor no vienen con estos programadores cuando se ha demostrado que son mejores en términos de rendimiento interactivo?

Puede encontrar más información sobre los dos programadores aquí:

• BFQ : http://algo.ing.unimo.it/people/paolo/disk_sched/
• BFS : http://ck.kolivas.org/patches/bfs/bfs-faq.txt

Respuesta rápida :

1. Ambos planificadores no funcionan en absoluto o funcionan bien para todas las plataformas compatibles de Linux (frecuencia, arquitectura, consumo de recursos, ...)
2. Parece que Torvalds simplemente no quiere soportar más de un programador

Explicaciones:

Dado que los planificadores son iniciativas por sí solas (alias no compatibles con el núcleo), el simple hecho de incluirlo significaría centrar a las personas en esos planificadores (parche de seguridad, parche de mantenimiento, acelerar la adaptación a las nuevas versiones del núcleo, ...). Significa inversión financiera para un proyecto que todavía no está seguro de su existencia en el futuro.

Todavía son bastante jóvenes. El mejor ejemplo es lo que se explica en las preguntas frecuentes de BFS en "¿Qué tan escalable es?".

Detrás de las líneas de esta parte nos dice que BFS tiene problemas de rendimiento cuando tienes mucha CPU lógica. Este único punto se aplica a los servidores y PC de alta gama (se da el número de 16, por lo que significa que un servidor simple de 1000 USD tendría problemas de rendimiento con esto). Por lo tanto, excluye Ubuntu Server de este parche, también excluye las configuraciones físicas de CPU bi que ahora alcanzan fácilmente este número.

Ubuntu no puede llegar a las masas si usan otro planificador. La escalabilidad gana al rendimiento.

Como siempre, con muchos "si" ...:

• Si cada usuario de Ubuntu es un usuario de escritorio
• Si todas las máquinas de cada usuario de Ubuntu son la PC correcta para los planificadores

De hecho, el mejor enfoque es el actual: deje que el usuario aplique los planificadores que desee si tiene el hardware y está interesado en él.

Aplicarlo puede funcionar mejor para algunos durante algún tiempo (porque, como he dicho, la escalabilidad es un gran problema y el futuro incrementará la cantidad de procesadores). Pero dará graves problemas a los demás.

Fuentes extra:

El enlace puede no quedarse para siempre, aquí hay un artículo que encontré sobre BFS en h-online . Es el más oficial que he encontrado. Sin embargo, si buscas en Google, puedes encontrar la declaración real. Creo que puede estar en kerneltrap.

Ver el tercer párrafo del título de Phoenix del artículo. Lo citaré aquí en caso de que el enlace muera:

En la actualidad, la integración de BFS en la rama de desarrollo principal de Linux parece muy poco probable, ya que Linus Torvalds ya ha dejado en claro que no quiere mantener múltiples programadores. Además, los distribuidores de Linux tienden a preferir una sola imagen del núcleo que logre un rendimiento óptimo en una amplia variedad de sistemas sin requerir una configuración especial. Podría ser que los desarrolladores de CFS mejoren su programador en las áreas cubiertas por BFS, una ventaja para la comunidad de usuarios.

Linus Torvalds Hilo al respecto.