View previous topic :: View next topic |
Author |
Message |
Guenther Brunthaler Apprentice
Joined: 22 Jul 2006 Posts: 217 Location: Vienna
|
Posted: Wed Nov 21, 2007 12:46 pm Post subject: Linux-Tuning - I/O Scheduler |
|
|
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 |
|
|
mrsteven Veteran
Joined: 04 Jul 2003 Posts: 1938
|
Posted: Wed Feb 20, 2008 12:13 pm Post subject: |
|
|
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 |
|
|
Guenther Brunthaler Apprentice
Joined: 22 Jul 2006 Posts: 217 Location: Vienna
|
Posted: Wed Feb 20, 2008 4:10 pm Post subject: |
|
|
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 |
|
|
Erdie Advocate
Joined: 20 May 2004 Posts: 2588 Location: Heidelberg - Germany
|
Posted: Wed Oct 29, 2008 3:41 pm Post subject: |
|
|
Frage: Welcher Scheduler wäre wohl optimal bei Audio - Anwendungen, wenn es auf geringste Latenz ankommt? _________________ Desktop AMD Ryzen 9 5900X 32GB RAM, Asus GF GTX 1060.
Notebook Tuxedo Pulse 15 Gen1 AMD Ryzen 7 4800H mit Radeon Vega 7
Raspberry Pi 1 + 2 + 3B+ + Zero W |
|
Back to top |
|
|
Guenther Brunthaler Apprentice
Joined: 22 Jul 2006 Posts: 217 Location: Vienna
|
Posted: Thu Oct 30, 2008 12:49 am Post subject: |
|
|
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 |
|
|
Erdie Advocate
Joined: 20 May 2004 Posts: 2588 Location: Heidelberg - Germany
|
Posted: Thu Oct 30, 2008 11:38 am Post subject: |
|
|
Danke Ich meinte eher das Aufnehmen, bevorzugt mit Ardour und Jack.
Grüße
Erdie _________________ Desktop AMD Ryzen 9 5900X 32GB RAM, Asus GF GTX 1060.
Notebook Tuxedo Pulse 15 Gen1 AMD Ryzen 7 4800H mit Radeon Vega 7
Raspberry Pi 1 + 2 + 3B+ + Zero W |
|
Back to top |
|
|
Guenther Brunthaler Apprentice
Joined: 22 Jul 2006 Posts: 217 Location: Vienna
|
Posted: Thu Oct 30, 2008 12:37 pm Post subject: |
|
|
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 |
|
|
Keepoer Apprentice
Joined: 30 Mar 2004 Posts: 293 Location: Zwischen Kassel und Edewecht pendelnd
|
Posted: Tue Dec 23, 2008 5:43 pm Post subject: |
|
|
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 |
|
|
Guenther Brunthaler Apprentice
Joined: 22 Jul 2006 Posts: 217 Location: Vienna
|
Posted: Tue Dec 23, 2008 6:42 pm Post subject: |
|
|
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 |
|
|
JoHo42 l33t
Joined: 14 Feb 2004 Posts: 956 Location: Germany
|
Posted: Thu Jan 29, 2009 10:05 am Post subject: |
|
|
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 |
|
|
Guenther Brunthaler Apprentice
Joined: 22 Jul 2006 Posts: 217 Location: Vienna
|
Posted: Thu Jan 29, 2009 12:54 pm Post subject: |
|
|
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 |
|
|
jodel Tux's lil' helper
Joined: 28 Sep 2004 Posts: 113
|
|
Back to top |
|
|
Klaus Meier Advocate
Joined: 18 Apr 2005 Posts: 2908 Location: Bozen
|
Posted: Tue Feb 16, 2010 5:05 pm Post subject: |
|
|
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 |
|
|
jodel Tux's lil' helper
Joined: 28 Sep 2004 Posts: 113
|
Posted: Tue Feb 16, 2010 7:01 pm Post subject: |
|
|
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 |
|
|
Klaus Meier Advocate
Joined: 18 Apr 2005 Posts: 2908 Location: Bozen
|
Posted: Tue Feb 16, 2010 7:51 pm Post subject: |
|
|
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 |
|
|
jodel Tux's lil' helper
Joined: 28 Sep 2004 Posts: 113
|
Posted: Tue Feb 16, 2010 8:35 pm Post subject: |
|
|
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 |
|
|
Klaus Meier Advocate
Joined: 18 Apr 2005 Posts: 2908 Location: Bozen
|
Posted: Wed Feb 17, 2010 4:48 pm Post subject: |
|
|
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 |
|
|
BennY- n00b
Joined: 19 Feb 2010 Posts: 1
|
Posted: Fri Feb 19, 2010 1:13 pm Post subject: |
|
|
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... |
|
Back to top |
|
|
jodel Tux's lil' helper
Joined: 28 Sep 2004 Posts: 113
|
Posted: Sun Jul 25, 2010 8:47 am Post subject: |
|
|
@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 |
|
|
gimpel Advocate
Joined: 15 Oct 2004 Posts: 2720 Location: Munich, Bavaria
|
Posted: Wed Sep 22, 2010 1:44 pm Post subject: |
|
|
BFS ist ein CPU-Scheduler, kein I/O-Scheduler - andere Baustelle. _________________ http://proaudio.tuxfamily.org/wiki - pro-audio software overlay
|
|
Back to top |
|
|
|
|
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
|
|