C
Cpt. Future
Gast
Einleitung:
Unser Super-Moderator mecss hat sich wirklich, in mühevoller Kleinstarbeit diesen tollen Thread erstellt! Ich war so begeistert, dass er es mir erlaubt hat, diesen auch hier in unserem Note2 Forum vorzustellen! Danke dafür
[FAQ] Governors & Schedulers
Aufgrund dessen, dass hier im Forum oftmals die Frage nach dem Sinn von Governors und Schedulers aufgekommen ist, habe ich mir mal die "kleine" Mühe gemacht, die Informationen aus dem XDA zu sammeln, zu übersetzen und hier zusammen zutragen.
Als Quelle dienten mir die Beschreibungen aus dem XDA-Forum. Zum einen von knzo und zum anderen von droidphile. Vielen Dank für deren Mühe.
Da einige Governors und Scheduler für diverse Kernels des SGSII erstellt worden sind, dachte ich mir, dass es eher hierher hingehört. Kann zwar sein, dass es auch generell für andere Kernels und Android-Handys passt, aber ich entschied mich, es hier zu posten.
Quelle: [REF][&Tweaks]KernelGovernors&Modules-Siyah&OtherKernels-xda-developers
Quelle: [REF]QuasarkernelgovernorsandI/Oschedulersmanual xda-developers
Quelle: http://forum.xda-developers.com/show...3#post24233103
1. Was ist ein Governor?
Ein Governor ist ein Treiber zur Regulierung der CPUFreq - CPU-Frequenz. Wie der Name uns schon sagt, ist der Governor der Entscheider, wann bei Vollauslastung die maxFreq - maximale Frequenz - erreicht wird oder wie schnell die minFreq - minimale Frequenz bzw. mittlere Frequenz erreicht wird. Er entscheidet, wann, wie und wie lange die CPU reagiert und trotzdem akkusparend bleibt und trotzdem weiterhin weich arbeitet.
Es gibt sehr sehr viele Arten von Governors. Einige sind für Einkern-Prozessoren und einige nur für Zweikern-Prozessoren ausgelegt. In Stock-Kernels gibt es 5 Governors und in Quasar-Kernels gibt es noch viel mehr.
2.Welche Governors gibt es?
Ich habe bis jetzt 20 Arten von Governors gefunden, wozu ich etwas schreiben kann und ich nachfolgend aufgelistet habe.
1) Ondemand *&
2) Powersave *@
3) Userspace *
4) Conservative *
5) Performance *
6) Interactive +
7) Interactivex +
8) Smartass (Removed as of 2.2i) +
9) Smoothass +
10) Brazilianwax +
11) SavagedZen +
12) Minmax +
13) Scary +
14) Lazy
15) Lulzactive
16) Lagfree
17) SmartassV2
18) Ondemandx
19) Intellidemand
20) Lionheart
21) Sleepy #
22) Hyper #
23) Pegasusq/Pegasusd %/$
Legende:
& = Default (standardmäßig eingestellt)
@ = standardmäßig abgestellt
* = im Stockkernel vorhanden
+ = in Quasarkerneln vorhanden
# = im RedPill-Kernel vorhanden
% = Default-ICS Stockkernel
$ = im Siyah-Kernel vorhanden
1) Ondemand:
Der Ondemand-Governor ist die Standardauswahl, die aufgrund seiner ausgewogenen Einstellungen, die einen guten Kompromiss zwischen Akkulaufleistung und Performance bietet. Allerdings hat er keine Profile beim Ausschalten des Displays (Screen-Off-Profile) oder für das Aufwecken des Handys und reagiert auf Eingaben gleich mit hohen Sprüngen zur Leistung.
2) Powersave:
Bei diesem Governor entspricht die maxFreq der minFreq. Für den alltäglichen Gebrauch ist dieser Governor nicht zu empfehlen.
3) Userspace:
Hier können individuelle Einstellungen statt automatischen Vorgaben eingestellt werden. Ob es funktioniert und wie, weiß anscheinend niemand. Ist schon komisch.
4) Conservative:
Er ist eher ein langsamer Vertreter seiner Art und ist eher ein langsamer Ondemand, welcher langsam hochskaliert um den Akku zu schonen. Zur Verdeutlichung ein Beispiel an Hand des Ondemand. Der Ondemand erhöht bei einer Interaktivität des Smartphones die Frequenz bis auf maxFreq. Der Conservative hingegen tut das um die Hälfte langsamer und spart dabei Akkulaufleistung, aber auf Kosten der Performance.
5) Performance:
Hier entspricht die minFreq der maxFreq, also genau umgekehrt wie beim Powersave, was bedeutet, dass beim Performance-Governor immer die maximale Frequenz eingestellt ist und den Akku in die Knie zwingt. Ist somit nur für Benchmarks zu gebrauchen.
6) Interactive:
Dieser Governor ist eher ein schnellerer Ondemand. Etwas flotter und akkufreundlicher. Anstelle von regelmäßigen Anfragen in jedem Intervall wie der Ondemand, bestimmt der Interactive wie er hochskaliert, wenn die CPU aus dem Standby aufgeweckt wird. Er ist wegen seiner Stabilitätsoptimierung ein intelligenter Ondemand. Dies ist der beliebteste Governor der letzten Jahre.
7) Interactivex:
Dies ist ein Interactive nur mit Aufweck-Profilen und ist auch akkufreundlicher als der Interactive. Grundsätzlich hat er die gleiche Leistung wie der Interactive, nur mit besserer Akkulaufleistung.
8) Smartass:
Dies ist der Vorgänger des SmartassV2. Er begrenzt die maxFreq, wenn der Bildschirm aus ist. Er gilt nicht als sehr akkufreundlich wie der SmartassV2. Das liegt daran, dass die minFreq bei eingeschaltetem Display höher ist als die Frequenz-Skalierung während des Standby.
9) Smoothass:
Dieser Governor ist auch ein aufgebohrter Smartass, welcher nur etwas flotter skaliert, was zur Folge hat, dass alles noch etwas weicher und schneller reagiert, aber auch auf Kosten des Akkuverbrauchs geht.
10) Brazilianwax:
Er ist ähnlich wie der SmartassV2, nur aggressiveres Hochskalieren, was mehr Leistung und auch Akkuverbrauch mit sich bringt.
11) SavagedZen:
Ein weiterer SmartassV2-Governor. Er erzielt eine gute Balance zwischen Leistung und Akkuverbrauch und wird eigentlich unterschätzt.
12) Minmax:
Dieser Governor sei eine angenehme Überraschung gewesen. Obwohl er an den Conservative anlehnt, soll er wohl die beste Performance von allen haben. Er habe wohl eine etwas schlechtere Akkulaufleistung wie der SmartassV2, aber soll die beste Spritzigkeit haben, weshalb er auch der Standardgovernor im Nova-Kernel sei.
13) Scary:
Dies sei einer der seltsamsten Governors. Er basiert auf den Conservative, welcher für seine langsame Skalierung bekannt sei, aber habe wiederum Elemente des Smartass, der wiederum als einer der schnellsten skalierfähigen Governore bekannt ist. Einige Leute berichten, dass sie von ihm fasziniert seien. Hörensagen eben.
14) Lazy:
Dieser Governor von ezekeel ist im Grunde einer, der auf den Ondemand basiert, nur mit dem zusätzlichen Parameter min_time_state, was die minimale Zeit der CPU auf einer Frequenz vor der Skalierung nach oben und unten beibehält. Hierbei werden Instabilitäten durch zu schnelle Frequenzwechsel, wie beim Ondemand, vermieden. Der Lazy-Governor stellt zwar öfter Anfragen als der Ondemand, aber wechselt die Frequenz erst nach Abschluss der min_time_state, was heißt so viel wie Stufe nach Stufe (erst 200 MHz, dann 300 MHz, dann 400 MHz, etc.). Dazu kommt noch, dass der Lazy-Governor von Haus aus Parameter beim Abschalten des Displays (Screenoff_maxfreq) mitbringt, d.h. man kann einstellen was die höchste Frequenz in MHz beim Abschalten des Displays sein darf.
15) Lulzactive:
Dieser Governor ist noch recht neu und stammt von tegrak. Er basiert sowohl auf den Interactive- als auch auf den Smartass-Governor.
Die etwas ältere Version: Wenn bei ihr die Arbeitsbelastung größer als oder gleich 60% war, skalierte dieser Governor die CPU in die nächst höhere Stufe. Wenn die Arbeitsbelastung weniger als 60% war, dann skalierte dieser Governor die CPU zur nächst niedrigeren Stufe. Und wenn der Bildschirm ausgeschaltet war, dann wurde die CPU auf die niedrigste skalierbare Frequenz gesperrt.
Die neue Version: Diese Version beinhaltet noch drei weitere konfigurierbare Parameter. inc_cpu_load, pump_up_step und pump_down_step. Diese Parameter verhelfen dem Anwender zu einer größere Kontrolle. Somit kann man den Schwellenwert, bei dem der Governor beschließt auf- oder abzuskalieren, festlegen. Man kann auch eine bestimmte Anzahl von Frequenzstufen festlegen, die beim Abfragen übersprungen werden sollen.
16) Lagfree:
Auch dieser Governor ähnelt dem Ondemand. Der Hauptunterschied liegt darin, dass er wesentlich akkufreundlicher ist. Die Frequenz wird entweder weich herunter gesetzt oder weich herauf gesetzt, anders als beim Ondemand, der bei Anfragen eher gleich auf 100% steigt, obwohl nicht gebraucht. Der Lagfree steigt also stufenweise und überspringt keine Frequenz während die CPU skaliert. Das bedeutet auch, dass dieser Governor bei akut starkem Leistungsbedarf nicht sofort auf 100% steigt und es somit zu Rucklern, wie z.B. bei der Video-Wiedergabe, kommen kann.
17) SmartassV2:
Das ist die überarbeitete Version des Smartass-Governor von erasmux. Dieser Governor verfolgt das Ziel, eine ideale Frequenz zu erreichen und versucht dieses aggressiv zu erreichen und weniger aggressiv zu verlieren. Er benutzt verschiedene ideale Frequenzen beim Anschalten und Abschalten des Displays. Wenn der Display ausgeschaltet ist, skaliert dieser Governor abwärts sehr schnell (aggressiv) und skaliert beim Anschalten des Displays auf bis zu 500 MHz schnell. Im Gegensatz zum kleinen Bruder Smartass gibt es keine Obergrenze für die Frequenz, wenn der Display ausgeschaltet ist. Bei diesem Governor geht es auch um ein Gleichgewicht zwischen Leistung und Akkulaufzeit.
18) Ondemandx:
Dieser Governor ist eigentlich auch ein Ondemand, nur mit dem Unterschied, dass er von Haus aus Profile beim Abschalten und Anschalten des Displays mitbringt. Dieser Governor wurde erstellt um noch akkufreundlicher zu sein. Wenn der Bildschirm ausgeschaltet ist, wird die maximale Frequenz auf 500 MHz gesetzt. Trotz dessen, dass der Ondemand in vielen Kerneln vorhanden ist, da er als stabil gilt, ist die Unterstützung durch den Ondemandx weitreichender, da er trotz der schnellen Schaltfrequenz und dadurch eine geringe Übergangsverzögerung hat, eben auch akkufreundlicher sei. Bei diesem Governor spiele, im Gegensatz zu anderen Governorn, der I/O-Scheduler eine große Rolle.
19) Intellidemand:
Der Intellidemand aka Intelligent Ondemand von faux ist ein weiterer Governor, der auf Ondemand basiert. Anders als manche Nutzer glauben, ist dieser Gouverneur nicht der Ersatz für OC Daemon. Der ursprüngliche Intellidemand verhält sich anders je nach GPU-Nutzung. Wenn die GPU wirklich beschäftigt ist (Spiele, Karten, Benchmarking usw.) verhält sich dieser wie der Ondemand. Wenn die GPU im "Leerlauf" ist (also eher mäßig beansprucht ist), begrenzt der Intellidemand die maximale Frequenz abhängig von den verfügbaren Frequenzen in eurem Gerät bzw. eurem Kernel um Akkuleistung zu sparen. Dies wird als Browsing-Modus bezeichnet. Wir können auch einige "Spuren" vom Interaktive-Governor finden. Frequenz-Skalierungen im unteren Segment hängen von der Leerlaufzeit der CPU ab. Untere Leerlauf-Zeit (<20%) bedeutet eine Herabsetzung der Frequenz-Skalierung von der aktuellen Frequenz. Frequenz-Skalierungsherabsetzungen geschehen in 5%-Schritten von der aktuellen Frequenz.
Zusammenfassend lässt sich sagen, dass dies ein intelligenter Ondemand-Governor ist, der durch den Browsing-Modus die maximale Frequenz begrenzt, wenn die GPU im Leerlauf ist, und, sofern der Browsing-Modus vorhanden ist, sich wie der Ondemand verhält, wenn die GPU nicht ausgelastet ist. Auch der Intellidemand schaltet nicht auf die höchste Frequenz, wenn der Bildschirm ausgeschaltet ist.
20) Lionheart:
Der Lionheart-Governor ist ein optimierter Conservative-Governor und stammt auch von Knzo. Er ist auf extreme Reaktionsfähigkeit und Leistung getrimmt, leider auf Kosten der Akkuleistung.
21) Sleepy:
Der Sleepy (früher bekannt als solo) ist ein Versuch um ein Gleichgewicht zwischen Leistung und Akkulaufleistung zu schaffen. Er basiert auf den getweakten Ondemand von arighi und ist für das SGS2 optimiert. Er beinhaltet imoseyons Ondemandx-Tweaks mit einigen Down_sampling- und anderen Features,welche der User mittels sysfs durch das Setzen von "echo" abrufen kann. Sleepy ist dem Verhalten des Ondemandx , wenn er in Aktion ist, sehr ähnlich.
Er verfügt auch über die arighis fast_start und deep_sleep-Erkennung-Features. Darüber hinaus ist die maximale Frequenz im Suspend-Modus 500Mhz.
21) Hyper
Der Hyper (früher bekannt als kenobi) ist ein aggressiver Smart und Smooth, getweakt und optimiert für das SGS2, basierend auf den Ondemand, welcher von arighi getweakt wurde und mit einigen Ondemandx-Suspend-Features von imoseyon ausgestattet wurde. (Hinzugefügt wurden die Einstellungen suspend_freq mittels sysfs und Imoseyons Suspend Code) Hyper ist dem Verhalten des Ondemand, wenn er in Aktion ist, sehr ähnlich. Er verfügt auch über die arighis fast_start und deep_sleep-Erkennung-Features. Darüber hinaus ist die maximale Frequenz im Suspend-Modus 500Mhz.
22) Pegasusq/Pegasusd
Der Pegasus-q/d ist ein MultiCore-Governor und basiert auf den Ondemand-Governor mit integriertem Hotplugging.
Laufende Prozesse in der Warteschlange: Wir wissen, dass mehrere Prozesse gleichzeitig auf unserem SGS2 laufen können. Diese aktiven Prozesse werden in einem Array, also einem Feld, genannt "Run Queue", also laufende Warteschlange, mit ihren Prioritätswerten angeordnet (Priorität wird vom Task-Scheduler verwendet, der dann entscheidet, welcher Prozess als nächstes laufen soll).
Um sicherzustellen, dass jeder Prozess einen fairen Anteil an Ressourcen hat, läuft jeder für einen bestimmten Zeitraum und wird irgendwann gestoppt und wird dann wieder auch in die Warteschlange gestellt bis er wieder dran ist. Wenn ein Programm beendet wird, damit andere laufen können, wird das Programm mit der höchsten Priorität in der laufenden Warteschlange ausgeführt.
3. Was ist ein Scheduler?
In einem Multitasking-Betriebssystem muss es eine Instanz geben, die den Prozessen, die laufen wollen, Rechenzeit zuteilt und sie nach Ablauf der zugeteilten Zeitspanne (Timeslice) wieder schlafen legt. Diese Instanz bildet der sog. Scheduler, z.B. beim Öffnen und Schließen von Anwendungen. d.h. wie schnell werden sie geöffnet und wie lange sie im RAM gehalten werden.
I/O-Scheduler können viele Zwecke haben wie:
4. Welche Scheduler gibt es?
Legende:
&=Default(standardmäßigeingestellt)
@=standardmäßigabgestellt
*=imStockkernelvorhanden
+=inQuasarkernelnvorhanden
Noop:
Der Noop-Scheduler ist der einfachste von ihnen. Er ist am Besten geeignet für Speichergeräte, die nicht von mechanische Bewegungen abhängig sind, wie unsere Flash-Laufwerke in unseren SGSII's, um den Datenzugriff zu verwenden. Der Vorteil ist, dass Flash-Laufwerke keine Neuanordnung der I/O-Anfragen im Gegensatz zu normalen Festplatten benötigen. d.h. die Daten, die zuerst kommen, werden auch als erstes geschrieben. Er ist im Grunde kein richtiger Scheduler, da er das Scheduling der Hardware überlässt.
Vorteile:
- Fügt alle eingehenden I/O-Anfragen in eine Wer-zuerst-kommt- mahlt- zuerst-Warteschlange und realisiert Anfragen mit der geringsten Anzahl von CPU-Zyklen, deshalb auch akkufreundlich
- Ist bestens für Flashlaufwerke geeignet, da es zu keinerlei Such-Fehlern kommt
- Guter Datendurchsatz auf db-Systemen
Nachteile:
- die Verringerung der Anzahl der CPU-Zyklen entspricht einem gleichzeitig einhergehendem Leistungsabfall
Anticipatory:
Zwei wichtige Dinge sind hier bezeichnend für diesen Scheduler:
- Das Suchen auf dem Flashlaufwerk geht sehr langsam von Statten
- Schreibvorgänge können zwar jeder Zeit abgearbeitet werden, jedoch werden Lesevorgänge vorgezogen, d.h. dieser Scheduler gibt den Lesevorgängen eine höhere Priorität als den Schreibvorgängen.
Vorteile:
- Anfragen von Lese-Zugriffen werden nie sekundär behandelt, d.h. hat ähnlich gute Leseleistung auf Flashlaufwerken wie der Noop
Nachteile:
- Anfragen von Prozessvorgängen sind nicht immer verfügbar
- Verringerte Schreib-Performance auf High-Performance- Festplatten
CFQ:
Der CFQ Completely Fair Queuing , ähnlich wie beim Deadline, verwaltet eine skalierbar durchgehende Prozess-I/O-Warteschlange, d.h. er versucht die verfügbare I/O-Bandbreite fair und gleichmäßig auf alle I/O-Anfragen zu verteilen. Dabei erstellt er eine Statistik zwischen den Blöcken und Prozessen. Durch diese Statistik kann er "erahnen", wann der nächste Block von welchem Prozess angefordert wird, d.h. jede Prozess-Warteschlange enthält synchrone Anfragen von Prozessen, die wiederum abhängig von der Priorität des Ursprungsprozesses ist. Es gibt eine V2 vom CFQ und hat einige Fixes, wie z.B. den I/O-Anfrage-Hunger zu stillen und einige kleine Rückwärtssuchen wurden eingebaut um die Reaktionsfähigkeit zu verbessern.
Vorteile:
- hat das Ziel eine ausgewogene I/O-Performance zu liefern
- am einfachsten einzustellen
- hervorragend auf Multiprozessoren-Systemen
- beste Datenbank-Performance nach dem Deadline
Nachteile:
- Einige User berichteten, dass das Medien-Scanning hierbei sehr sehr lange dauern würde und dies eben durch die faire bzw. gleichmäßige Verteilung der Bandbreite auf die I/O-Operationen während des Bootvorgangs bedingt ist, wobei das Medien-Scanning nicht unbedingt die höchste Priorität haben sollte
- Jitter (worst-case-delay) kann manchmal sehr hoch sein, da die Anzahl der Prozess-Aufgaben untereinander konkurrieren
Deadline:
Dieser Scheduler hat das Ziel, die I/O-Wartezeit einer Prozess-Anfrage zu verringern. Das geschieht anhand der Blocknummern der Daten auf dem Laufwerk. Damit aber auch Blöcke mit stark abweichenden Blocknummern bearbeitet werden, erhält jede Anfrage eine maximale Auslieferungszeit. Dieser Governor ist neben dem BFQ sehr beliebt und in vielen bekannten Kerneln wie Netarchy für das Nexus S enthalten. Er sei zwar besser als der BFQ, aber im Vergleich zum VR soll er schwächer sein.
Vorteile:
- Ist annährend ein Echtzeit-Scheduler.
- Zeichnet sich durch Verringerung der Wartezeit von einzelnen Prozessen aus - Bester Scheduler für Datenbankzugriffen und Abfragen.
- Bandbreitenbedarf eines Prozesses, z.B. wieviel Prozent eine CPU braucht, ist leicht zu berechnen.
- Wie der Noop-Governor hervorragend geeignet für Flashlaufwerke
Nachteile:
- Wenn das System überlastet ist, können eine Reihe von Prozessen verloren gehen, und ist nicht so einfach vorhersehbar
VR:
Im Gegensatz zu anderen Schedulern, werden synchrone und asynchrone Anfragen nicht getrennt behandelt, sondern es wird eine faire bzw. ausgeglichene Frist innerhalb dieser Anfragen verhängt, d.h. die nächste Anfrage, die bedient werden soll, ist abhängig von Abstand der letzten Anfrage. Der VR ist ein sehr guter Scheduler mit Elementen des Deadline-Schedulers. Er soll wahrscheinlich der Beste für MTD-Android-Geräten sein. Er ist derjenige, der die meisten Benchmarkpunkte machen kann, aber er sei auch einer instabilsten Schedulern sein, da seine Leistung schwanke. Mal schwankt sie unterhalb des Durchschnitts, mal schwankt sie oberhalb des Durchschnitts, aber wenn oberhalb, dann ist er der Beste.
Vorteile:
- Ist der beste Scheduler für Benchmarks
Nachteile:
- Performance-Schwankungen können zu unterschiedlichen Ergebnissen führen
- sehr unzverlässig bzw. meistens instabil
Simple:
Wie der Name schon sagt, ist er eher ein simpler bzw. einfacher Scheduler. Speziell für EMMC-Geräte geeignet. Er ist zuverlässig, vielleicht nicht so gut wie der VR, wenn dieser mal einen guten Tag hat, aber er ist trotzalledem sehr leistungsbezogen und gibt sein Bestes. Im Moment ist er der Standard-Scheduler bei Quasar-Kernels.
Vorteile: - nicht bekannt
Nachteile: - nicht bekannt
BFQ:
Anstelle Anfragen in Zeitabschnitte aufzuteilen wie der CFQ, weist der BFQ Budgets auf. Dem Flashlaufwerk wird ein aktiver Prozess gewährt, bis es sein Budget (Anzahl der Sektoren auf dem Flashlaufwerk) aufgebraucht hat. Der BFQ vergibt hohe Budgets an nicht gelesene Aufgaben.
Vorteile:
- Hat eine sehr gute USB-Datentransferrate.
- Sei der beste Scheduler zum Abspielen von HD-Videoaufzeichnungen und Video-Streaming ( da weniger Jitter als CFQ und andere Scheduler)
- Gilt als ein sehr genau arbeitender Scheduler
- Erzielt ca. 30% mehr Datendurchsatz als der CFQ
Nachteile:
- Nicht der beste Scheduler für Benchmarks - Höhere Budgets, die einem Prozess zugewiesen wurden, können die Interaktivität beeinflussen und erhöhte Wartezeit mit sich bringen.
SIO:
Er hat das Ziel, bei minimalem Aufwand eine niedrige Wartezeit bei I/O-Anfragen zu erreichen. Keine Priorität bei Warteschlangen zu setzen, stattdessen einfach die Anfragen zusammenzuführen. Dieser Scheduler ist eine Mischung zwischen dem Noop und dem Deadline. Bei ihm gibt es keine Umstellung oder Sortierung bei Anfragen.
Vorteile:
- Er ist einfach und stabil. - Minimierte Starvations (Hungertod) bei Anfragen
Nachteile:
- Langsame zufällige Lesegeschwindigkeiten auf Flashlaufwerken im Gegensatz zu anderen Schedulern. - Sequentielle Lesegeschwindigkeiten auf Flashlaufwerken auch nicht so gut
5. Wie kann ich den Governor und Scheduler ändern?
Es gibt zwei Möglichkeiten den Governor und Scheduler zu ändern, als auch die Einstellungen zu den Governorn. Entweder händisch, in dem man einen File-Manager wie Root Explorer benutzt und dann zu /sys/devices/system und dort die entsprechenden Dateien auf seine Wünsche verändert, vorausgesetzt man weiß was man da macht oder über eine grafische Oberfläche mittels App wie SetCPU oder Voltage Control. Dies sind die prominentesten Apps, wenn es um das Verstellen der Governor und/oder Scheduler geht.
- SetCPU gibt, neben der Möglichkeit die Taktrate der CPU, das Einstellen von Profilen bei bestimmten Situation, nur die Möglichkeit den Governor zu verändern. Den Scheduler kann man damit nicht verändern.
- Voltage Control kann sowohl den Governor als auch den Scheduler verändern, aber hat keine Möglichkeit Verhaltensprofile einzustellen. Man kann zwar diverse Taktungs-, Governor- und Scheduler-Profile manuell einstellen, aber mehr auch nicht. Trotzdem favorisiere ich den VC, da er schlicht ist und mir die Möglichkeit gibt, auch den Scheduler zu verändern.
Beide Apps gibt es in einer Lite- und Pro-Version im Market zu finden.
Persönlich benutze ich unterschiedliche Governors wie Ondemandx, Smartassv2, Lulzactive oder auch mal den Intellidemand, tendenziell eher den Intellidemand, und wenn der nicht vefügbar ist, dann den Lulzactive. Bei den Schedulern favorisiere ich den Deadline und BFQ, aber momentan eher den Deadline.
Hoffe, ich konnte ein wenig Licht ins Dunkel der Governors und Scheduler bringen. Und wenn nicht, dann p.p. :smilie:
P.S.: Wenn es irgend etwas gibt, was ich ergänzen soll oder irgendwo Fehler vorhanden sind, dann mir bitte per PM melden...Danke...
Quelle: HIER
Unser Super-Moderator mecss hat sich wirklich, in mühevoller Kleinstarbeit diesen tollen Thread erstellt! Ich war so begeistert, dass er es mir erlaubt hat, diesen auch hier in unserem Note2 Forum vorzustellen! Danke dafür
[FAQ] Governors & Schedulers
Aufgrund dessen, dass hier im Forum oftmals die Frage nach dem Sinn von Governors und Schedulers aufgekommen ist, habe ich mir mal die "kleine" Mühe gemacht, die Informationen aus dem XDA zu sammeln, zu übersetzen und hier zusammen zutragen.
Als Quelle dienten mir die Beschreibungen aus dem XDA-Forum. Zum einen von knzo und zum anderen von droidphile. Vielen Dank für deren Mühe.
Da einige Governors und Scheduler für diverse Kernels des SGSII erstellt worden sind, dachte ich mir, dass es eher hierher hingehört. Kann zwar sein, dass es auch generell für andere Kernels und Android-Handys passt, aber ich entschied mich, es hier zu posten.
Quelle: [REF][&Tweaks]KernelGovernors&Modules-Siyah&OtherKernels-xda-developers
Quelle: [REF]QuasarkernelgovernorsandI/Oschedulersmanual xda-developers
Quelle: http://forum.xda-developers.com/show...3#post24233103
1. Was ist ein Governor?
Ein Governor ist ein Treiber zur Regulierung der CPUFreq - CPU-Frequenz. Wie der Name uns schon sagt, ist der Governor der Entscheider, wann bei Vollauslastung die maxFreq - maximale Frequenz - erreicht wird oder wie schnell die minFreq - minimale Frequenz bzw. mittlere Frequenz erreicht wird. Er entscheidet, wann, wie und wie lange die CPU reagiert und trotzdem akkusparend bleibt und trotzdem weiterhin weich arbeitet.
Es gibt sehr sehr viele Arten von Governors. Einige sind für Einkern-Prozessoren und einige nur für Zweikern-Prozessoren ausgelegt. In Stock-Kernels gibt es 5 Governors und in Quasar-Kernels gibt es noch viel mehr.
2.Welche Governors gibt es?
Ich habe bis jetzt 20 Arten von Governors gefunden, wozu ich etwas schreiben kann und ich nachfolgend aufgelistet habe.
1) Ondemand *&
2) Powersave *@
3) Userspace *
4) Conservative *
5) Performance *
6) Interactive +
7) Interactivex +
8) Smartass (Removed as of 2.2i) +
9) Smoothass +
10) Brazilianwax +
11) SavagedZen +
12) Minmax +
13) Scary +
14) Lazy
15) Lulzactive
16) Lagfree
17) SmartassV2
18) Ondemandx
19) Intellidemand
20) Lionheart
21) Sleepy #
22) Hyper #
23) Pegasusq/Pegasusd %/$
Legende:
& = Default (standardmäßig eingestellt)
@ = standardmäßig abgestellt
* = im Stockkernel vorhanden
+ = in Quasarkerneln vorhanden
# = im RedPill-Kernel vorhanden
% = Default-ICS Stockkernel
$ = im Siyah-Kernel vorhanden
1) Ondemand:
Der Ondemand-Governor ist die Standardauswahl, die aufgrund seiner ausgewogenen Einstellungen, die einen guten Kompromiss zwischen Akkulaufleistung und Performance bietet. Allerdings hat er keine Profile beim Ausschalten des Displays (Screen-Off-Profile) oder für das Aufwecken des Handys und reagiert auf Eingaben gleich mit hohen Sprüngen zur Leistung.
2) Powersave:
Bei diesem Governor entspricht die maxFreq der minFreq. Für den alltäglichen Gebrauch ist dieser Governor nicht zu empfehlen.
3) Userspace:
Hier können individuelle Einstellungen statt automatischen Vorgaben eingestellt werden. Ob es funktioniert und wie, weiß anscheinend niemand. Ist schon komisch.
4) Conservative:
Er ist eher ein langsamer Vertreter seiner Art und ist eher ein langsamer Ondemand, welcher langsam hochskaliert um den Akku zu schonen. Zur Verdeutlichung ein Beispiel an Hand des Ondemand. Der Ondemand erhöht bei einer Interaktivität des Smartphones die Frequenz bis auf maxFreq. Der Conservative hingegen tut das um die Hälfte langsamer und spart dabei Akkulaufleistung, aber auf Kosten der Performance.
5) Performance:
Hier entspricht die minFreq der maxFreq, also genau umgekehrt wie beim Powersave, was bedeutet, dass beim Performance-Governor immer die maximale Frequenz eingestellt ist und den Akku in die Knie zwingt. Ist somit nur für Benchmarks zu gebrauchen.
6) Interactive:
Dieser Governor ist eher ein schnellerer Ondemand. Etwas flotter und akkufreundlicher. Anstelle von regelmäßigen Anfragen in jedem Intervall wie der Ondemand, bestimmt der Interactive wie er hochskaliert, wenn die CPU aus dem Standby aufgeweckt wird. Er ist wegen seiner Stabilitätsoptimierung ein intelligenter Ondemand. Dies ist der beliebteste Governor der letzten Jahre.
7) Interactivex:
Dies ist ein Interactive nur mit Aufweck-Profilen und ist auch akkufreundlicher als der Interactive. Grundsätzlich hat er die gleiche Leistung wie der Interactive, nur mit besserer Akkulaufleistung.
8) Smartass:
Dies ist der Vorgänger des SmartassV2. Er begrenzt die maxFreq, wenn der Bildschirm aus ist. Er gilt nicht als sehr akkufreundlich wie der SmartassV2. Das liegt daran, dass die minFreq bei eingeschaltetem Display höher ist als die Frequenz-Skalierung während des Standby.
9) Smoothass:
Dieser Governor ist auch ein aufgebohrter Smartass, welcher nur etwas flotter skaliert, was zur Folge hat, dass alles noch etwas weicher und schneller reagiert, aber auch auf Kosten des Akkuverbrauchs geht.
10) Brazilianwax:
Er ist ähnlich wie der SmartassV2, nur aggressiveres Hochskalieren, was mehr Leistung und auch Akkuverbrauch mit sich bringt.
11) SavagedZen:
Ein weiterer SmartassV2-Governor. Er erzielt eine gute Balance zwischen Leistung und Akkuverbrauch und wird eigentlich unterschätzt.
12) Minmax:
Dieser Governor sei eine angenehme Überraschung gewesen. Obwohl er an den Conservative anlehnt, soll er wohl die beste Performance von allen haben. Er habe wohl eine etwas schlechtere Akkulaufleistung wie der SmartassV2, aber soll die beste Spritzigkeit haben, weshalb er auch der Standardgovernor im Nova-Kernel sei.
13) Scary:
Dies sei einer der seltsamsten Governors. Er basiert auf den Conservative, welcher für seine langsame Skalierung bekannt sei, aber habe wiederum Elemente des Smartass, der wiederum als einer der schnellsten skalierfähigen Governore bekannt ist. Einige Leute berichten, dass sie von ihm fasziniert seien. Hörensagen eben.
14) Lazy:
Dieser Governor von ezekeel ist im Grunde einer, der auf den Ondemand basiert, nur mit dem zusätzlichen Parameter min_time_state, was die minimale Zeit der CPU auf einer Frequenz vor der Skalierung nach oben und unten beibehält. Hierbei werden Instabilitäten durch zu schnelle Frequenzwechsel, wie beim Ondemand, vermieden. Der Lazy-Governor stellt zwar öfter Anfragen als der Ondemand, aber wechselt die Frequenz erst nach Abschluss der min_time_state, was heißt so viel wie Stufe nach Stufe (erst 200 MHz, dann 300 MHz, dann 400 MHz, etc.). Dazu kommt noch, dass der Lazy-Governor von Haus aus Parameter beim Abschalten des Displays (Screenoff_maxfreq) mitbringt, d.h. man kann einstellen was die höchste Frequenz in MHz beim Abschalten des Displays sein darf.
15) Lulzactive:
Dieser Governor ist noch recht neu und stammt von tegrak. Er basiert sowohl auf den Interactive- als auch auf den Smartass-Governor.
Die etwas ältere Version: Wenn bei ihr die Arbeitsbelastung größer als oder gleich 60% war, skalierte dieser Governor die CPU in die nächst höhere Stufe. Wenn die Arbeitsbelastung weniger als 60% war, dann skalierte dieser Governor die CPU zur nächst niedrigeren Stufe. Und wenn der Bildschirm ausgeschaltet war, dann wurde die CPU auf die niedrigste skalierbare Frequenz gesperrt.
Die neue Version: Diese Version beinhaltet noch drei weitere konfigurierbare Parameter. inc_cpu_load, pump_up_step und pump_down_step. Diese Parameter verhelfen dem Anwender zu einer größere Kontrolle. Somit kann man den Schwellenwert, bei dem der Governor beschließt auf- oder abzuskalieren, festlegen. Man kann auch eine bestimmte Anzahl von Frequenzstufen festlegen, die beim Abfragen übersprungen werden sollen.
16) Lagfree:
Auch dieser Governor ähnelt dem Ondemand. Der Hauptunterschied liegt darin, dass er wesentlich akkufreundlicher ist. Die Frequenz wird entweder weich herunter gesetzt oder weich herauf gesetzt, anders als beim Ondemand, der bei Anfragen eher gleich auf 100% steigt, obwohl nicht gebraucht. Der Lagfree steigt also stufenweise und überspringt keine Frequenz während die CPU skaliert. Das bedeutet auch, dass dieser Governor bei akut starkem Leistungsbedarf nicht sofort auf 100% steigt und es somit zu Rucklern, wie z.B. bei der Video-Wiedergabe, kommen kann.
17) SmartassV2:
Das ist die überarbeitete Version des Smartass-Governor von erasmux. Dieser Governor verfolgt das Ziel, eine ideale Frequenz zu erreichen und versucht dieses aggressiv zu erreichen und weniger aggressiv zu verlieren. Er benutzt verschiedene ideale Frequenzen beim Anschalten und Abschalten des Displays. Wenn der Display ausgeschaltet ist, skaliert dieser Governor abwärts sehr schnell (aggressiv) und skaliert beim Anschalten des Displays auf bis zu 500 MHz schnell. Im Gegensatz zum kleinen Bruder Smartass gibt es keine Obergrenze für die Frequenz, wenn der Display ausgeschaltet ist. Bei diesem Governor geht es auch um ein Gleichgewicht zwischen Leistung und Akkulaufzeit.
18) Ondemandx:
Dieser Governor ist eigentlich auch ein Ondemand, nur mit dem Unterschied, dass er von Haus aus Profile beim Abschalten und Anschalten des Displays mitbringt. Dieser Governor wurde erstellt um noch akkufreundlicher zu sein. Wenn der Bildschirm ausgeschaltet ist, wird die maximale Frequenz auf 500 MHz gesetzt. Trotz dessen, dass der Ondemand in vielen Kerneln vorhanden ist, da er als stabil gilt, ist die Unterstützung durch den Ondemandx weitreichender, da er trotz der schnellen Schaltfrequenz und dadurch eine geringe Übergangsverzögerung hat, eben auch akkufreundlicher sei. Bei diesem Governor spiele, im Gegensatz zu anderen Governorn, der I/O-Scheduler eine große Rolle.
19) Intellidemand:
Der Intellidemand aka Intelligent Ondemand von faux ist ein weiterer Governor, der auf Ondemand basiert. Anders als manche Nutzer glauben, ist dieser Gouverneur nicht der Ersatz für OC Daemon. Der ursprüngliche Intellidemand verhält sich anders je nach GPU-Nutzung. Wenn die GPU wirklich beschäftigt ist (Spiele, Karten, Benchmarking usw.) verhält sich dieser wie der Ondemand. Wenn die GPU im "Leerlauf" ist (also eher mäßig beansprucht ist), begrenzt der Intellidemand die maximale Frequenz abhängig von den verfügbaren Frequenzen in eurem Gerät bzw. eurem Kernel um Akkuleistung zu sparen. Dies wird als Browsing-Modus bezeichnet. Wir können auch einige "Spuren" vom Interaktive-Governor finden. Frequenz-Skalierungen im unteren Segment hängen von der Leerlaufzeit der CPU ab. Untere Leerlauf-Zeit (<20%) bedeutet eine Herabsetzung der Frequenz-Skalierung von der aktuellen Frequenz. Frequenz-Skalierungsherabsetzungen geschehen in 5%-Schritten von der aktuellen Frequenz.
Zusammenfassend lässt sich sagen, dass dies ein intelligenter Ondemand-Governor ist, der durch den Browsing-Modus die maximale Frequenz begrenzt, wenn die GPU im Leerlauf ist, und, sofern der Browsing-Modus vorhanden ist, sich wie der Ondemand verhält, wenn die GPU nicht ausgelastet ist. Auch der Intellidemand schaltet nicht auf die höchste Frequenz, wenn der Bildschirm ausgeschaltet ist.
20) Lionheart:
Der Lionheart-Governor ist ein optimierter Conservative-Governor und stammt auch von Knzo. Er ist auf extreme Reaktionsfähigkeit und Leistung getrimmt, leider auf Kosten der Akkuleistung.
21) Sleepy:
Der Sleepy (früher bekannt als solo) ist ein Versuch um ein Gleichgewicht zwischen Leistung und Akkulaufleistung zu schaffen. Er basiert auf den getweakten Ondemand von arighi und ist für das SGS2 optimiert. Er beinhaltet imoseyons Ondemandx-Tweaks mit einigen Down_sampling- und anderen Features,welche der User mittels sysfs durch das Setzen von "echo" abrufen kann. Sleepy ist dem Verhalten des Ondemandx , wenn er in Aktion ist, sehr ähnlich.
Er verfügt auch über die arighis fast_start und deep_sleep-Erkennung-Features. Darüber hinaus ist die maximale Frequenz im Suspend-Modus 500Mhz.
21) Hyper
Der Hyper (früher bekannt als kenobi) ist ein aggressiver Smart und Smooth, getweakt und optimiert für das SGS2, basierend auf den Ondemand, welcher von arighi getweakt wurde und mit einigen Ondemandx-Suspend-Features von imoseyon ausgestattet wurde. (Hinzugefügt wurden die Einstellungen suspend_freq mittels sysfs und Imoseyons Suspend Code) Hyper ist dem Verhalten des Ondemand, wenn er in Aktion ist, sehr ähnlich. Er verfügt auch über die arighis fast_start und deep_sleep-Erkennung-Features. Darüber hinaus ist die maximale Frequenz im Suspend-Modus 500Mhz.
22) Pegasusq/Pegasusd
Der Pegasus-q/d ist ein MultiCore-Governor und basiert auf den Ondemand-Governor mit integriertem Hotplugging.
Laufende Prozesse in der Warteschlange: Wir wissen, dass mehrere Prozesse gleichzeitig auf unserem SGS2 laufen können. Diese aktiven Prozesse werden in einem Array, also einem Feld, genannt "Run Queue", also laufende Warteschlange, mit ihren Prioritätswerten angeordnet (Priorität wird vom Task-Scheduler verwendet, der dann entscheidet, welcher Prozess als nächstes laufen soll).
Um sicherzustellen, dass jeder Prozess einen fairen Anteil an Ressourcen hat, läuft jeder für einen bestimmten Zeitraum und wird irgendwann gestoppt und wird dann wieder auch in die Warteschlange gestellt bis er wieder dran ist. Wenn ein Programm beendet wird, damit andere laufen können, wird das Programm mit der höchsten Priorität in der laufenden Warteschlange ausgeführt.
3. Was ist ein Scheduler?
In einem Multitasking-Betriebssystem muss es eine Instanz geben, die den Prozessen, die laufen wollen, Rechenzeit zuteilt und sie nach Ablauf der zugeteilten Zeitspanne (Timeslice) wieder schlafen legt. Diese Instanz bildet der sog. Scheduler, z.B. beim Öffnen und Schließen von Anwendungen. d.h. wie schnell werden sie geöffnet und wie lange sie im RAM gehalten werden.
I/O-Scheduler können viele Zwecke haben wie:
- Zeit beim Suchen auf der Festplatte zu minimieren
- Prioritäten setzen bei bestimmten Prozess-Anfragen
- Einen bestimmten Teil der Bandbreite des Datenträgers zu jedem laufenden Prozess zu regulieren
- Bestimmte Prozess-Anfragen innerhalb einer bestimmten Zeit zu garantieren
4. Welche Scheduler gibt es?
- Noop *
- Anticipatory *@+
- CFQ *&
- Deadline *@+
- VR +
- Simple +&
- BFQ #
- Sio &+
Legende:
&=Default(standardmäßigeingestellt)
@=standardmäßigabgestellt
*=imStockkernelvorhanden
+=inQuasarkernelnvorhanden
Noop:
Der Noop-Scheduler ist der einfachste von ihnen. Er ist am Besten geeignet für Speichergeräte, die nicht von mechanische Bewegungen abhängig sind, wie unsere Flash-Laufwerke in unseren SGSII's, um den Datenzugriff zu verwenden. Der Vorteil ist, dass Flash-Laufwerke keine Neuanordnung der I/O-Anfragen im Gegensatz zu normalen Festplatten benötigen. d.h. die Daten, die zuerst kommen, werden auch als erstes geschrieben. Er ist im Grunde kein richtiger Scheduler, da er das Scheduling der Hardware überlässt.
Vorteile:
- Fügt alle eingehenden I/O-Anfragen in eine Wer-zuerst-kommt- mahlt- zuerst-Warteschlange und realisiert Anfragen mit der geringsten Anzahl von CPU-Zyklen, deshalb auch akkufreundlich
- Ist bestens für Flashlaufwerke geeignet, da es zu keinerlei Such-Fehlern kommt
- Guter Datendurchsatz auf db-Systemen
Nachteile:
- die Verringerung der Anzahl der CPU-Zyklen entspricht einem gleichzeitig einhergehendem Leistungsabfall
Anticipatory:
Zwei wichtige Dinge sind hier bezeichnend für diesen Scheduler:
- Das Suchen auf dem Flashlaufwerk geht sehr langsam von Statten
- Schreibvorgänge können zwar jeder Zeit abgearbeitet werden, jedoch werden Lesevorgänge vorgezogen, d.h. dieser Scheduler gibt den Lesevorgängen eine höhere Priorität als den Schreibvorgängen.
Vorteile:
- Anfragen von Lese-Zugriffen werden nie sekundär behandelt, d.h. hat ähnlich gute Leseleistung auf Flashlaufwerken wie der Noop
Nachteile:
- Anfragen von Prozessvorgängen sind nicht immer verfügbar
- Verringerte Schreib-Performance auf High-Performance- Festplatten
CFQ:
Der CFQ Completely Fair Queuing , ähnlich wie beim Deadline, verwaltet eine skalierbar durchgehende Prozess-I/O-Warteschlange, d.h. er versucht die verfügbare I/O-Bandbreite fair und gleichmäßig auf alle I/O-Anfragen zu verteilen. Dabei erstellt er eine Statistik zwischen den Blöcken und Prozessen. Durch diese Statistik kann er "erahnen", wann der nächste Block von welchem Prozess angefordert wird, d.h. jede Prozess-Warteschlange enthält synchrone Anfragen von Prozessen, die wiederum abhängig von der Priorität des Ursprungsprozesses ist. Es gibt eine V2 vom CFQ und hat einige Fixes, wie z.B. den I/O-Anfrage-Hunger zu stillen und einige kleine Rückwärtssuchen wurden eingebaut um die Reaktionsfähigkeit zu verbessern.
Vorteile:
- hat das Ziel eine ausgewogene I/O-Performance zu liefern
- am einfachsten einzustellen
- hervorragend auf Multiprozessoren-Systemen
- beste Datenbank-Performance nach dem Deadline
Nachteile:
- Einige User berichteten, dass das Medien-Scanning hierbei sehr sehr lange dauern würde und dies eben durch die faire bzw. gleichmäßige Verteilung der Bandbreite auf die I/O-Operationen während des Bootvorgangs bedingt ist, wobei das Medien-Scanning nicht unbedingt die höchste Priorität haben sollte
- Jitter (worst-case-delay) kann manchmal sehr hoch sein, da die Anzahl der Prozess-Aufgaben untereinander konkurrieren
Deadline:
Dieser Scheduler hat das Ziel, die I/O-Wartezeit einer Prozess-Anfrage zu verringern. Das geschieht anhand der Blocknummern der Daten auf dem Laufwerk. Damit aber auch Blöcke mit stark abweichenden Blocknummern bearbeitet werden, erhält jede Anfrage eine maximale Auslieferungszeit. Dieser Governor ist neben dem BFQ sehr beliebt und in vielen bekannten Kerneln wie Netarchy für das Nexus S enthalten. Er sei zwar besser als der BFQ, aber im Vergleich zum VR soll er schwächer sein.
Vorteile:
- Ist annährend ein Echtzeit-Scheduler.
- Zeichnet sich durch Verringerung der Wartezeit von einzelnen Prozessen aus - Bester Scheduler für Datenbankzugriffen und Abfragen.
- Bandbreitenbedarf eines Prozesses, z.B. wieviel Prozent eine CPU braucht, ist leicht zu berechnen.
- Wie der Noop-Governor hervorragend geeignet für Flashlaufwerke
Nachteile:
- Wenn das System überlastet ist, können eine Reihe von Prozessen verloren gehen, und ist nicht so einfach vorhersehbar
VR:
Im Gegensatz zu anderen Schedulern, werden synchrone und asynchrone Anfragen nicht getrennt behandelt, sondern es wird eine faire bzw. ausgeglichene Frist innerhalb dieser Anfragen verhängt, d.h. die nächste Anfrage, die bedient werden soll, ist abhängig von Abstand der letzten Anfrage. Der VR ist ein sehr guter Scheduler mit Elementen des Deadline-Schedulers. Er soll wahrscheinlich der Beste für MTD-Android-Geräten sein. Er ist derjenige, der die meisten Benchmarkpunkte machen kann, aber er sei auch einer instabilsten Schedulern sein, da seine Leistung schwanke. Mal schwankt sie unterhalb des Durchschnitts, mal schwankt sie oberhalb des Durchschnitts, aber wenn oberhalb, dann ist er der Beste.
Vorteile:
- Ist der beste Scheduler für Benchmarks
Nachteile:
- Performance-Schwankungen können zu unterschiedlichen Ergebnissen führen
- sehr unzverlässig bzw. meistens instabil
Simple:
Wie der Name schon sagt, ist er eher ein simpler bzw. einfacher Scheduler. Speziell für EMMC-Geräte geeignet. Er ist zuverlässig, vielleicht nicht so gut wie der VR, wenn dieser mal einen guten Tag hat, aber er ist trotzalledem sehr leistungsbezogen und gibt sein Bestes. Im Moment ist er der Standard-Scheduler bei Quasar-Kernels.
Vorteile: - nicht bekannt
Nachteile: - nicht bekannt
BFQ:
Anstelle Anfragen in Zeitabschnitte aufzuteilen wie der CFQ, weist der BFQ Budgets auf. Dem Flashlaufwerk wird ein aktiver Prozess gewährt, bis es sein Budget (Anzahl der Sektoren auf dem Flashlaufwerk) aufgebraucht hat. Der BFQ vergibt hohe Budgets an nicht gelesene Aufgaben.
Vorteile:
- Hat eine sehr gute USB-Datentransferrate.
- Sei der beste Scheduler zum Abspielen von HD-Videoaufzeichnungen und Video-Streaming ( da weniger Jitter als CFQ und andere Scheduler)
- Gilt als ein sehr genau arbeitender Scheduler
- Erzielt ca. 30% mehr Datendurchsatz als der CFQ
Nachteile:
- Nicht der beste Scheduler für Benchmarks - Höhere Budgets, die einem Prozess zugewiesen wurden, können die Interaktivität beeinflussen und erhöhte Wartezeit mit sich bringen.
SIO:
Er hat das Ziel, bei minimalem Aufwand eine niedrige Wartezeit bei I/O-Anfragen zu erreichen. Keine Priorität bei Warteschlangen zu setzen, stattdessen einfach die Anfragen zusammenzuführen. Dieser Scheduler ist eine Mischung zwischen dem Noop und dem Deadline. Bei ihm gibt es keine Umstellung oder Sortierung bei Anfragen.
Vorteile:
- Er ist einfach und stabil. - Minimierte Starvations (Hungertod) bei Anfragen
Nachteile:
- Langsame zufällige Lesegeschwindigkeiten auf Flashlaufwerken im Gegensatz zu anderen Schedulern. - Sequentielle Lesegeschwindigkeiten auf Flashlaufwerken auch nicht so gut
5. Wie kann ich den Governor und Scheduler ändern?
Es gibt zwei Möglichkeiten den Governor und Scheduler zu ändern, als auch die Einstellungen zu den Governorn. Entweder händisch, in dem man einen File-Manager wie Root Explorer benutzt und dann zu /sys/devices/system und dort die entsprechenden Dateien auf seine Wünsche verändert, vorausgesetzt man weiß was man da macht oder über eine grafische Oberfläche mittels App wie SetCPU oder Voltage Control. Dies sind die prominentesten Apps, wenn es um das Verstellen der Governor und/oder Scheduler geht.
- SetCPU gibt, neben der Möglichkeit die Taktrate der CPU, das Einstellen von Profilen bei bestimmten Situation, nur die Möglichkeit den Governor zu verändern. Den Scheduler kann man damit nicht verändern.
- Voltage Control kann sowohl den Governor als auch den Scheduler verändern, aber hat keine Möglichkeit Verhaltensprofile einzustellen. Man kann zwar diverse Taktungs-, Governor- und Scheduler-Profile manuell einstellen, aber mehr auch nicht. Trotzdem favorisiere ich den VC, da er schlicht ist und mir die Möglichkeit gibt, auch den Scheduler zu verändern.
Beide Apps gibt es in einer Lite- und Pro-Version im Market zu finden.
Persönlich benutze ich unterschiedliche Governors wie Ondemandx, Smartassv2, Lulzactive oder auch mal den Intellidemand, tendenziell eher den Intellidemand, und wenn der nicht vefügbar ist, dann den Lulzactive. Bei den Schedulern favorisiere ich den Deadline und BFQ, aber momentan eher den Deadline.
Hoffe, ich konnte ein wenig Licht ins Dunkel der Governors und Scheduler bringen. Und wenn nicht, dann p.p. :smilie:
P.S.: Wenn es irgend etwas gibt, was ich ergänzen soll oder irgendwo Fehler vorhanden sind, dann mir bitte per PM melden...Danke...
Quelle: HIER