Wer Linux benutzt verwendet (in den allermeisten Fällen) einen Kernel mit dem Standard-Scheduler CFS (Completely Fair Scheduler).
Kernel Hacker Con Kolivas hat dem schon vor einiger Zeit ein völlig neues Konzept, den Brain Fuck Scheduler (BFS) entgegengestellt.

Der Grundunterschied der Auswirkungen für den User liegt in der ‘responsiveness’ des Systems. CFS ist darauf ausgelegt auf riesige Maschinen zu skalieren, und unterscheidet dabei nicht zwischen dem normalen Rechner für zu Hause oder einem 4096 CPU Gerät. (Die Zahl 4096 CPUs taucht in der Diskussion als Richtlinie für Skalierbarkeit immer wieder auf.)
Ebensowenig wird meist zwischen dem Einsatzgebiet, Desktop oder eben Server unterschieden. (Es gibt hierfür zwar einige Möglichkeiten in der Kernel Konfiguration, aber wer den Standardkernel seines Distributors verwendet, unterscheidet hier zwangsläufig nicht.)

Die Folge ist eine Trägheit die ich auch schon öfter bemerkt habe. Wenn ich z.B. große Dateimengen kopiere, nebenher vllt noch einige youtube videos schaue, fängt die Maus an zu ruckeln. Das Umschalten zwischen Arbeitsflächen dauert mehrere Sekunden. Und das alles obwohl die CPU Last unter 10% liegt. Sehr störend.

Nun verwende ich schon seit einigen Wochen den BFS. Um etwas zu testen habe ich vorhin mal wieder einen Kernel mit CFS gebootet, und auch gleich mal mehrere GB auf meinen USB Stick kopiert. Den direkten Vergleich zwischen den beiden Schedulern hatte ich so noch nie gezogen. Fakt ist: Diese Probleme die CFS beim Kopieren großer Datenmengen und anderen lastenden Vorgängen macht, Ruckeln der Maus, langsame Reaktion, sind unter einem Kernel mit BFS nicht vorhanden.

Ich kann nur jedem ans Herz legen, der leidenschaftlicher Linux Nutzer ist, seinen nächsten Kernel mit dem BFS zu kompilieren. Dazwischen liegen Welten!

Update 1: Gerade habe ich mal einen Kernel mit BFS304 (Version 0.304) kompiliert. Es ist immernoch 2.6.31 btw, mal sehen wie sich das auf die Stabilität auswirkt. (Alles oben geschriebene war 2.6.31 mit BFS221, und litt doch an der einen oder anderen Stabilitätsschwäche….)

Update 2: Die Abstürze die ich mit BFS221 noch ab und zu erlebt habe, sind bisher unter 304 nicht aufgetreten… :)

I ran into this issue about two weeks ago, but didn’t get through to writing about it.

The new (Debian) Kernel 2.6.24-1-amd64 no comes with ‘built in’ drivers and firmware for various Ralink WIFI devices. E.g. there are drivers for both PCI and USB devices (rt2×00 chipsets, including rt2500 (pci), rt2400) from rt2×00.serialmonkey.com compiled as modules into the kernel.
Unfortunately, those drivers really didn’t work out for me. My WIFI PCI Card has got a Ralink rt2500 chipset. I used to compile the module myself, using the rt2500 drivers from rt2×00.serialmonke.com CVS.
But with kernel 2.6.24-1 various modules, such as rt2×00, rt2×00pci, rt2500, rt2500pci, were loaded automatically. But the result wasn’t what I had hoped for. Even though my WIFI card was recognized immediately and connecting to my WIFI was really easy, because of the new GNOME network manager that includes WIFI connections, the transferrate always went down to 1 Mbit/s.

I could not manage to get it faster.

So the conclusion, I built the kernel again, manually, without any WIFI support included. Then I used those nice rt2500 CVS drivers from serialmonkeys.org and all works fine again :)

Currently I’m spending my very rare free time (I’m pretty busy with school right now) on getting my gentoo installation to work properly ;)

Edit: (Thanks adlerweb): Yeah I know I could’ve blacklisted the built-in modules, but I was in the mood (and found some time ;) ) for some ‘handicrafts’