Warum sind die BFQ- und BFS-Scheduler nicht im offiziellen Ubuntu-Kernel enthalten?

Gestern las ich einen Artikel über die Beschleunigung von Ubuntu. Ein Vorschlag im Artikel war, den Standard-E / A-Scheduler durch BFQ zu ersetzen , der laut Artikel für die interaktive Leistung optimiert ist.

In einem ähnlichen Artikel werden die Vorteile der Desktop-Leistung bei Verwendung des BFS- Prozess-Schedulers hervorgehoben.

Beide Scheduler sind in zahlreichen Patchsets und alternativen Kerneln enthalten, von denen bekannt ist, dass sie die Desktop-Interaktivität und -Performance steigern (z. B. Linux- PF , Liquorix-Kernel und Linux-CK ).

Meine Frage lautet also : Wie kommt es angesichts des Strebens von Ubuntu nach einem großartigen Desktop-Erlebnis dazu, dass die Nicht-Server-Builds des Betriebssystems nicht mit diesen Schedulern geliefert werden, wenn sich herausgestellt hat, dass sie in Bezug auf die interaktive Leistung besser sind?

Weitere Informationen zu den beiden Schedulern finden Sie hier:

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

Schnelle Antwort :

1. Beide Scheduler funktionieren nicht oder nicht für alle unterstützten Linux-Plattformen (Häufigkeit, Architektur, Ressourcenverbrauch, ...)
2. Es scheint, dass Torvalds einfach nicht mehr als einen Scheduler unterstützen möchte

Erklärungen:

Da es sich bei den Schedulern um eigenständige Initiativen handelt (vom Kernel auch nicht unterstützt), bedeutet die bloße Einbeziehung, die Mitarbeiter auf diese Scheduler zu konzentrieren (Sicherheitspatch, Wartungspatch, schnellere Anpassung an neue Kernel-Releases, ...). Dies bedeutet eine finanzielle Investition für ein Projekt, dessen Existenz in Zukunft noch ungewiss ist.

Sie sind noch ziemlich jung. Das beste Beispiel ist, was in den FAQ von BFS unter "Wie skalierbar ist es?" Erklärt wird.

Hinter den Zeilen dieses Teils steht, dass BFS Leistungsprobleme hat, wenn Sie viel logische CPU haben. Dieser einzelne Punkt gilt für Server und High-End-PCs (die Zahl 16 bedeutet, dass ein einfacher 1000-USD-Server Leistungsprobleme mit sich bringen würde). Wenn Sie Ubuntu Server von diesem Patch ausschließen, schließen Sie auch physische Doppel-CPU-Konfigurationen aus, die diese Zahl jetzt problemlos erreichen.

Ubuntu kann keine Massen erreichen, wenn sie einen anderen Scheduler verwenden. Skalierbarkeit gewinnt über Leistung.

Wie immer bei vielen "wenn" ...:

• Wenn jeder Benutzer von Ubuntu ein Desktop-Benutzer ist
• Wenn jeder Rechner eines jeden Ubuntu-Benutzers der richtige PC für den Scheduler ist

Tatsächlich ist der beste Ansatz der aktuelle: Lassen Sie den Benutzer die gewünschten Scheduler anwenden, wenn er über die Hardware verfügt und daran interessiert ist.

Die Anwendung könnte für einige Zeit besser funktionieren (da, wie gesagt, die Skalierbarkeit ein großes Problem darstellt und die Anzahl der Prozessoren in Zukunft zunehmen wird). Aber wird anderen ernsthafte Probleme bereiten.

Zusätzliche Quellen:

Der Link kann nicht für immer bleiben, hier ist ein Artikel, den ich über BFS auf h-online gefunden habe . Es ist das offiziellste, das ich gefunden habe. Wenn Sie jedoch hart googeln, finden Sie möglicherweise die echte Aussage. Ich denke, es kann auf Kerneltrap sein.

Siehe dritter Absatz des Phoenix-Titels des Artikels. Ich zitiere es hier, falls der Link stirbt:

Die Integration von BFS in den Hauptentwicklungszweig von Linux erscheint derzeit sehr unwahrscheinlich, da Linus Torvalds bereits klargestellt hat, dass er nicht mehrere Scheduler verwalten möchte. Darüber hinaus bevorzugen die Linux-Distributoren in der Regel ein einzelnes Kernel-Image, das auf einer Vielzahl von Systemen eine optimale Leistung erzielt, ohne dass eine spezielle Konfiguration erforderlich ist. Es könnte sein, dass die CFS-Entwickler ihren Scheduler in den von BFS abgedeckten Bereichen verbessern - ein Bonus für die Benutzergemeinschaft.

Linus Torvalds Thread darüber.