Parameter für den pegasusq Govenor

H

hellsgod

Gast
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 :)

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.

QUELLE: http://forum.xda-developers.com/showpost.php?p=24233103&postcount=3

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
 
Zuletzt bearbeitet von einem Moderator:
  • Danke
Reaktionen: Alex0901, Andrenalin1981, nobody573 und 8 andere
Platzhalter für Beispiele - Nächste Woche dann, sobald ich beim Abbauen des Open Airs fertig bin ;)

hells

Gesendet von meinem GT-I9300 mit Tapatalk 2
 
Ich kann den Platzhalter leider nicht mehr bearbeiten, ich wäre deshalb froh, wenn dieser von einem Mod gelöscht, oder bearbeitet wird.

Samsung Werte für den pegasusq:

sampling_rate: 50000
up_threshold: 85
sampling_down_factor: 2
ignore_nice_load: 0
io_is_busy: 0
down_differential: 5
freq_step: 40
cpu_up_rate: 10
cpu_down_rate: 20
cpu_up_freq: 500000
cpu_down_freq: 200000
up_nr_cpus: 1
max_cpu_lock: 0
hotplug_lock: 0
dvfs_debug: 0
hotplug_freq 1 1: 500000
hotplug_freq 2 0: 200000
hotplug_freq 2 1: 500000
hotplug_freq 3 0: 200000
hotplug_freq 3 1: 500000
hotplug_freq 3 0: 200000
hotplug_rq 1 1: 100
hotplug_rq 2 0: 100
hotplug_rq 2 1: 200
hotplug_rq 3 0: 200
hotplug_rq 3 1: 300
hotplug_rq 4 0: 300

Ziemlich aggressive Werte, auf das Hot Plugging bezogen, kann also gut sein, dass wenn die vier Kerne einmal laufen, diese permanent aktiv bleiben. Ich finde es ziemlich unnötig, beim Homescreen switchen oder lesen mit allen vier Kernen unterwegs zu sein...

Siyah Werte für pegasusq (1.2.3)

sampling_rate: 50000
up_threshold: 85
sampling_down_factor: 2
ignore_nice_load: 0
io_is_busy: 0
down_differential: 5
freq_step: 40
cpu_up_rate: 10
cpu_down_rate: 20
cpu_up_freq: 500000
cpu_down_freq: 200000
up_nr_cpus: 1
max_cpu_lock: 0
hotplug_lock: 0
dvfs_debug: 0
hotplug_freq 1 1: 500000
hotplug_freq 2 0: 400000
hotplug_freq 2 1: 500000
hotplug_freq 3 0: 400000
hotplug_freq 3 1: 800000
hotplug_freq 3 0: 500000
hotplug_rq 1 1: 200
hotplug_rq 2 0: 200
hotplug_rq 2 1: 300
hotplug_rq 3 0: 300
hotplug_rq 3 1: 400
hotplug_rq 4 0: 400
up_threshold_at_min_freq: 80
freq_for_responsiveness: 500000

Das fett gedruckte sind die Änderungen beim Siyah. Die Werte vom Siyah emfpinde ich als sehr ausgewogen vom Hot Plugging her, die nicht benötigten Kerne werden relativ schnell wieder ausgeschaltet, und es laufen dann höchstens mal zwei beim Homescreen Switchen. Beim lesen, also idle ist oft nur ein Kern aktiv. So soll es meiner Meinung nach auch sein!

Wo kann noch geschraubt werden?

Beim Hot Plug würde ich die Siyah Werte nehmen, oder übernehmen wenn man einen anderen Kernel hat. Auch da kann natürlich noch etwas runter oder hoch geschraubt werden, ich würde es aber dabei belassen. Um eine gleichmässige Verteilung auf die Frequenzen zu erreichen, kann man auch den "freg_step" Wert etwas nach Unten korrigieren, da 40(%) auf 100mhz gerundet 600mhz entspricht. Man kann da durchaus 10-15% weiter runter. Da jedoch jedes Gerät hierbei etwas anders reagiert, möchte ich euch keine Werte vorkauen. Bedenkt aber, dass bei dem Wert "40" zwei Mal skaliert wird, (von 200 auf 800 und dann 1400) und je weiter runter man mit diesem Wert geht, desto mehr Skalierungsvorgänge werden benötigt, bis die "max_freq" erreicht wird.

Um etwas "zackiger" zu skalieren kann man auch gut den Wert bei "sampling_rate" auf 40000 setzen.

Falls noch Anregungen oder Fragen sind, schiesst los :)

hells
 
  • Danke
Reaktionen: Milchbeck, craP_cillA und TAT1980
ich hab da noch ne frage, beim siyah kann ich jetzt pegasusq und hotplug einstellen. wenn ich unter dem tab gouvernor kein haken setze, ist dann das ganze profil garnicht aktiviert?

so nun zur frage, was ist das neben den gouvernor einstellungen, mit
sio, cfg, noob, deadline??? was genau machen diese scheduler???
 
Standartmässig ist bei ExTweaks der pegasusq drin, einen anderen Govenor würd ich nicht nehmen, da diese noch "alte" Hot Plug Einstellungen verwenden.

Die Sheduler sind dazu da, die Prozesse zu verarbeiten, Entscheidungen treffen welcher Prozess zuerst bearbeitet wird. Im S2 Bereich bei den Kernel gibt es noch ein FAQ zum Thema Govenor und Sheduler. Bin grad mit tapa unterwegs, kann dir den Link grad nicht geben, sollte aber leicht zu finden sein.

hells

Gesendet von meinem GT-I9300 mit Tapatalk 2
 
So schnell habe ich nicht mit der Antwort gerechnet. Danke schön.
Ja hab jetzt einiges gelesen.
Welchen scheduler nimmst du denn oder würdest empfehlen?
Bisher fand ich den dfg am besten.
 

Ähnliche Themen

Oebbler
Antworten
4
Aufrufe
1.749
Oebbler
Oebbler
Oebbler
Antworten
0
Aufrufe
1.971
Oebbler
Oebbler
mecss
  • Gesperrt
  • Angepinnt
  • mecss
Antworten
2
Aufrufe
14.371
mecss
mecss
Zurück
Oben Unten