BFQおよびBFSスケジューラーが公式のUbuntuカーネルに含まれないのはなぜですか？

昨日、Ubuntuの高速化に関する記事を読みました。この記事では、デフォルトのI / OスケジューラーをBFQに置き換えることを提案しました。

同様の記事で、BFSプロセススケジューラを使用した場合のデスクトップパフォーマンスの利点が指摘されています。

両方のスケジューラは、デスクトップの対話性とパフォーマンスを向上させることが知られている多数のパッチセットと代替カーネルに含まれています（例：linux-pf、liquorix-kernelおよびlinux-ck）。

だから私の質問は次のとおりです。Ubuntuが優れたデスクトップ体験のためにどのように努力しているかを考えると、対話型パフォーマンスの点で優れていることが証明されたOSの非サーバービルドにこれらのスケジューラが付属しないのはなぜですか？

2つのスケジューラの詳細については、次を参照してください。

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

素早い回答 ：

1. 両方のスケジューラーがまったく機能しないか、Linuxのサポートされているすべてのプラットフォーム（周波数、アーキテクチャー、リソース消費など）で正常に動作します
2. Torvaldsは単に複数のスケジューラーをサポートしたくないようです

説明：

スケジューラは単独のイニシアチブ（カーネルではサポートされていない）であるため、それを含めるための単なる事実は、それらのスケジューラ（セキュリティパッチ、メンテナンスパッチ、新しいカーネルリリースへの適応の高速化など）に人々を集中させることを意味します。これは、プロジェクトが将来存在するかどうかまだ不明なプロジェクトへの金融投資を意味します。

彼らはまだかなり若いです。最良の例は、BFS のFAQで「どれだけスケーラブルですか？」で説明されているものです。

この部分の裏には、論理CPUが大量にある場合にBFSにパフォーマンスの問題があることが示されています。この単一のポイントは、サーバーとハイエンドPCに対応します（16の数字が与えられているため、単純な1000米ドルのサーバーではパフォーマンスの問題が発生します）。したがって、このパッチのUbuntu Serverを除外し、この数に簡単に到達する物理的なbi CPU構成も除外します。

Ubuntuは、別のスケジューラを使用する場合、大衆に到達できません。スケーラビリティがパフォーマンスよりも優先されます。

いつものように、多くの「if」で...：

• Ubuntuのすべてのユーザーがデスクトップユーザーである場合
• 各Ubuntuユーザーのすべてのマシンがスケジューラーの正しいPCである場合

実際、最良のアプローチは現在のアプローチです。ハードウェアがあり、それに興味がある場合は、ユーザーが望むスケジューラを適用できます。

それを適用することは、しばらくの間より良く機能するかもしれません（私が言ったように、スケーラビリティは大きな問題であり、将来はプロセッサの数を増やすためです）。しかし、他の人に深刻なトラブルを与えます。

追加ソース：

このリンクは永遠に続くとは限りません。これは、h-onlineで BFSについて見つけた記事です。私が見つけた最も公式なものです。ただし、一生懸命グーグルで検索すると、実際のステートメントが見つかる場合があります。カーネルトラップ上にあると思います。

記事の不死鳥のタイトルの3番目の段落を参照してください。リンクが切れた場合に備えて、ここで引用します。

現在、BFSのLinuxメイン開発ブランチへの統合は、Linus Torvaldsが複数のスケジューラーを維持したくないことをすでに明らかにしているため、ほとんどありそうにないようです。さらに、Linuxディストリビューターは、特別な構成を必要とせずにさまざまなシステムで最適なパフォーマンスを実現する単一のカーネルイメージを好む傾向があります。CFS開発者は、BFSの対象地域でスケジューラを改善する可能性があります。これはユーザーコミュニティにとってのボーナスです。

Linus Torvalds氏のスレッドそれについて。