Ich halte nicht viel davon, theoretische Disskussionen zu führen. Das ist auch bei Schedulern der Fall. Ich bin auch nicht gegen Provokationen. Richtig eingesetzt dienen sie dazu, die eigene Meinung relativ eindeutig darzustellen. Wenn man sich die berühmt/berüchtigten Mail von Linus durchliest, dann ist die Auseinandersetzung hier noch reines Werfen mit Wattebällchen. Ich erinnere an die Diskussionen zu ext4 und btrfs und bestimmete Sachen wie das Verhalten von Commits und Journaling. Die Worte von Linus wahren wohl braindead, bullshit uä. Das mag nicht jeder mögen, aber es wurde was bewegt.
Man wird bei Real-Time-Verarbeitung immer relativ viel Verlust im Durchsatz haben. Dadurch, dass ich auf jeden Fall zu einer genau definierten Zeit einen bestimmten Prozess ansprechen und ausführen muss, um Echtzeit zu erreichen, blocke ich alle anderen Prozesse, die dieser Priorität im Weg stehen. Die tatsächlichen Messungen und theoretischen Hintergünde sind recht eindrucksvoll. Die praktische Auswirkung auch. In Kürze: Der Desktop und alle anderen Anwendungen profitieren durch das Scheduling ganz gewaltig, der Durchsatz sinkt drastisch, was man bei den Datenmengen auf einem Desktop aber nicht merkt. Im Serverbereic führt an CFS nichts vorbei. Der Prozess, der wirklich arbeiten muss, bekommt die meiste Rechenleistung, was auch sehr sinnvoll ist. Leider führt das dazu, dass Prozesse, die kaum Last erzeugen, unterpriorisiert werden, und das in jedem Fall. Die Prozesse rund um den Desktop gehhören halt dazu. Das führ dann dazu, dass der Desktop nicht rund läuft. Zusammen mit einer Schedulingfrequenz von 300hz default oder noch niedriger macht das keinen Spass. Kolivas stösst mit seinen Überlegungen genau in diese Lücke und verteilt die Rechenzeiten halt kreativ um. Das ist nicht das allein Selig machende, aber im Desktop-Bereich State of Art. Und nur darum geht es.
Wer seine Gewichtung auf Signalverarbeitung setzt, für den sind CFS und BFS sinnlos, dieses Scheduler können vom Design auf keinen Fall die an sie gerichteten Anforderungen erfüllen. Das ist doch aber kein Drama, da man mit Linux, Wissen und Verfügbarkeit vorausgesetzt, die Werkzeuge zur Hand hat, die man geziehlt einsetzen kann, um Probleme zu lösen. Das mag dann jeder für sich tun.
Um ein kleines Beispiel für eine absolute Fehlkonfiguration im Serverbereich zu bringen: RT-Kernel, ext4 mit data=journal auf einem Mailserver mit 100000 Mails stündlich, dazu noch ein KDE mit vollständiger Kontrolle der Sensoren und auf dem Schirm die graphische Auswertung dieser. Und weil die Maschine eh nichts zu tun hat, noch eine größere Datenbank mit der Warenwirtschaft und 100 Conkurrent Usern. (Sorry, ein wenig extrem, aber heftiger fällt mir momentan nichts ein)