Brainf*ck - weil ich es mir wert bin!

Es war einmal vor vielen, vielen Monden, da schickte sich ein Anaesthesist aus Kanada an, zwischendurch - als Hobby - den Linux-Kernel zum Besten zu machen, was einen modernen Multimedia-Desktop antreiben kann. Die aeltesten und weisesten der LUG-Staemme erinnern sich noch dunkel an das sagenumwitterte "ck-Patchset", das bis zum Jahre 2007 des Herrn den staunend-verzückten Pinguinen kürzere Anwendungsreaktionszeiten, mehr Frames pro Sekunde beim Killerspielen und weniger Knacksen und Aussetzer beim Musikspielen brachte.

Doch dann, eines folgenschweren Tages, wollten Con Kolivas' - so der Name unseres tragischen Helden - durchlauchte Patches abermals nicht von den Linux-Kernelhuetern in den Olymp des Mainline-Kernels aufgenommen werden! Und in gerechtem, brennendem Zorn zerbrach er die zarte Bande, die zwischen ihm und der Linux-Gemeinschaft sich gebildet hatte, und die Desktop-Pinguine trauerten tief…

Doch fürchtet euch nimmer! Die dunklen Zeiten sind vorbei! Con Kolivas ist zurueck - und mit sich bringt er die Freifahrkarte ins gelobte Land: den Brain Fuck Scheduler!

-- Schnitt --

Ich habe mich ja selbst einige Zeit (viele Monate eigentlich) dagegen gestraeubt, den BFS-Patch auszuprobieren, weil ich einfach nicht glauben wollte, dass die Wahl des CPU-Schedulers einen gewichtigen, spuerbaren Einfluss auf meinen GNU/Linux Desktop haben koennte - und das, obwohl ich frueher durchaus auf das oben erwaehnte ck-Patchset zu schwoeren pflegte.

Meine Ignoranz ging sogar so weit, dass ich kuerzlich die Frechheit besasz, wieder auf die ungepatchte Variante, "pure Vanilla" also, umzusteigen, und dem BFS den Ruecken zu kehren. Gleichzeitig mit einem Update auf Qt 4.6.1 und KDE 4.4.00.

Seitdem habe ich mich gruen und blau geaergert - KDE war ploetzlich so langsam, der Bildaufbau zaeh, "alles wie Kaugummi hier!!1!".

Tja. Jetzt weisz ich, woran es gelegen hat. Ihr kommt aber vermutlich auch drauf, ohne dass ich es explizit ausspreche

Hausaufgabe fuer die ganz Braven also: FAQ lesen, patchen, kompilieren, ausprobieren! Ich wette, ihr werdet nicht enttauscht sein. Steak-sauce awesome!



PS: Ultrakurzanleitung zum Laden und Patchen der momentan aktuellen (2.6.32.8) Stable-Sources:

Code:

wget -O- http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.32.8.tar.bz2 | tar xvj -C /usr/src/
cd /usr/src/linux-2.6.32.8/
wget -O- http://ck.kolivas.org/patches/bfs/2.6.32-sched-bfs-313.patch | patch -p1

Dann noch Sourcen konfigurieren, kompilieren, installieren - booten, fertig.

Ich hatte alle RCs ab 2.6.33-rc4 schon drauf, und kein einziger kam bei mir an die "Geschmeidigkeit" von 2.6.32 mit BFS heran. Im Gegenteil, ich persoenlich bin bisher eigentlich ziemlich enttaeuscht von 2.6.33 (mein System hat in rc4 einen schweren Bug getriggert, und auch der aktuellste RC OOPSt bei mir ab und zu - einen entsprechenden Eintrag gibt es zwar im Bugtracker, aber Loesung zeichnet sich noch keine ab).

Ich verwende auch reiserfs, allerdings nur fuer /usr/portage - und auf diesem FS tut sich nicht viel. Ich hab uebrigens lediglich voluntary preemeption, nicht forced.

reiserfs ist bei mir für die wesentlichen Teile von / zuständig. Ich hab derzeit einen 2.6.33 zen-BFS kernel laufen, mit den folgenden Parametern:

Code:

CONFIG_SCHED_BFS=y
CONFIG_SCHED_BFS_AUTOISO=y
CONFIG_SLQB=y
CONFIG_IOSCHED_SIO=y
CONFIG_X86_MARCH_NATIVE=y
CONFIG_PREEMPT_VOLUNTARY=y

Interessant wird besonders wie sich das System unter I/O Load verhält - im normalen Betrieb bilde ich mir ein eine leichte Verbesserung zu spüren. Aber wie gesagt, der große Boost kam bei mir schon mit dem Wechsel zu 2.6.33.

weil ich grade seh, dass in den zen-sources auch die phc-patches drin sind:
verwendet irgendjemand die phc-patches mit einem core2? bringt das wirklich noch was?

Wird grad gebaut! Bin schon gespannt wenn alle so davon schwärmen.

Ich werd den BFS mal auf einem Pentium-M Notebook installieren, wo in kde4 die Menues usw. schon ziemlich laggy sind.

Hab gerade seit Ewigkeiten wieder einen eigenen Kernel gebacken.

Der stable Kernel mit BFS Patch hat nun den Ubuntu default kernel verdrängt, ich frage mich nur was nun alles nicht mehr funktioniert...

Gefühlt rennt das System nun einen Tick schneller, kann aber auch einfach daran liegen, dass der selfmade Kernel besser an die Hardware angepasst ist als ein 0815 Kernel.