Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Linux-Tuning - I/O Scheduler
View unanswered posts
View posts from last 24 hours
View posts from last 7 days

 
Reply to topic    Gentoo Forums Forum Index Deutsches Forum (German) Deutsche Dokumentation
View previous topic :: View next topic  
Author Message
Guenther Brunthaler
Apprentice
Apprentice


Joined: 22 Jul 2006
Posts: 214
Location: Vienna

PostPosted: Wed Nov 21, 2007 12:46 pm    Post subject: Linux-Tuning - I/O Scheduler Reply with quote

Liebe Freunde,

Vielleicht interessiert euch das ja auch.

Jeder der unter Linux einen Rechner aufsetzen und dabei die
Disk-Performance optimieren will, könnte daran potenziell Bedarf haben.

Es geht um die verschiedenen I/O-Scheduler die man unter Kernel 2.6 wählen kann, und für welche Szenarien meiner Ansicht nach welcher Scheduler am besten geeignet ist.

Vorab möchte ich aber klarstellen, dass dieses Posting meine persönlichen, subjektiven Schlussfolgerungen beinhaltet wie ich die Sachverhalte zur Zeit nach bestem Wissen verstehe; ohne jeden Anspruch auf Vollständigkeit oder absolute Korrektheit. Ich freue mich auf ergänzende Kommentare von anderen Usern, die meine Annahmen bestätigen oder korrigieren können.

-------- Original-Nachricht --------
Betreff: Ein sehr empfehlenswerter Artikel über die I/O Scheduler von Linux
Datum: Wed, 21 Nov 2007 13:21:24 +0100
Von: Guenther Brunthaler

[...]

Bislang war mir immer sehr unklar, welchen I/O-Scheduler man für welche
Art von Arbeit verwenden sollte.

Der Artikel

http://kerneltrap.org/node/7637

brachte nun einiges Licht in diese Thematik - ich kann ihn nur empfehlen.

Vorab meine Interpretation des Textes, welcher I/O Scheduler für was gut
ist:

  • "noop" - wie der Name schon sagt, scheduled der gar nichts. Simples
    FIFO-Queuing für alle I/O Requests egal woher sie stammen. Ist gedacht
    für wirklich intelligente Hardware, die ihr eigenes internes Scheduling
    macht, und wo jedes Scheduling durchs OS kontraproduktiv wäre. (Etwa
    SANs, könnte ich mir vorstellen.) Update: Angeblich ist dies auch der beste Scheduler für Flash-Medien.

  • "deadline": I/O-Requests werden nach der Blocknummer sortiert in eine
    Warteschlange eingeordnet unabhängig woher sie stammen. Diese Queue wird
    dann zyklisch von vorn nach hinten abgearbeitet. Damit I/O-Requests
    nicht unmäßig warten müssen falls die Schlange zu lange wird, werden die
    I/O-Requests überdies in separate FIFOs für Read und Write-Requests
    eingeordnet, nach Alter sortiert. Jedem Request wird dabei eine
    Maximaldauer zur Erledigung zugewiesen. Solange diese Maximaldauern
    nicht überschritten werden werden die I/Os wie zuvor beschrieben in der
    Sortierreihenfolge der Blocknummern durchgeführt. Sobald die
    Maximaldauern aber überschritten werden, werden nur mehr abwechselnd die
    ältesten Read- und Write-Requests aus den FIFOs bedient, bis sich die
    Situation wieder gebessert hat - dann wird wieder das zyklische
    Schedulen in Blockreihenfolge angeworfen.

  • "anticipatory": Tut dasselbe wie "deadline", wartet aber nach jedem
    I/O-Vorgang (ich hoffe nur bei Schreibvorgängen aus den Deadline-FIFOs)
    einige Millisekunden ob vielleicht ein Nachfolge-Request daher kommt.
    Dadurch werden zahlreiche sequenzielle I/Os besser unterstützt, welche
    an verschiedenen Stellen der Disk gleichzeitig erfolgen. Sprich, wenn
    verschiedene Prozesse zur selben Zeit verschiedene Dateien bearbeiten.
    Der "deadline" geht dabei nämlich ziemlich ein und "seekt" sich blöd.

  • "cfq": Der "Completely Fair Queueing" Scheduler arbeitet völlig
    anders. Er scheduled Zeitscheiben, in denen nur die I/O eines bestimmten
    Prozesses auf die Disk erfolgt. Die Größe der Zeitscheiben ist von
    Statistiken und der Prozesspriorität abhängig, und ausserdem wird
    innerhalb eines Prozesses noch zwischen synchronen und asynchronen
    Requests unterschieden. Aber zwischen den Prozessen gibt es ein Round
    Robin, daher kommt jeder Prozess nach einer relativ kurzen Zeit wieder
    dran, und keiner "verhungert" auch wenn sehr viel I/O durchzuführen ist.

Der cfq ist der komplexeste der I/O Scheduler, reagiert aber am
schnellsten. Daher ist es für den typischen Desktop-Betrieb
normalerweise der am besten geeignete I/O Scheduler. In vielen
Linux-Distris wird er daher auch als Default-Scheduler eingesetzt.

Allerdings scheduled der cfq die Requests nicht optimal aus der Sicht
der Arbeit welche die Disk zu erledigen hat. Hier ist der anticipatory
normalerweise am effizientesten - insbesondere wenn Batch-Jobs laufen
die ihrerseits jede Menge sequenzielle Dateien (gleichzeitig)
bearbeiten. Auch zum Ansehen von Videos etc. ist er wohl der geeignetste.

Der deadline wiederum glänzt bei völligen Random-Zugriffen, wie sie vor
allem bei Datenbanken oft vorkommen. Hier sorgt er dafür, dass die Seeks
minimiert werden welche für das Durchführen der Random-Zugriffe
erforderlich sind. Zwar ist der anticipatory dem deadline sehr ähnlich,
aber durch die kleinen Wartepausen die er einlegt um "Sequenzialität zu
erkennen" (die bei Datenbankzugriffen nicht vorkommt), vergeudet das
anticipatory Zeit welche der deadline nicht vergeudet.

Wenn Datenbankzugriffe aber nicht andauernd erfolgen, kann der
anticipatory doch wieder besser sein: Bei Datenbankzugriffen zwar etwas
langsamer, kann er aber zwischendurch bei sequenziellen Zugriffen wieder
Zeit und Seeks sparen.

Wenn neben den Datenbanken und Batch-Jobs aber auch noch "normal"
gearbeitet werden soll, empfiehlt sich wieder der cfq: Durch seine
Zeitscheiben werden auch sequenzielle Jobs - zumindest innerhalb der
Zeitscheibe - halbwegs effizient abgearbeitet, durch seine verschieden
langen Zeitscheiben kann er aber auch Datenbanken ausreichend effizient
bedienen obwohl nicht ganz so gut wie der deadline. Vor allem aber
verhungern während dessen keine interaktiven Benutzerprozesse.

Ich werde aus diesen Erkenntnissen die Konsequenz ziehen, den cfq als
Default-Scheduler einzustellen.

Wenn ich aber fette Batch-Jobs laufen lasse, wie große emerge-Orgien wo
der Compiler ständig sequeziell Source-Dateien liest und Object-Files
erzeugt, werde ich temporär auf den anticipatory umschalten. Dasselbe
gilt beim Movie-Ansehen, oder wenn sehr große Dateien möglichst schnell
durch die Gegend kopiert werden sollen und mir Interaktivität
währenddessen nicht so wichtig ist.

Wenn ich hingegen einen Rechner als dezidierten Datenbankserver unter
hoher Last einsetze, ist hingegen der "deadline" die beste Wahl. (cfq
dürfte auch OK sein wenn die Last nicht ganz so hoch ist.)

Tja, soweit meine Erkenntnisse.

Hier noch wie man die Scheduler umschaltet (geht im laufenden Betrieb):

Script "set_iosched":
Code:
#! /bin/sh
SCHEDULER=${1:-cfq}
lsmod | grep "$SCHEDULER[_-]iosched" > /dev/null 2>& 1 || {
        modprobe "$SCHEDULER-iosched"
}
for D in /sys/block/*; do
        S="$D/queue/scheduler"
        test -e "$S" || continue
        echo "Assigning $SCHEDULER to $S."
        echo "$SCHEDULER" > "$S"
done


Aufruf:

Code:
set_iosched cfq
set_iosched # setzt ebenfalls cfq
set_iosched noop
set_iosched anticipatory
set_iosched deadline

Natürlich setzt dies voraus, dass die entsprechenden Scheduler auch ins
Kernel oder als Modul kompiliert wurden.

Das Script setzt hier denselben Scheduler für alle Blockgeräte; wenn man
will kann man aber für jedes Gerät einen anderen Scheduler wählen. So
etwa setzt man für alle Geräte den cfq, fürs cdrom aber den
cd-rom-freundlicheren anticipatory:

Code:
# set_iosched cfq
# echo anticipatory > /sys/block/hdc/queue/scheduler

wenn /dev/hdc das cdrom ist.

in diesem Sinne,
Günther
Back to top
View user's profile Send private message
mrsteven
Veteran
Veteran


Joined: 04 Jul 2003
Posts: 1892

PostPosted: Wed Feb 20, 2008 12:13 pm    Post subject: Reply with quote

Schöner Beitrag, finde ich sehr hilfreich. :)

Mir ist aufgefallen, dass gerade bei langsameren Platten (z.B. in Notebooks) der Anticipatory nach wie vor am besten ist, da dieser eben versucht unnötige Seeks zu vermeiden. Mit dem CFQ steht bei mir fast das ganze System, wenn mehrere Anwendungen gleichzeitig auf die Platte zugreifen. :?
_________________
Unix philosophy: "Do one thing and do it well."
systemd: "Do everything and do it wrong."
Back to top
View user's profile Send private message
Guenther Brunthaler
Apprentice
Apprentice


Joined: 22 Jul 2006
Posts: 214
Location: Vienna

PostPosted: Wed Feb 20, 2008 4:10 pm    Post subject: Reply with quote

mrsteven wrote:
Mit dem CFQ steht bei mir fast das ganze System, wenn mehrere Anwendungen gleichzeitig auf die Platte zugreifen.


Ich könnte mir denken, dass es beim CFQ auch ein Problem ist, dass dieser quasi zu einem normale "Deadline" degradiert wird, wenn nur ein einziger Prozess I/O durchführt.

Denn die Vorteile des CFQ kommen ja erst zum Tragen, wenn verschiedene Prozesse sich ums I/O "balgen".

Wenn aber ohnehin nur ein einziger Prozess I/O mit verschiedenen Dateien macht, etwa Daten sequenziell von einer Datei in eine andere kopieren (oder mehrere solche Copy-Vorgänge mit verschiedenen Datei-Paaren gleichzeitig), dann wird der CFQ nicht klüger arbeiten als der deadline.

Der anticipatory wird aber auch in diesem Fall seinen Vorteil ausspielen, I/Os zu sequentialisieren, so dass nicht andauernd herumgeseekt werden muss.

Wenn eine Platte eine lange Seek-Zeit hat, könnte dieser Vorteil des anticipatory in der Tat stärker ins Gewicht fallen als die Fähigkeiten des CFQ was das Aufteilen von I/O auf mehrere Prozesse anbetrifft.

Für solche Platten wäre wohl eine Mischung aus CFQ und anticipatory ideal!
Back to top
View user's profile Send private message
Erdie
Veteran
Veteran


Joined: 20 May 2004
Posts: 1661
Location: Heidelberg - Germany

PostPosted: Wed Oct 29, 2008 3:41 pm    Post subject: Reply with quote

Frage: Welcher Scheduler wäre wohl optimal bei Audio - Anwendungen, wenn es auf geringste Latenz ankommt?
_________________
Desktop Phenom II X4 8GB RAM, Asus GF 430 fanless. Sound RME Multiface + PCI + Cardbus, 2x RME Quadmic, 1x Behringer ADA8000.
2x IBM Thinkpad T60
Zotag Mag Mini Atom
Raspberry Pi
Back to top
View user's profile Send private message
Guenther Brunthaler
Apprentice
Apprentice


Joined: 22 Jul 2006
Posts: 214
Location: Vienna

PostPosted: Thu Oct 30, 2008 12:49 am    Post subject: Reply with quote

Erdie wrote:
Frage: Welcher Scheduler wäre wohl optimal bei Audio - Anwendungen, wenn es auf geringste Latenz ankommt?


Kommt drauf an von was für einer Art Audio wir hier sprechen.

Wenn du die Wiedergabe von einzelnen Audio-Dateien meinst ist der I/O-Scheduler ziemlich egal, weil praktisch alle Media-Player die Audiodaten immer stückweise in einen Puffer im Speicher lesen und von dort in Ruhe abspielen können, während sie schon in Seelenruhe das nächste Stück der Datei in einen zweiten Puffer laden. Hier entsteht daher keine Hektik.

Wenn du Sequenzer-Programme wie Rosegarden & Co über JACK meinst, da wird der Scheduler auch eher egal sein weil die üblicherweise alles in den Speicher laden bevor sie mit der Wiedergabe anfangen.

Wenn du Programme wie Audacity meinst wo du Realtime Multitrack-Mixing betreiben willst, kommt es vermutlich darauf an wie das Programm intern genau arbeitet.

Ich würde in diesem Fall erst den CFQ und dann den Anticipatory ausprobieren. Aber probiere einfach sicherheitshalber *alle* Scheduler der Reihe nach durch.

Ich würde den Test dabei so machen: Du fügst einfach eine Audio-Spur (etwa mehrere als WAV-Dateien exportierte MP3-Dateien) nach der anderen hinzu und probierst jedesmal ob die Wiedergabe noch ruckelfrei verläuft. *Irgendwann* wird damit Schluss sein.

Und dann wählst du einfach denjenigen I/O Scheduler aus, bei dem du die meisten Audio-Tracks störungsfrei gleichzeitig abspielen konntest.

Ich tippe dabei auf den CFQ oder den Deadline. Dabei kommt es auch darauf an was sonst noch an Programmen oder Daemonen bei dir läuft.

Wenn sonst nichts läuft, wird der Deadline vermutlich besser sein.

Was Latenz angeht sollte der Anticipatory der schlechteste sein, denn dieser erzeugt ja sogar künstlich Latenzen um sich damit eventuell Seeks zu ersparen.

Andererseits, wenn du eine eher langsam "seekende" Festplatte hast (wie offenbar bei Notebooks verbreitet), könnte das doch wieder hilfreich sein.

Falls du eine SSD-Platte oder einen Flash-Stick als Speichermedium benutzt, könnte hingegen sogar "noop" der beste Scheduler sein.
Back to top
View user's profile Send private message
Erdie
Veteran
Veteran


Joined: 20 May 2004
Posts: 1661
Location: Heidelberg - Germany

PostPosted: Thu Oct 30, 2008 11:38 am    Post subject: Reply with quote

Danke :) Ich meinte eher das Aufnehmen, bevorzugt mit Ardour und Jack.

Grüße
Erdie
_________________
Desktop Phenom II X4 8GB RAM, Asus GF 430 fanless. Sound RME Multiface + PCI + Cardbus, 2x RME Quadmic, 1x Behringer ADA8000.
2x IBM Thinkpad T60
Zotag Mag Mini Atom
Raspberry Pi
Back to top
View user's profile Send private message
Guenther Brunthaler
Apprentice
Apprentice


Joined: 22 Jul 2006
Posts: 214
Location: Vienna

PostPosted: Thu Oct 30, 2008 12:37 pm    Post subject: Reply with quote

Erdie wrote:
Danke :) Ich meinte eher das Aufnehmen, bevorzugt mit Ardour und Jack.


Ach so! Nun, ich glaube dann brauchst du dir nicht all zu viele Sorgen um den I/O-Scheduler zu machen wenn du nicht gerade auf extrem alter Hardware arbeitest welche du mit der Aufnahme aufs Limit belastest.

Denn aus der Sicht der Festplatte ist das Aufnehmen einer Audio-Datei nicht aufwändiger als deren Wiedergabe: Ein schöner, sequenzieller Schreibvorgang.

Ich habe zwar keine Erfahrungen mit Ardour, aber wenn es nicht gerade völlig schwachsinnig programmiert ist, wird es ähnlich wie ein ein Media-Player *zwei* Aufnahme-Puffer besitzen (im RAM natürlich, nicht auf der Festplatte), von denen immer nur einer von beiden gerade mit Daten befüllt wird während die Aufnahme läuft.

Wenn der eine Puffer voll ist, wird die Aufnahme unterbrechungsfrei in den zweiten Puffer weitergeleitet, und das Programm hat nun "alle Zeit der Welt" um die Daten aus dem ersten Puffer auf die Festplatte zu schreiben.

Sobald der zweite Puffer voll ist, wird dann wieder auf den ersten umgeschaltet, und der zweite Puffer wird geschrieben.

Man muss also nur darauf achten, dass diese internen Puffer groß genug sind, damit die Festplatte genug Zeit hat einen Puffer zu schreiben noch bevor der jeweils andere voll ist.

Und Festplatten, sogar die langsamsten, können weitaus schneller Daten schreiben als jede realistische Audio-DMA welche hereinbringt!

Nehmen wir hier einfach einmal an, du möchtest 8.1-Audiodaten mit je 32 Bit Auflösung wie in JACK mit einer Sample-Frequenz von 192 kHz aufnehmen. (Das sollte ja hoffentlich reichen...)

Welche Datenmengen entstehen hier pro Sekunde?

Es sind (8 + 1) * 32 * 192.000 Bits oder (8 + 1) * 4 * 192.000 Bytes.

Das sind etwas weniger als 7 MB pro Sekunde.

Wenn Adour also etwa (als schöne runde Zahl) 8 MB Speicher pro Aufnahmepuffer nimmt, zusammen also 16 MB RAM, dann hat es mehr als eine volle Sekunde Zeit zum Zurückschreiben jedes Puffers, und muss in dieser Zeit 7 MB an Daten schreiben.

Das sollte selbst die schwächste Festplatte schaffen wenn das System ansonsten unbelastet ist.

Und selbst *wenn* die Festplatte andere Dinge zu tun hat, sollte der CFQ für diesen Fall meiner Ansicht nach völlig ausreichend sein.

Mit einer Ausnahme vielleicht: Man sollte immer achten dass genug RAM frei ist, damit das Kernel nicht zu Swappen anfängt.

Denn wenn *das* geschieht, hat die Festplatte *derart* viel mehr zu tun als im Normalfall, so dass ich für *nichts* mehr garantieren würde was Echtzeitverhalten angeht.

Mit anderen Worten, du solltest vielleicht nicht gerade OpenOffice emergen während du eine Aufnahme machst! :-)
Back to top
View user's profile Send private message
Keepoer
Apprentice
Apprentice


Joined: 30 Mar 2004
Posts: 293
Location: Zwischen Kassel und Edewecht pendelnd

PostPosted: Tue Dec 23, 2008 5:43 pm    Post subject: Reply with quote

Danke für den Beitrag! Ich habe auf meinem Server (USB-Stick als Systemplatte) mal noop gesetzt und bin damit echt zufrieden. Das System läuft deutlich schneller, vor allem bei schtreibintensiven Aufgaben (Portage-Update, emerge-Vorgängen). Ich hab den entsprechenden Scheduler per Hand gesetzt. Wie isn das? Müsste ich nach einem Neustart den Stick erneut auf noop setzen?

MfG
Back to top
View user's profile Send private message
Guenther Brunthaler
Apprentice
Apprentice


Joined: 22 Jul 2006
Posts: 214
Location: Vienna

PostPosted: Tue Dec 23, 2008 6:42 pm    Post subject: Reply with quote

Hi Keepoer,

Keepoer wrote:
Ich hab den entsprechenden Scheduler per Hand gesetzt. Wie isn das? Müsste ich nach einem Neustart den Stick erneut auf noop setzen?


Wenn du deine Kernel-Konfiguration selbst angepasst hast, kannst du den noop als Default-Scheduler einstellen. Dann wird er immer automatisch als Default genommen und ein manuelles Ändern erübrigt sich.

Falls du die Gentoo-Defaultkonfiguration fürs Kernel verwendest, sind die Änderungen in der Tat nach jedem Neustart futsch und du musst sie neu setzen.

In diesem Fall kannst du die entsprechenden Befehle etwa in /etc/conf.d/local.start eintragen, da diese Datei bei jedem Systemstart gesourced wird.

Warnung: Da dieses Script von den Systemscripts gesourced und nicht nur einfach ausgeführt wird, solltest du aufpassen dass du nicht irrtümlich irgendwelche Environement-Variablen darin setzt oder veränderst, die das System später noch braucht.

Die einfachste Möglichkeit dies zu verhindern ist, deine Befehle zwischen runde Klammern zu schreiben. Dadurch werden diese in einer Subshell ausgeführt und können die Environment-Variablen der Systemscripts daher nicht irrtümlich versauen.

Also etwa so:

--- File "/etc/conf.d/local.start" ---
(
command1
command2
...
commandN
)
--- File "/etc/conf.d/local.start" ---

mfg
Günther
Back to top
View user's profile Send private message
JoHo42
l33t
l33t


Joined: 14 Feb 2004
Posts: 904
Location: Germany

PostPosted: Thu Jan 29, 2009 10:05 am    Post subject: Reply with quote

Hi Leute,

vier Fragen:

1) Wie stelle ich fest, ob der Scheduler laeuft?
2) Wie kann ich die Performence testen?
3) In der kernel configuration ist der noop als default eingetragen,
dieses laesst sich auch nicht aendern es gibt keine weiteren Scheduler.
Ich habe alles drei Scheduler als modul compeliert.

4) Mit dem Script kann ich den cfg und deadeline problemlos wechseln.
Allerdings der as-scheduler will sich nicht mit dem Script starten lassen.

Gruss Joerg
Back to top
View user's profile Send private message
Guenther Brunthaler
Apprentice
Apprentice


Joined: 22 Jul 2006
Posts: 214
Location: Vienna

PostPosted: Thu Jan 29, 2009 12:54 pm    Post subject: Reply with quote

JoHo42 wrote:
Wie stelle ich fest, ob der Scheduler laeuft?


Es läuft immer irgend einer - und sei es nur der "noop".

Welcher läuft, kannst du für jedes Gerät mittels einer Abfrage wie der folgenden ermitteln:

Code:
# cat /sys/block/sda/queue/scheduler
noop [cfq] anticipatory


wobei du statt "sda" das gewünschte Gerät angibst (hda, hdb, sdb, ...).

Die ausgegebene Zeile listet alle derzeit geladenen Scheduler auf, der Eintrag in eckigen Klammern ist derjenige Scheduler welcher dieses Gerät verwendet. Im dargestellten Beispiel wäre dies also der "cfq".

JoHo42 wrote:
Wie kann ich die Performence testen?


Stoppuhr? :-)

Der time-Befehlszusatz der bash kann aber auch hilfreich sein. Wenn man etwa die Performance von /dev/sda testen will und sagen wir /usr auf dieser Festplatte liegt, könnte man die Performance (zumindest die zum Lesen) folgendermaßen testen:

Code:
# time tar -c --one-file-system -C / usr > /dev/null


Allerdings testet dies nur die Performance wenn ein Prozess liest.

Wenn man testen will wie gut der Scheduler ist wenn mehrere Prozesse gleichzeitig verschiedene Daten lesen, kann man ebenfalls einen Befehl wie oben verwenden, nur mehrere gleichzeitig davon (mit "&" ausgeführt), und alle sollten verschiedene Verzeichnisse ähnlichem Umfangs von derselben Partition lesen.

JoHo42 wrote:
In der kernel configuration ist der noop als default eingetragen,
dieses laesst sich auch nicht aendern es gibt keine weiteren Scheduler.


Hast du das Kernel selbst konfiguriert? Vielleicht hast du einfach keine anderen Scheduler ausgewählt!

Beim Kernel-konfigurieren kann man sich frei aussuchen, welche Scheduler fix eingebaut sein sollen, welche als Modul und welche gar nicht. Zumindest der noop ist aber immer vorhanden. Als Default-Scheduler können nur fix eincompilierte Scheduler festgelegt werden.

JoHo42 wrote:
Ich habe alles drei Scheduler als modul compeliert.


Dann sind wahrscheinlich einfach die Module nicht geladen worden! In diesem Fall musst du das händisch mit modprobe nachholen bevor die Scheduler angezeigt werden bzw. ausgewählt werden können.

Versuche einmal ein

Code:
# ls /lib/modules/`uname -r`/kernel/block/
as-iosched.ko  deadline-iosched.ko
# modprobe as-iosched
# modprobe deadline-iosched


das zeigt dir an wie die Module heißen - wenn du modprobe für sie aufrufst, musst du allerdings die ".ko"-Erweiterung weglassen.
Back to top
View user's profile Send private message
jodel
Tux's lil' helper
Tux's lil' helper


Joined: 28 Sep 2004
Posts: 113

PostPosted: Tue Feb 16, 2010 2:06 pm    Post subject: Reply with quote

es gibt auch noch den BFS scheduler in den -ck kerneln. Manchen sind davon extrem begeistert, habs selbst aber noch nicht getestet
http://ck.kolivas.org/patches/bfs/bfs-faq.txt
Back to top
View user's profile Send private message
Klaus Meier
Advocate
Advocate


Joined: 18 Apr 2005
Posts: 2165
Location: Bozen

PostPosted: Tue Feb 16, 2010 5:05 pm    Post subject: Reply with quote

Die ck-sources gibt es ja nicht mehr. Der bfs Scheduler ist n den zen-sources drin. Habe dir mir gerade mal angetan und ich finde, das System reagiert schneller, läuft flüssiger. Hm, mal etwas vergleichen. Und noch mal die Einstellungen tunen.
Back to top
View user's profile Send private message
jodel
Tux's lil' helper
Tux's lil' helper


Joined: 28 Sep 2004
Posts: 113

PostPosted: Tue Feb 16, 2010 7:01 pm    Post subject: Reply with quote

Klaus Meier wrote:
Die ck-sources gibt es ja nicht mehr. Der bfs Scheduler ist n den zen-sources drin. Habe dir mir gerade mal angetan und ich finde, das System reagiert schneller, läuft flüssiger. Hm, mal etwas vergleichen. Und noch mal die Einstellungen tunen.


doch seit kurzem is Con Kolivas wieder zurück und streitet auch schon wieder fleißig mit Ingo Molnar, dem CFS Verantwortlichen:
http://lwn.net/Articles/351058/
Back to top
View user's profile Send private message
Klaus Meier
Advocate
Advocate


Joined: 18 Apr 2005
Posts: 2165
Location: Bozen

PostPosted: Tue Feb 16, 2010 7:51 pm    Post subject: Reply with quote

jodel wrote:
Klaus Meier wrote:
Die ck-sources gibt es ja nicht mehr. Der bfs Scheduler ist n den zen-sources drin. Habe dir mir gerade mal angetan und ich finde, das System reagiert schneller, läuft flüssiger. Hm, mal etwas vergleichen. Und noch mal die Einstellungen tunen.


doch seit kurzem is Con Kolivas wieder zurück und streitet auch schon wieder fleißig mit Ingo Molnar, dem CFS Verantwortlichen:
http://lwn.net/Articles/351058/

Ok, aber ck-sources sehe ich trotzdem keine... Hast du den bfs Scheduler direkt im Einsatz und wenn ja, wie? Gehe das gerade durch, aber die zen-sources gefallen mir sehr gut. Hatte sie mir ja schon etwas angesehen, aber dein Beitrag war dann der letzte Tritt, sie mal zu versuchen. Finde sie einfach chick.
Back to top
View user's profile Send private message
jodel
Tux's lil' helper
Tux's lil' helper


Joined: 28 Sep 2004
Posts: 113

PostPosted: Tue Feb 16, 2010 8:35 pm    Post subject: Reply with quote

ja du hast recht, es gibt keine direkt neuen ck-sources, sondern halt kernel patches für die vanilla sources:
http://ck.kolivas.org/patches/bfs/
ich glaube bei den ck-sources war eh außer dem Scheduler sonst nichts verändert, so kommt das aufs gleiche raus.

An deiner Stelle würde ich wohl auch bei zen bleiben, da hast du alle Vorteile durch BFS und noch einige andere Dinge, die die verändern.
Irgendwo habe ich gelesen, die google Leute wollen bei Android jetzt auch auf BFS setzen, finde aber die Quelle nicht mehr.

Ich selbst habe BFS noch nicht ausprobiert, habe dies aber auch demnächst mal vor.
Back to top
View user's profile Send private message
Klaus Meier
Advocate
Advocate


Joined: 18 Apr 2005
Posts: 2165
Location: Bozen

PostPosted: Wed Feb 17, 2010 4:48 pm    Post subject: Reply with quote

Also ich werde mal weiter testen, was dieser Scheduler so bringt, aber meine Begeisterung ist erst mal etwas weg. In den zen-sources ist tuxonice integriert, was dazu führt, dass Suspend und Hibernate nicht mehr funktioniert im Vergleich zu den gentoo-sources. Sollte doch das Gegenteil der Fall sein. Und es gibt viel mehr Dinge, die du konfigurieren kannst oder musst. Mal abwarten, ob das was bringt. TuxOnIce ist bei mir der Schuss ins Knie.
Back to top
View user's profile Send private message
BennY-
n00b
n00b


Joined: 19 Feb 2010
Posts: 1

PostPosted: Fri Feb 19, 2010 1:13 pm    Post subject: Reply with quote

Welche Flashspeicher sollen von Noop profitieren, bzw. in wie fern gelten die Aussagen aus dem Startposting noch für aktuelle Kernel?

Ich habe es mal mit einer Intel X25M-G2 SSD getestet indem ich einfach die maketime vom Kernel gemessen habe:

real 7m29.790s
user 6m28.216s
sys 0m54.395s
[noop]

real 7m17.363s
user 6m23.140s
sys 0m53.655s
[cfq]

kernel 2.6.31-gentoo-r6

weitere Tests werde ich am WE u.a. auch auf dem SW RAID5 ausführen, was z.Z. meine Hauptsorge ist... :twisted:
Back to top
View user's profile Send private message
jodel
Tux's lil' helper
Tux's lil' helper


Joined: 28 Sep 2004
Posts: 113

PostPosted: Sun Jul 25, 2010 8:47 am    Post subject: Reply with quote

@benny
hast du schon neue Tests durchgeführt?
Ich verwende ebenfalls eine intel SSD und habe aufgrund des Artikels im Arch Wiki auf noop umgestellt:
http://wiki.archlinux.org/index.php/SSD#I.2FO_Scheduler

Allerdings hab ich keine Vergleichstests gemacht.
Back to top
View user's profile Send private message
gimpel
Advocate
Advocate


Joined: 15 Oct 2004
Posts: 2720
Location: Munich, Bavaria

PostPosted: Wed Sep 22, 2010 1:44 pm    Post subject: Reply with quote

jodel wrote:
es gibt auch noch den BFS scheduler in den -ck kerneln. Manchen sind davon extrem begeistert, habs selbst aber noch nicht getestet
http://ck.kolivas.org/patches/bfs/bfs-faq.txt

BFS ist ein CPU-Scheduler, kein I/O-Scheduler - andere Baustelle.
_________________
http://proaudio.tuxfamily.org/wiki - pro-audio software overlay
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Deutsches Forum (German) Deutsche Dokumentation All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum