Hier, j'ai lu un article sur l'accélération de la vitesse d'Ubuntu. Une suggestion dans l'article consistait à remplacer le planificateur d'E/S par défaut par BFQ , qui, selon l'article, est optimisé pour les performances interactives.
Un article similaire souligne les avantages des performances de bureau lorsque vous utilisez le planificateur de processus BFS .
Les deux planificateurs sont inclus dans de nombreux patchs et autres noyaux connus pour augmenter l'interactivité et les performances des postes de travail (par exemple, linux-pf , liquorix-kernel et linux-ck ).
Ma question est donc la suivante : Compte tenu des efforts d'Ubuntu pour une expérience de bureau exceptionnelle, pourquoi les versions non-serveur de l'OS ne sont-elles pas fournies avec ces ordonnanceurs quand ils ont fait leurs preuves pour être meilleurs en termes de performances interactives?
Plus d'informations sur les deux planificateurs peuvent être trouvées ici:
Réponse rapide:
Explications:
Étant donné que les planificateurs sont des initiatives isolées (c’est-à-dire qu’elles ne sont pas prises en charge par le noyau), le simple fait de les inclure revient à concentrer les utilisateurs sur ces planificateurs (correctif de sécurité, correctif de maintenance, accélération de l’adaptation aux nouvelles versions du noyau, ...). Cela signifie un investissement financier pour un projet qui n’est toujours pas sûr de son existence future.
Ils sont encore assez jeunes. Le meilleur exemple est ce qui est expliqué sur le FAQ de BFS dans "Comment évolutif?".
Derrière les lignes de cette partie nous dit que BFS a des problèmes de performances lorsque vous avez beaucoup de CPU logique. Ce point unique s’applique aux serveurs et aux PC haut de gamme (le nombre de 16 étant donné, cela signifie qu’un simple serveur de 1 000 USD aurait des problèmes de performances avec cela). Donc, vous excluez Ubuntu Server de ce correctif, vous excluez également les configurations physiques bi-CPU qui atteignent maintenant facilement ce nombre.
Ubuntu ne peut pas atteindre la masse s'il utilise un autre planificateur. L'évolutivité gagne la performance.
Comme toujours, avec beaucoup de "si" ...:
En fait, la meilleure approche est la solution actuelle: laissez l’utilisateur appliquer les planificateurs qu’il souhaite s’il dispose du matériel et s’y intéresse.
L’appliquer peut fonctionner mieux pour certains pendant un certain temps (parce que, comme je l’ai dit, l’évolutivité est un gros problème et l’avenir augmentera le nombre de processeurs). Mais va donner de graves problèmes aux autres.
Sources supplémentaires:
Le lien peut ne pas rester éternellement, voici un article que j'ai trouvé sur BFS sur h-online . C'est le plus officiel que j'ai trouvé. Toutefois, si vous google dur, vous pouvez trouver la vraie déclaration. Je pense que cela peut être sur Kerneltrap.
Voir le troisième paragraphe du titre phénix de l'article. Je vais le citer ici au cas où le lien mourrait:
À l'heure actuelle, l'intégration de BFS dans la branche de développement principale de Linux semble très improbable, car Linus Torvalds a déjà indiqué clairement qu'il ne souhaitait pas conserver plusieurs planificateurs. En outre, les distributeurs Linux ont tendance à préférer une image de noyau unique qui permet d’atteindre des performances optimales sur une grande variété de systèmes sans nécessiter de configuration particulière. Il se peut que les développeurs du CFS améliorent leur planificateur dans les domaines couverts par BFS - un bonus pour la communauté des utilisateurs.
Linus Torvalds Fil à ce sujet.