1. Nimm jetzt an unserem Uhans - 3. ADVENT - Gewinnspiel teil - Alle Informationen findest Du hier!

Parameter für den pegasusq Govenor

Dieses Thema im Forum "Kernel für Samsung Galaxy S3" wurde erstellt von hellsgod, 13.06.2012.

  1. hellsgod, 13.06.2012 #1
    hellsgod

    hellsgod Threadstarter 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 von einem Moderator bearbeitet: 13.06.2012
    Alex0901, Andrenalin1981, nobody573 und 8 andere haben sich bedankt.
  2. hellsgod, 16.06.2012 #2
    hellsgod

    hellsgod Threadstarter Gast

    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
     
  3. hellsgod, 20.06.2012 #3
    hellsgod

    hellsgod Threadstarter Gast

    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
     
    Milchbeck, craP_cillA und TAT1980 haben sich bedankt.
  4. TAT1980, 20.06.2012 #4
    TAT1980

    TAT1980 Fortgeschrittenes Mitglied

    Beiträge:
    431
    Erhaltene Danke:
    51
    Registriert seit:
    04.03.2012
    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???
     
  5. hellsgod, 20.06.2012 #5
    hellsgod

    hellsgod Threadstarter Gast

    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
     
  6. TAT1980, 20.06.2012 #6
    TAT1980

    TAT1980 Fortgeschrittenes Mitglied

    Beiträge:
    431
    Erhaltene Danke:
    51
    Registriert seit:
    04.03.2012
    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.
     
  7. Lord Boeffla, 20.06.2012 #7
    Lord Boeffla

    Lord Boeffla Threadstarter Gast

  8. hellsgod, 20.06.2012 #8
    hellsgod

    hellsgod Threadstarter Gast

    Milchbeck und TAT1980 haben sich bedankt.

Diese Seite empfehlen