BFQおよびBFSスケジューラーが公式のUbuntuカーネルに含まれないのはなぜですか？
昨日、Ubuntuの高速化に関する 記事 を読みました。この記事での提案の1つは、デフォルトのI/Oスケジューラーを BFQ に置き換えることでした。これは、記事によると、インタラクティブなパフォーマンスのために最適化されています。
同様の article は、 BFS プロセススケジューラを使用した場合のデスクトップパフォーマンスの利点を示しています。
両方のスケジューラは、デスクトップの対話性とパフォーマンスを向上させることが知られている多数のパッチセットと代替カーネルに含まれています（例： linux-pf 、 liquorix-kernel および linux-ck ）。
だから私の質問は：Ubuntuが素晴らしいデスクトップ体験のためにどのように努力しているかを考えると、OSの非サーバービルドにはどうしてこれらが付属していないのですか？スケジューラー 証明済み インタラクティブパフォーマンスの点で優れている？
2つのスケジューラの詳細については、次を参照してください。
クイックアンサー：
- 両方のスケジューラーがまったく機能しないか、Linuxのサポートされているすべてのプラットフォーム（周波数、アーキテクチャ、リソース消費など）で正常に動作します
- Torvaldsは単に複数のスケジューラーをサポートしたくないようです
説明：
スケジューラは単独のイニシアチブ（カーネルではサポートされていない）であるため、それを含めるための単なる事実は、それらのスケジューラに集中することを意味します（セキュリティパッチ、メンテナンスパッチ、新しいカーネルリリースへの適応の高速化など）。これは、プロジェクトが将来存在するかどうかまだ不明なプロジェクトへの金融投資を意味します。
彼らはまだかなり若いです。最良の例は、BFSの FAQ で「どれだけスケーラブルですか？」で説明されているものです。
この部分の裏には、論理CPUが大量にある場合にBFSのパフォーマンスの問題があることがわかります。この単一のポイントは、サーバーとハイエンドPCに対応します（16の数字が与えられているため、単純な1000米ドルのサーバーではパフォーマンスの問題が発生します）。したがって、このパッチのUbuntu Serverを除外し、この数値に簡単に到達する物理的なbi CPU構成も除外します。
Ubuntuは、別のスケジューラを使用する場合、大衆に到達できません。スケーラビリティがパフォーマンスよりも優先されます。
いつものように、多くの「if」で...：
- Ubuntuのすべてのユーザーがデスクトップユーザーである場合
- 各Ubuntuユーザーのすべてのマシンがスケジューラーの正しいPCである場合
実際、最善のアプローチは現在のアプローチです。ハードウェアがあり、それに興味がある場合は、ユーザーが望むスケジューラを適用できます。
それを適用することはしばらくの間より良く機能するかもしれません（私が言ったように、スケーラビリティは大きな問題であり、将来はプロセッサの数を増やすためです）。しかし、他の人に深刻なトラブルを与えます。
追加ソース：
リンクは永遠に残るとは限りません。ここに、BFSについて h-online で見つけた記事があります。私が見つけた最も公式なものです。ただし、一生懸命グーグルで検索すると、実際のステートメントが見つかる場合があります。カーネルトラップ上にあると思います。
記事の不死鳥のタイトルの3番目の段落を参照してください。リンクが切れた場合に備えてここで引用します：
現在、BFSのLinuxメイン開発ブランチへの統合は、Linus Torvaldsが複数のスケジューラーを維持したくないことをすでに明らかにしているため、非常に考えにくいようです。さらに、Linuxディストリビューターは、特別な構成を必要とせずにさまざまなシステムで最適なパフォーマンスを実現する単一のカーネルイメージを好む傾向があります。 CFS開発者は、BFSの対象地域でスケジューラを改善する可能性があります。これはユーザーコミュニティにとってのボーナスです。
Linus Torvalds Thread それについて。