Scheduler: cfq, deadline usw.

Willkommen!

Wenn du im Nexave-Forum mitmachen möchtest, schreib an community@nexave.de. Wir haben die Registrierungsfunktion in unserem Diskussionsforum nämlich deaktiviert, weil sich praktisch nur noch Spammer und Werbebots registriert haben. Per E-Mail sind wir dir gern behilflich, einen Account anzulegen.

    Preclaimer: Scheduler sind eindeutig ein Freizeitbastelspaß. Das Ursache-Wirkungs-Verhältnis läßt sich nur indirekt ermitteln, inklusive Abstürze und möglichem Datenverlust


    Wo zu finden?
    Deadline-Scheduler in Govnah ab 0.6.1 unter "Profileinstellungen" - "advanced settings" - "I/O Scheduler" - dort gibt es u.a. den Deadline-Scheduler. Setzt den UeberKernel 1.4.1-74 oder neuer voraus. Voreingestellt ist der CFQ-Scheduler.


    Was sind Scheduler?
    Scheduler meint hier den Teil des Linux-Kernels, der die Zugriffsanfragen ("I/O-Requests") von Software-Prozessen auf die Hardware abarbeitet. I/O-Requests dauern lange, daher gibt es verschiedene Strategien ("Scheduler"), um sicherzustellen, daß ein Prozess nicht ewig warten muss, bevor er mal mit der Festplatte oder der WLAN-Karte kommunizieren darf. Nähere Informationen zu den unterschiedlichen Schedulern liefert u.a. Wikipedia


    Warum die Wahl des Schedulers Auswirkungen haben kann:
    - die I/O-PErformance gerade beim Pixi ist sehr lahm ("Southbridge") -> der Flash-Speicher des Pixi ist sehr lahm, die WLAN-Verbindung ist sehr lahm
    - webOS macht regen Gebrauch vom Auslagerungsspeicher (Swap) auf dem Flashlaufwerk - wächst locker mal 50MB in einem Rutsch -> Wartezeiten



    Wofür ich den Deadline Scheduler verwende:
    a) ****
    Der Kalender erzeugt starkes Swapping. Einigermaßen Linderung der Wartezeiten im Kalender und auch Email-PRogramm erreiche ich wie folgt:
    1. UberKernel installiert, kein Compcache
    2. Deadline-Scheduler aktiviert. (Muß man nach jedem Neustart erneut aktivieren).
    - macht KAlender und Email erheblich robuster, wenn nur wenige Apps gleichzeitig geöffnet sind.
    - Vorsicht: Der Deadline-Scheduler ist für Multimedia und intensives Multitasking kaum geeignet. Sporadisch treten leider extreme Wartezeiten auf, z.B. beim Öffnen eines YouTube-Videos.


    b) ****
    längere Standby-Zeit durch Deadline-Scheduler


    seit einem Neustart lief mein Pixi wieder mit dem cfq-Scheduler - und hielt nur noch 2 Tage im Standby! Jetzt wieder auf Deadline-Scheduler gestellt und der Verbrauch im Standby-Modus ist wieder so gering wie vorher. Scheinbar erreicht die CPU mit dem Deadline-Scheduler schneller und häufiger den Stromspar-Zustand.


    Ich spreche hier von einem Pixi im "Performance"-Modus (konstant 600Mhz). Der Pre läuft auch mit konstant 500MHz. Habe leider keinen zum Vergleich da.


    EDIT: brauchbare Erläuterungen bei Precentral zum Thema Auslagerungsspeicher (Swap-Speicher)


    EDIT2: Hinweis auf UeberKernel ergänzt. Danke inta

    Ich nehme an, du sprichst hier vom UberKernel wiwa? Die verfügbaren Scheduler hängen nicht von Govnah ab, sondern vom Kernel. Ich weiß nicht ob es am Scheduler liegt, aber ich habe immer noch das Gefühl, dass ich mit dem F105 eine längere Laufzeit hinbekomme, als mit dem UberKernel (erst in den letzten Tagen wieder getestet). Die Unterschiede sind recht deutllich und bewegen sich bei meinem Nutzungsstil im Stundenbereich (trotz verschiedener getesteter Einstellungen/Scheduler beim UberKernel).

    Todsichere Laufzeitverbesserung von etwa 1 Tag habe ich mit dem Deadline-Scheduler (und natürlich UK) nur ohne WLAN und ohne WAN. Bei eingeschaltetem WAN könnte sie zumindest noch einen gewissen Teil besser sein, vielleicht einige Stunden. Habe es aber noch nicht nachgeprüft, da ich den Pixi meist nur im WLAN oder offline habe.

    Interessant. Die experimentellen Kernel gibt es leider gar nicht für den Pixi. Der Anticipatory+UK brachte bei mir eine gefühlte PErformance-Verschlechterung bei eingeschaltetem WLAN, habe ihn daher nicht auf seine Laufzeit getestet. Auf dem Pre sind wahrscheinlich kaum Perfomance-Unterschiede spürbar, wegen der besseren Hardware.


    Was anderes: ich habe den Auslagerungsspeicher mit swapoff deaktiviert und mein Pixi läuft viel robuster - leider stürzt er bei zuvielen offenen Karten einfach ab, statt vorher eine TMC-Warnung zu bringen. Würde mich interessieren, ob das bei den neueren Kerneln auch so ist. Meines Wissens wird die TMC-Berechnung ständig "optimiert"