Welcome, Guest. Please login or register.
Did you miss your activation email?

Author Topic: [DE] Quasi-Realtime mit BFScheduler per ck-patch  (Read 22308 times)

Offline ralul

  • User
  • Posts: 1.814
[DE] Quasi-Realtime mit BFScheduler per ck-patch
« on: 2010/10/10, 13:24:54 »
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.
experiencing siduction runs better than my gentoo makes me know I know nothing

mylo

  • Guest
Realtime Kernel ist Schwachsinn für Desktop User
« Reply #1 on: 2010/10/10, 17:10:21 »
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.

Offline ralul

  • User
  • Posts: 1.814
Re: Realtime Kernel ist Schwachsinn für Desktop User
« Reply #2 on: 2010/10/10, 20:17:21 »
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?

@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.
experiencing siduction runs better than my gentoo makes me know I know nothing

Offline devil

  • Administrator
  • User
  • *****
  • Posts: 4.838
Re: Realtime Kernel ist Schwachsinn für Desktop User
« Reply #3 on: 2010/10/10, 21:19:55 »
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

  • Guest
Re: Realtime Kernel ist Schwachsinn für Desktop User
« Reply #4 on: 2010/10/10, 23:00:06 »
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.


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 ;)

Offline ralul

  • User
  • Posts: 1.814
Re: Realtime Kernel ist Schwachsinn für Desktop User
« Reply #5 on: 2010/10/11, 00:18:04 »
Quote from: "devil"
solange der BFS scheduler nicht mainline ist, ist er für uns uninteressant.

Aber auch keiner von den im slh Kernel integrierten staging Treibern ist Mainline.

Quote from: "DonKult"
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.
Der "BFS" Patch wird schon portiert und getestet auf 2.6.36, also ziemlich aktuell. Und ein neues Feature des BFS soll Einzug halten: Bestrafung von Threads, die viel forken.
Quote
und natürlich wird der CFS konstant weiterentwickelt wodurch natürlich auch nichts älter ist als der Benchmark von gestern…
Der Mainline CFS hat im letzten Jahr tatsächlich enorm aufgeholt durch die Anstöße, die Kolivas durch seine Demontration gegeben hat! Das war auch der Grund, warum ich zurückhaltend war das letzte Jahr den BFS zu forden, denn vielleicht holte der CFS Scheduler den BFS ja ein? Aber je tiefer man in die Materie einsteigt, desto klarer wird, der CFS ist für Großrechner mit vielen Kernen gemacht. Deswegen ist er auch viel komplizierter als der BFS Scheduler. Schon deswegen spart der BFS einige Ticks ein und hält den Rechner kühler - siehe unten.

Quote
meisten Anwender sind duo und quad-core Rechner ja bereits Standard
Erst ab mehr als 16 cores kann der Mainline CFS besser sein als der BFS Scheduler.

Quote
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…

Man merkt es schon, jedenfalls beim 2.6.35er Kernel. Ich habe den neuen 36 Kernel ohne BFS schon getestet, er schein performanter zu werden! Besonders an den IO Operationen scheint gearbeitet worden zu sein. Es gibt ja schon längere Zeit auch die Patches für die IO Queue, die im ZEN Kernel benutzt werden. Das Thema IO ist aber so enorm viel komplizierter als der kleine Task Scheduler im Kernel, dass ich das links liegen lasse.

Man kann Performance übrigens ganz esoterisch durch Handauflegen messen: Das Gerät bleibt kühler mit BFS. Die vielen erziehlten Micro-Sleeps sparen Strom. Deswegen ist BFS besonders für mobile Benutzer interessant.

Code: [Select]
Auf jeden Fall schlechter getestet als der CFSKolivas erzählt in seinem Blog, dass er von einem Fall gehört hat, dass ein Android Hersteller intern BFS getestet hat und wegen keinerlei positiver Wirkung außen vor ließ. Dies fiel in eine Phase, in der sein BFS Feature für Mono Core wirkungslos blieb, weil er, Kolivas, keine Testrückmeldungen für diese Architektur bekommen hatte:
http://ck.kolivas.org/patches/bfs/2.6.31/2.6.31.14-bfs-315-316.patch

...Testen ist ja gerade die Aufgabe von Debian unstable Benutzern...

Und ich gehe immer noch jede Wette ein, dass die "Plugin" Architektur für Kernel Scheduler kommen wird und Linus seine Meinung wieder um 180
Grad dreht....
Oder aber Linus Thorwalds will sich die Entwicklung offen halten, weil er selbst unsicher ist wohin die Reise geht. Wenn er eine Plugin Architektur für den Scheduler offiziös akzeptierte, wäre das eine Verpflichtung für die Zukunft, die ihn in seinen Entscheidungen binden und einschränken könnte.
experiencing siduction runs better than my gentoo makes me know I know nothing

Offline ralul

  • User
  • Posts: 1.814
Bfs bleibt wie es war
« Reply #6 on: 2010/10/11, 14:48:47 »
BFS für Kernel 2.6.36
Das geplante neue Feature der Bestrafung von forking Threads ist auf Eis gelegt worden nach Tests von Arch Usern
Quote from: "Kolivas"
These sorts of bugs, although likely due to the userspace application itself, make changes of this nature in the scheduler as the default impossible, or at least foolish. So as much as I'd like to see this change go into the next -ck release and be the default, I can't.
...
But now I can relax and just sync up with mainline again when 2.6.36 final comes out.
experiencing siduction runs better than my gentoo makes me know I know nothing

Offline agaida

  • User
  • Posts: 1.760
    • http://g-com.eu
Bfs bleibt wie es war
« Reply #7 on: 2010/10/12, 17:55:44 »
Ich habe den 2.6.35 mit und ohne CK in Arch. getestet. CK bleibt mein Favorit. Im Lastbereich wirds geringfügig langsamer, dafür ist der gesamte Desktop auch bei Vollast noch wunderbar zu bedienen. Da nehme ich etwas geringeren throughput gern in Kauf. Obwohl ich zugeben muss, dass der 2.6.35 aufgeholt hat.
There's this special biologist word we use for "stable". It's "dead". ~ Jack Cohen

Offline RoEn

  • User
  • Posts: 219
Bfs bleibt wie es war
« Reply #8 on: 2010/10/12, 20:35:20 »
ralul, imposant Dein Wissen. :-)
naja...

RoEn

Offline devil

  • Administrator
  • User
  • *****
  • Posts: 4.838
Bfs bleibt wie es war
« Reply #9 on: 2010/10/12, 21:05:55 »
'wissen' im bereich kernel ist ein heikler begriff.
halbwissen führt da schnell zu falschen schlussfolgerungen.
ich selbst bin weit davon entfernt, mir in sachen kernel wissen zu attestieren.

greetz
devil

Offline ralul

  • User
  • Posts: 1.814
Bfs bleibt wie es war
« Reply #10 on: 2010/10/12, 21:18:01 »
@agaida, interessantes Feedback. Sehe ich auch so.

Ich fände ja eine "statistische" Performance Messung interessant. Das ist jetzt ein Gedanke von mir:

Die traditionellen Performancetest versuchen mit möglichst gleichen Voraussetzung möglichst genau zu messen. Dabei müssen diese Test sich auf bestimmte Anwendungen einschränken. Zum Beispiel die berüchtigten Phoronix Tests machen in ihrer Auswahl immer das Gleiche. Dabei gibt es aber die Einschränkung, dass bei geringen Abweichungen der Versuchsanordnung falsche Ergebnisse herauskommen. Macht sich der Versuchsleiter zB nicht die Mühe immer auf dem gleichen Rechner alles gleich und neu zu installieren, sind Vergleiche hinfällig, wenn die Anordnung auf der Festplatte eine Rolle spielt, weil unterschiedliche Plätze auf einer traditionellen HD unterschiedliche IO Performance ergeben.

Dagegen Statistik:
Bei hunderten, tausenden Teilnehmern spielt nichts Besonderes mehr eine Rolle. Gemessen wird nur der statistische Trend.

Wenn soviele Benutzer, besonders hier bei aptosid, dabei sind, die den Fortschritt von Opensource unterstützen wollen, sollte es dann nicht möglich sein bei uns die Teilnahme an einem ausgefeilten statistischen Performancemessungsprogramm zu erreichen?

Es sollte so einfach wie popcon zu installieren sein, und Ergebnisse zeigen, wie zB:
- nach Einspiel von linux-image-2.6.36-1.slh.0 Verbesserung
- nach Einspiel von linux-image-2.6.36-1.slh.1 Verschlechterung
- nach Einspiel von linux-image-2.6.36-bfs357  Verschlechterung
oder zB, Benutzer von amarok haben einen viel höheren Stromverbrauch als Benutzer von audacious ....etc

Was meint ihr?
Klar müsste man auf Datenschutz achten, vielleicht anonymisiert, damit keine Trojanerhersteller Angriffspunkte ausspähen können...
experiencing siduction runs better than my gentoo makes me know I know nothing

Offline brummer

  • User
  • Posts: 276
    • http://guitarix.sourceforge.net/
Bfs bleibt wie es war
« Reply #11 on: 2010/10/12, 21:35:11 »
Ich nutze nur den realtime kernel, ich bin Musiker. Deinen Vorstoß hier finde ich Schwachsinn. Du weißt wahrscheinlich das der rt patch schon seit einigen Jahren in den Mainline Kernel eingepflegt wird, das finde ich persönlich sehr gut.
Der BFS patch würde mir den zugang zu rt rechten in IRQ Bereich verschließen, was verschließt dir im Gegenzug der rt patch? Bedenke bitte das es Anwender mit anderen Anforderungen gibt als deine. Deine Überschrift ist u.a.s.

Offline ralul

  • User
  • Posts: 1.814
Bfs bleibt wie es war
« Reply #12 on: 2010/10/12, 22:13:13 »
Naja, ich hatte geschrieben "Schwachsinn für Desktop Benutzer" nicht Musiker.
Aber ganz davon abgesehen, mit RT musst Du sehr fein justieren, und wenn Du zusätzlich Video editieren willst, sieht es wieder anders aus. C.Kolivas behauptet, dass kaum einer die Feinjustierung, die notwendig ist, hinbekommen kann um wirkliche Vorteile zu haben. Mit dem BFS hättest Du sehr einfach quasi Realtime, wenn Du das schedtool benutzt. Hast Du den Link zum Blog dazu ganz gelesen?
experiencing siduction runs better than my gentoo makes me know I know nothing

Offline devil

  • Administrator
  • User
  • *****
  • Posts: 4.838
Bfs bleibt wie es war
« Reply #13 on: 2010/10/12, 22:20:23 »
Quote

C.Kolivas behauptet....

ich kanns nicht mehr hören.

greetz
devil

Offline brummer

  • User
  • Posts: 276
    • http://guitarix.sourceforge.net/
Re: Bfs bleibt wie es war
« Reply #14 on: 2010/10/12, 22:30:22 »
Quote from: "devil"
Quote

C.Kolivas behauptet....

ich kanns nicht mehr hören.

greetz
devil


Dito, Raul, was glaubst du denn warum Musiker den rt-patch benutzen, etwa weil sie zu doof sind Ihn auch anzuwenden/auszunutzen ?

Im übrigen habe ich hier gerade die rt vergabe für IRQ's angesprochen, und nicht das scheduling. Zum rt-patch gehört ein bisschen mehr als "nur" der scheduler.

Und "schwachsinn" ist der rt-patch für niemanden außer für dich, allerhöchstens wirkungslos wenn man nicht mit ihm umgehen kann, das kann man vom BFS allerdings nicht behaupten. :idea: