Siduction Forum > Scripting & Kernelhacking

[DE] Quasi-Realtime mit BFScheduler per ck-patch

(1/12) > >>

ralul:
Vor Kurzem hat Con Kolivas ein neues Blog angefangen, in dem er wunderbar den Unterschied seines BFS-Schedulers zum Realtime-Kernel erklärt:
http://ck-hack.blogspot.com/2010/10/bfs-in-real-time.html

Seiner Meinung nach sollten nur Spezialisten, die wirklich was verstehen vom Kernel Hacken, die Realtime Patches für den Linux Kernel benutzen: Die für optimale Arbeit notwendigen speziellen Justierungen der Konfig seien zu kompliziert, als dass ein normaler User damit Profit für seine Arbeit erhält. So ist zB beim Video Editieren, im Gegensatz zum reinen Audio Editieren, darauf zu achten, dass noch genügend Durchlauf (Load throughput) möglich ist. Sein BFS Scheduler dagegen sei sofort optimal einsetzbar.

Einen Artikel früher spricht er sich gegen die Angewohnheit der Mainline Kernelhacker aus, ihren Scheduler nur gegen Heavy-Load zu optimieren. Das kommt bei modernen PCs nur seltenst vor und vermindert aber den Load-Troughput: Er hat einen speziellen Demo Test Patch bereit gestellt, der die Maus des Benutzers auch noch bei Overload bereitwillig ohne Verzögerung bewegen lässt, aber zur Folge hat, dass 20 Prozent weniger Durchlauf vonstatten gehen kann.

mylo:
Hi ralul,

interessant, aber die headline könnte sachlicher formuliert sein (hatten wir uns ja alle vorgenommen).

Was regt sich in Dir auf? Was ist Dein (bestimmt interessanter) Punkt?

Laß uns teilhaben (auch die Nicht-Hacker und Nixperten)...gern auf deutsch. Schlechtes Englisch macht nichts klarer oder deutlicher.

ralul:

--- Quote from: "mylo" ---interessant, aber die headline könnte sachlicher formuliert sein (hatten wir uns ja alle vorgenommen).

Was regt sich in Dir auf? Was ist Dein (bestimmt interessanter) Punkt?
--- End quote ---

@mylo, ich hatte hier im letzten Forum keine Reaktionen auf meine Kern Gedanken, deswegen die Provo-Überschrift :)

Aber was ist dran: Das Konzept des BFS-Scheduler von Kolivas ist so einleuchtend, der Gedanke von Linus Thorwalds, dass ein Scheduler alles abdecken kann, vom Handy bis zum Supercomputer, dies ist so absurd, dass ich mich wundere, warum so wenig Distributionen (PCLinuxOS) diesen BFS Desktop-User-Scheduler einsetzen. Stattdessen werden manchmal hochkomplizierte Realtime Patches eingesetzt, die niemand richtig bedienen kann. Das alles erklärt der Link zum Kolivas Blog...

Eigentlich auch enttäuschend, dass slh keinen Versuch macht in dieser Richtung. Klar, der Nachteil wäre, dass aptosid nicht mehr optimal auf einem 128cpu Server läuft, aber alle anderen und besonders Notebook Benutzer (durch mehr Kernschlaf ist der Scheduler stromsparend) hätten nur Vorteile.

devil:
solange der BFS scheduler nicht mainline ist, ist er für uns uninteressant.
man kann viel spekulieren und lesen, ordentlich testen ist etwas ganz anderes.

greetz
devil

DonKult:

--- Quote from: "ralul" ---Eigentlich auch enttäuschend, dass slh keinen Versuch macht in dieser Richtung. Klar, der Nachteil wäre, dass aptosid nicht mehr optimal auf einem 128cpu Server läuft, aber alle anderen und besonders Notebook Benutzer (durch mehr Kernschlaf ist der Scheduler stromsparend) hätten nur Vorteile.
--- End quote ---


Ganz davon abgesehen, dass der wirkliche Vorteil der slh Kernels flöten geht: Immer am aktuellen Mainline dran zu sein, den der BTS Patch ist wohl kaum immer kompatibel zum aktuellen Stand. Auf jeden Fall schlechter getestet als der CFS und natürlich wird der CFS konstant weiterentwickelt wodurch natürlich auch nichts älter ist als der Benchmark von gestern…

Davon abgesehen hatte towo ja bereits von Problemen bei sich mit dem BTS berichtet, für die meisten Anwender sind duo und quad-core Rechner ja bereits Standard und schlussendlich halte ich es persönlich für recht unwahrscheinlich, dass der normale Anwender überhaupt irgendetwas spüren wird, was nicht mit dem Placeboeffekt zu erklären ist…
Ich kenne z.B. auchh keine openmoko Distribution die den BTS verwendet, obwohl man bei einem schwachbrüstigen ARMv4 400 MHz CPU ja was bemerken sollte, wenns denn was zu bemerken gäbe…

Einbildung ist ja bekanntlich auch 'ne Bildung ;)

Navigation

[0] Message Index

[#] Next page