# Linux-Tuning - I/O Scheduler

## Guenther Brunthaler

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":

```
#! /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:

```
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:

```
# set_iosched cfq

# echo anticipatory > /sys/block/hdc/queue/scheduler

```

wenn /dev/hdc das cdrom ist.

in diesem Sinne,

Günther

----------

## mrsteven

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

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.  :Confused: 

----------

## Guenther Brunthaler

 *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!

----------

## Erdie

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

----------

## Guenther Brunthaler

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

----------

## Erdie

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

Grüße

Erdie

----------

## Guenther Brunthaler

 *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!  :Smile: 

----------

## Keepoer

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

----------

## Guenther Brunthaler

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

----------

## JoHo42

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

----------

## Guenther Brunthaler

 *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:

```
# 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?   :Smile: 

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:

```
# 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

```
# 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.

----------

## jodel

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

----------

## Klaus Meier

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.

----------

## jodel

 *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/

----------

## Klaus Meier

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

----------

## jodel

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.

----------

## Klaus Meier

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.

----------

## BennY-

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 Evil: 

----------

## jodel

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

----------

## gimpel

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

----------

