Guten Abend liebe Forengemeinde,
Beim Galaxy S3 wurde ein neuer Govenor hinzugefügt, der pegasusq. Gökhan hat ihn bereits auf das S2 portiert, und daher kennen ihn vielleicht einige schon. Nun, wie verändere ich dessen Parameter, und was bedeuten sie? Ich habe hier einige der Punkte Sinngemäss übersetzt, um es auch Usern die mit der Englischen Sprache etwas Mühe haben zugänglich zu machen. Bin aber für Vorschläge, Tipps oder Anregungen offen.
FAQ - Govenors u. Sheduler
Tweaks / Parameter für Govenors
sampling_rate: (wie oft die CPU abgefragt wird, um zu entscheiden ob hoch -oder runter skaliert wird)
up_threshold: (% Auslastung ab der hoch skaliert wird)
sampling_down_factor: (Dient als Multiplikator des "sampling_rate" Wertes, um zu entscheiden wie schnell nach Neuberechnung der aktuellen Auslastung bei Vollast runter skaliert wird. "1" bedeutet "sampling_rate = "sampling_down_factor", jede andere Zahl multipliziert die 500000 mikrosekunden. Dieser Wert gilt nur für die oberen Frequenzen, oder hoher Auslastung. Beachte dass die CPU automatisch auf "max frequency" skaliert, wenn "max_load_freq" grösser ist als "up_threshold" x "current frequency". "max_load_freq" ist ein willkürlicher Wert, der aus "maximum of load_frequencies" berechnet wird. "load_frequency" ist auch ein willkürlicher Wert, welcher die Frequenz beschreibt, bei der das Gerät theoretisch mit 100% Auslastung umgehen kann, errechnet aus "load" x "average_frequency" (Durchschnitts-Frequenz))
ignore_nice_load: 0 (Auf "1" werden "low-level prozesse" beim skalierien ignoriert)
io_is_busy: 0 (bei "1" werden ressourcenintensive Anwendungen durch den Sheduler etwas anders behandelt)
down_differential: 5 (Nachdem die Zeit von "sampling_rate* x "sampling_down_factor" verstrichen ist, wird Versucht eine niedrigere Frequenz zu wählen, welche aber nicht den "up_threshold" (85%) bei der nächsten Abfrage auslösen wird. Das "down_differential" ist auch dazu da, dass nicht zu schnell herunterskaliert wird. Gerechnet wird Folgendermassen: "Max_load_freq" (bei mir 1400mhz) wird gegen (up_threshold - down_differential) x "current frequency" (aktuelle Frequenz) gerechnet)
freq_step: 40 (Definiert um wieviel Prozent der "max_frequency" hochskaliert werden soll, wenn die Auslastung den "up_threshold" erreicht. Der Wert entspricht "40" = 1400mhz/100x40 = 560mhz. Das heisst, wenn bei 200mhz die 85% erreicht werden, skaliert die CPU 560mhz hoch, gerundet auf 100 = 600mhz = 800mhz entspricht dann der nächsten Frequenz. Hier können Akkufreaks natürlich rumspielen und schauen ab wann es zu Lags kommt)
cpu_up_rate: (Anzahl der Abfragen um die Auslastung beim hoch skalieren zu berechnen. Sobald die Abfragen für eine Frequenz ausgeführt wurden, wird die "scale-up logic ausgeführt. Bevor die CPU hoch skaliert wird, bleibt die CPU auf "cpu_up_rate" x "sampling_rate" in Mikrosekunden auf der jeweiligen Frequenz)
cpu_down_rate: (Anzahl der Abfragen um die Auslastung beim runter skalieren zu berechnen. Sobald die Abfragen für eine Frequenz ausgeführt wurden, wird die "scale-down logic" ausgeführt. Bevor also runter skaliert wird, bleibt die CPU auf "cpu_down_rate" x "sampling_rate" in Mikrosekunden auf der jeweiligen Frequenz)
cpu_up_freq: (Nicht ganz schlüssig, führt aber dazu, dass 300mhz und 400mhz nicht genutzt werden)
cpu_down_freq: (Nicht ganz schlüssig, hat aber etwas mit der min_freq zu tun)
up_nr_cpus: 1 (Wie viele CPUs mindestens im Einsatz sind, und bei der Entscheidung des Hot Pluggings berücksichtigs wird)
max_cpu_lock:
hotplug_lock:
dvfs_debug: (Kernel debugging aus "0" an "1")
hotplug_freq 1 1: (zuschalten des nächsten Kernes beim hoch skalieren)
hotplug_freq 2 0: (abschalten des Kernes beim runter skalieren)
hotplug_freq 2 1: (wie 1 1)
hotplug_freq 3 0: (wie 2 0)
hotplug_freq 3 1: (wie 1 1)
hotplug_freq 3 0: (wie 2 0)
hotplug_rq 1 1: (Schwellenwert für die Lauflänge der Warteschlange bis der nächste Kern beim hoch skalieren zugeschaltet wird)
hotplug_rq 2 0: (Schwellenwert für die Lauflänge der Warteschlange bis der nächste Kern beim runter skalieren ausgeschaltet wird)
hotplug_rq 2 1: (wie 1 1)
hotplug_rq 3 0: (wie 2 0)
hotplug_rq 3 1: (wie 1 1)
hotplug_rq 4 0: (wie 2 0)
up_threshold_at_min_freq: (Schwellenwert der mit freq_of_responsiveness zusammenarbeitet, d.h bei Mindestfrequenz bis zur freq_of_responsiveness (500mhz z.B.) wird ab diesem threshold hoch skaliert. Danach wird der obere up_threshold genutzt)
freq_for_responsiveness: (Bis zu dieser Frequenz wird der up_threshold_at_min_freq als Trigger genutzt. Danach löst der up_threshold den Trigger zum hoch skalieren aus .Diese Frequenz wird auch dazu genutzt, um der CPU beim runter skalieren zu helfen die beste Frequenz zu finden. Eine, die beim nächsten Abfragen den "up_threshold" nicht sofort wieder auslöst.
Höhere Werte bei den "hotplug_freq" führen dazu, dass die Kerne erst ab "Wert" der kH (500000 = 500mhz) beim hoch skalieren zugeschalten (hotplug_freq 1 1, 2 1, 3 1) und beim runter skalieren wieder ausgeschalten werden (hotplug_freq 2 0, 3 0, 4 0)
Höhere Werte bei "hotplug_rq" führen dazu, dass die Kerne erst ab "Wert" der Warteschlange beim hoch skalieren zugeschalten (hotplug_rq 1 1, 2 1, 3 1), und beim runter skalieren wieder ausgeschalten werden (hotplug_rq 2 0, 3 0, 4 0)
Experimentiert selber etwas damit rum, und nutzt um es zu beobachten die App "Cool Tool". Vergesst nicht unter "Advanced" die "Multicore CPU Gauge" einzuschalten.
hells
