Brainf*ck - weil ich es mir wert bin!

Seite 1 von 2 - Forum: Linux and other OS auf overclockers.at

URL: https://www.overclockers.at/linux/brainfck_weil_ich_es_mir_wert_bin_214163/page_1 - zur Vollversion wechseln!


COLOSSUS schrieb am 14.02.2010 um 01:46

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.


t3mp schrieb am 14.02.2010 um 02:13

Hmm. Bei mir ist vanilla 2.6.33 schon viel responsiver im Vergleich zu 2.6.32, ich habe das bisher auf die reiserfs- (BKL remove) und KMS-Verbesserungen zurückgeführt weil ich früher so gar keinen Unterschied mit dem BFS Patch spüren konnte - im Gegensatz zu den meisten anderen Leuten.

Für alle, die zu faul zum Patchen sind, gibt es das sehr empfehlenswerte zen-kernel Project, mit zusätzlichen Extras wie ein aktuelleres btrfs, reiser4, aufs2, tuxonice, BFQ und Simple I/O Scheduler, etc.

Code:
git clone git://git.zen-kernel.org/kernel/zen-stable.git /usr/src/linux-2.6-zen

Ich werd BFS mal eine neue Chance geben und ein zen git pull durchführen.

Vielleicht auch für dich was Interessantes dabei :)


COLOSSUS schrieb am 14.02.2010 um 10:26

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


t3mp schrieb am 14.02.2010 um 11:49

Das kommt wohl stark aufs System draufan - bei mir ist es total stabil. Möglich, dass die Auswirkungen von BFS bei mir vor allem unter I/O bisher durch die Verwendung des BKL von reiserfs verpufft sind.


COLOSSUS schrieb am 14.02.2010 um 11:53

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.


Marcellus schrieb am 14.02.2010 um 15:17

Ich hab mir gestern auch die zen sources draufgespielt mit bfs, allerdings 2.6.32 und merk keinen unterschied.

Aber ich hab auch ext3 für /.


t3mp schrieb am 14.02.2010 um 15:25

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.


Marcellus schrieb am 15.02.2010 um 01:28

2.6.33_rc7 it is.

Gentoo hat rc8 noch nicht mit zen patches. Der Simple I/O Scheduler macht wirklich einen Unterschied, mein raid suckt nicht mehr so arg, wie es das früher immer getan hat.

Aber von der Reaktionszeit merk ich nicht wirklich was, allerdings muss ich doch dazu sagen, das mein Rechner in meinen Augen sowieso schon Pfeil schnell ist.

Aber ich kompilier mir mal firefox und amarok und schau wies aussieht mit 2.6.32 vanilla vs 2.6.33 zen.


deftenski schrieb am 15.02.2010 um 13:41

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?


MONVMENTVM schrieb am 16.02.2010 um 02:59

Danke fuer den Tipp! Trotz meines eh schon schlanken Tiling WM merk ich definitiv einen Unterschied beim Switchen von Desktops oder Programmen; es passiert genau in der Instanz wo ich druecke. KDE Anwendungen wirken wirken wesentlich schneller. Vimperator und zsh sind bei Tab-Completion wesentlich flotter. Bei der zsh merke ich nun absolut keinen Lag mehr, wohingegen davor Completions mit Autokorrektur (falls man sich vertippt) schon eher "zach" waren. Dabei ist es mir oefters passiert dass ich aus Reflex ein zweites mal Tab gedrueckt habe, weil ich dachte der Tastenanschlag wurde nicht registriert.

Dachte nie, dass sich das so spuerbar auswirken kann... sehr nice :)


Lukas schrieb am 18.02.2010 um 12:08

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


issue schrieb am 18.02.2010 um 12:18

Okay, der Thread hat mich jetzt auch animiert, mein Kernel baeckt auch gerade.

edit: okay hab ihn jetzt laufen, merkbar besser ist die Performance aber imho net geworden.

edit2:

Zitat von deftenski
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?

ich habs bei meinem aeltern c2d laptop verwendet, damit er nit so heiss wird, hat damals recht problemlos funktioniert!


MONVMENTVM schrieb am 18.02.2010 um 19:41

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


Lukas schrieb am 19.02.2010 um 10:34

Der Scheduler ist ja :eek:.

Im Desktopbetrieb (KDE 4.4) merke ich nicht besonders viel davon aber ich habe dann ne flotte Runde CoD:MW2 (wine 1.1.38) gespielt und da habe ich einen eindeutigen FPS Boost erhalten. Hab dann noch den Gegentest mit dem Vanilla-Kernel gemacht und tatsächlich hat sich da was an der Performance verbessert. :)


othan schrieb am 19.02.2010 um 13:46

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.




overclockers.at v4.thecommunity
© all rights reserved by overclockers.at 2000-2025