[INFO] [v0.9 beta1] CPU Governor ZZMoove (03.06.2014)

[Matthias1968]

Erfahrungswerte mit Akkuverbrauch gibt es noch nicht denke ich.

Ich bin ja auch jemand der Energie sparen möchte. Deswegen meine Frage ob Battery plus oder moderate zu empfehlen sind. Ansonsten testen werde ich es auf jedenfall. War nur so als Anhaltspunkt gedacht.

Gruß Matthias

P.S. Flott laufen tun sie auf jedenfall beide

 

[S13gfried]

Hatte yank Battery mit 0.7er Zzmoove. Und jetzt Battery plus im 0.8er.
Habe das Gefühl, nach allerdings zu kurzer Zeit, dass Battery plus sparsamer ist.
Aber nur ein erstes Gefühl.

Mfg

 

[Matthias1968]

Auf jedenfall läuft er wesentlich runder als Battery bei mir.

Problem bei mir ist, das ich erst noch eine neue FW installiert habe und danach die Werte meistens nicht richtig stimmen. Deswegen einfach noch ein bischen ausprobieren.

Gruß Matthias

 

[ZaneZam]

Hallo Leute!

indem ich es leider versäumt habe mir hier die ersten drei post zu reservieren (so was blödes!) dumpe ich den neuesten changelog einfach mal hier rein und verlinke ihn anschliessend...

Also los gehts:

ZZMoove Governor 0.8
(cool down baby!)

Cangelog:

- Einstellbare Frequenz Scaling "Verlangsamung" eingeführt (im normalen und im Leagacy Scaling Modus) um unerwünschte Sprünge auf höhere Frequenzen zu verringern (wie hoch hängt von den jeweiligen Einstellungen ab) wenn der System Load nur für kurze Zeit den Up Threshold überschreitet oder konstant mittelmäßig oder höher ist und dadurch den Up Threshold öfter als "normal" überschreitet. Das reduzieren dieser übermässigen Sprünge reduziert auch die CPU Temperatur und könnte sogar etwas Energie sparen. Mit dieser Funktion lässt sich also das etwas seltsame Frequenzskalierverhalten beeinflussen welches zb. beim Ausführen von Spielen auftritt die den System Load in einem gewissen Bereich halten und dabei die Frequenz viel zu hoch ist für diesen Bereich. In der Tat sieht es aber nur so aus! Monitoring Tools sind in der Regel viel zu langsam um den aktuellen Load in Echtzeit zu erfassen, also sieht man die meiste zeit eigentlich nur die "Vergangenheit". Es ist eigentlich nicht wirklich seltsam sondern viel mehr so: eine Anwendung stresst das System und hält den Load in einem gewissen höheren Bereich, durch dieses hohe Load Level wird der Up Threshold öfter erreicht (auch wenn Monitoring Tools anzeigen der Load wäre unterhalb von up_threshold!). Der Governor skaliert nun sehr schnell hinauf (bekanntes zzmoove verhalten) und skaliert fast nie mehr herunter (auch wenn Monitoring Tools zeigen der Load wäre unterhalb von down_threshold). Also nun im Detail: Diese Scaling Verlangsamung "bremst" nun das hinauf skalieren mittels auslassen des selbigem für die Anzahl an eingestellten Zyklen und macht gleich danach zusätzlich ein Erzwungenes Down Skalieren während der nächsten gleichen Anzahl von Zyklen. Das alles sollte uns nun in einen "angemessenen" Frequenzbereich bringen wenn der System Load konstant in der Nähe von up_threshold verweilt.
- (D)ynamische (S)ampling (R)ate - Danke an @Hellsgod für die selbe Idee zur selben Zeit und für den Hinweis auf ein Implementierungsbeispiel! Ich hab es jedoch am Ende "auf meine Art" gemacht. "DSR" schaltet in Abhängigkeit des eingestellten Load Thresholds zwischen einer Ruhezeit und einer "normalen" Sampling Rate um.
- Schreibgeschützte Tuneable 'sampling_rate_current' für "DSR" hinzugefügt um die aktuelle Sampling Rate anzuzeigen und intern zu verwenden anstatt die vorhandene 'sampling_rate' Tuneable in "DSR" zu verwenden. Das hält die Sache kompatibler und vermeidet Probleme wenn Governor Tuneabels mit Tools gesetzt werden die aktuell angezeigte Werte speichern.
- Verwendung von 'sampling_rate' in 'sampling_rate_current' intern im Governor geändert und den Wert bei Suspend in 'sampling_rate_idle' statt die aktuelle aktive Sampling Rate zu nutzen. Dies verhindert ein versehendliches setzen der 'normalen' sampling rate im Sampling Rate Idle
Modus welche normalerweise einen viel niedrigeren Wert hat!
- eingebaute Profile (Governor Einstellungen) in einer seperaten Header Datei eingeführt. (credits an Yank555 für die Idee und der prototypen Datei) man kann nun zwischen verschiedenen implementierten Profilen mittels setzen einer nummer in die Tuneable 'profile_number' umschalten. Alle betroffenen Tuneablewerte des Profils werden daraufhin on-the-fly gesetzt. Wenn ein Profil aktiv ist und einer seiner Werte geändert wird wird zur information die Tuneable Profilnummer in 'profile_number' auf 0 und die Tunebale 'profile' auf 'custom' geändert. Mit diesem Profile Support können Entwickler nun ihre gut geprüften/bewährten Einstellungen direkt im Governor speichern und können auf die Verwendung von Init-Scripts oder Tuning Apps verzichen. HINWEIS: Dies ist nur ein optionales Feature, man kann nach wie vor alle Tunables setzen wie gewohnt man sollte dann nur darauf achten dass die Tunebale 'profile_number' auf 0 gesetzt ist damit sie nicht durch Schalten eines internen Profils andere Tuneables überschreibt! Nähere informatinen zu den Profilen und wie man eigene hinzufügt gibt es in der mitgelieferten 'cpufreq_zzmoove_profiles.h' Datei!
- 'profile_version' Tuneable hinzugefügt um die Version der Profil Header Datei anzuzeigen.
- Einschalten aller offline geschalteten Kerne bei Governor Stop hinzugefügt um zu verhindern dass Kerne im offline Modus "steckenbleiben" wenn man auf einen nicht-hotplug-fähigen Governor umschaltet. Bei dieser Gelegenheit reduntanten Code reduziert indem eine Funktion zu diesem zweck eingesetzt wird und der bessere 'sheduled_work_on-way' an allen relevanten Stellen verwendet wird.
- Einige Code Teile welche nur Relevanz bei Verwednung des Legacy Modus haben in die 'Lagacy Modus' macros verschoben und zur Laufzeit exkludiert wenn der Legacy Modus nicht aktiv ist.
- Freq Limit Handhabung in den entsprechenden Tuneables und in der 'dbs_check_cpu' Funktion verbessert.
- Einschränkung der Hotplug Down Threshold minimal werte von '11' auf '1' gesenkt da diese Einschränkung nur bei Scaling Down benötigt wird
- Fehlender 'fast scaling' Modus - schnelles down skalieren/normales up skalieren zur fast scaling Funktion hinzugefügt (Werte Bereich 9-12 und nur im nicht-Legacy-Modus - Dank an OldBoy.Gr für den Hinweis das dieser Modus fehlte!)
- Auto Fast Scaling Modus zur Fast Scaling Funktion hinzugefügt -> die Glücksnummer 13 aktiviert diesen Modus in der 'fast_scaling' Tuneable
Hinweis: ein wirklich witziger Modus, probiert es einfach mal aus aber bitte beachten dies in Kombination mit einem Frequenz Limit zu verwenden
(bei screen on oder off) macht nicht viel Sinn denn damit wäre nicht genug 'Platz' zum springen vorhanden.
- Weg von der Vorsichtsmassnahme 'mutex_try_lock' zum normalen 'mutex_lock' im Governor "LIMIT" case -> das sollte nun wieder sicher sein, keine Deadlocks mehr zu erwarten da sich die Hotplug Logik seit Version 0.6 signifikant geändert hat!
- Die Vorsichtsmassnahme auslassen von Hotplugging und 'dbs_check_cpu' an verschiedenen Punkten im Code und Mutex Locks bei Governor stop/early suspend/late resume entfernt
- Hotplug Frequenz Thresholds zu Legacy Hotplugging hinzugefügt (selbe Verwendung wie beim normalen hotplugging)
- Hotplug Down und Up Block Zyklen getrennt um mehr Flexibilität zu haben. Dies ersetzt die Tunebale 'hotplug_block_cycles' mit 'hotplug_block_up_cycles' und fügt eine neue Tunable 'hotplug_block_down_cycles' hinzu. Funktionalität ist die selbe wie zuvor nur kann man nun zwischen up und down Wert differenzieren.
- 'Early Demand Sleep' kombiniert mit automatischem Fast Scaling Schaltung (fixer up Wert von 2) und wenn nicht schon gesetzt automatischer (abhänig vom Load) Schaltung des Sampling Rate Multiplier auf einen fixen minimal Wert von 2. Dies soll mögliche Audio oder generelle Gerät Verbindungsprobleme mit Resource-hungrigeren Apps wie zb. einige Music Player, Skype, Navigations Apps usw. und/oder in Kombination mit Bluetooth Equipment bei Screen Off lösen. Hinweis: Dies überschreibt eine mögliche Fast Scaling Sleep Einstellung! Also entweder diese Funktion oder Fast Scaling Sleep verwenden!
- Einige fehlende Governor Tunabable Default Wertdefinitionen hinzugefügt
- Tuneable Anwendungsreihenfolge-Ausnahme und Gegenwertprüfung in Hotplugg Threshold und Hotplug Frequenz Threshold Tuneables entfernt um das Problem des zeitweise nicht gesetzten Wertes zu behebn. Hinweis: bitte daruf achten dass alle "down" Werte niedriger sein müssen als alle up Werte und umgekehrt!
- 200 mhz up Hotpug Beschränkung entfernt, das hotplugging beginnt also nun schon bei 200mhz
- Unötige macros in Scaling Logik entfernt
- Maximales Fast Scaling und Freq Boost zu Late Resume hinzugefügt um Wake up Lags entgegenzuwirken
- Einige Verbessungen von ktoonservativeq governor version für das SGS4 übernommen (credits to ktoonsez)
Änderungen von hier: https://github.com/ktoonsez/KT-SGS4/...onservativeq.c
Verwendung von speziellen hoch Priorität-Workqueues
Verwende neue Priorität-Workqueues auch für Hotplugging
Hotplugging generell verbessert durch reduzieren der Aufrufe zu den Hotplugging Funktionen wenn diese gerade aktiv sind, durch reduzieren zu externen Funktionen in Up Hotplugging und durch Optimieren der Down Hotplugging Schleife
- Hotplug Boost Schalter zu Early Demand und Up Hotplugging Funktion hinzugefügt
- 'hotplug_idle_freq' Tuneable hinzugefügt um einstellen zu können ab welcher Frequenz die Idle Sampling Rate aktiv sein soll
- Alle Programmteile für die Frequenz-Tabellen-Anordnungserkennung und Frequenz Limit Optimierung in eine Inline Funktion transferiert und diese im START, LIMIT und Early Suspend/Late Resume verwendet anstatt redundante Programmteile zu verwenden.
- Tabellen-Anordnungserkennung und Limit Frequenzoptimierung wird nun bei START und LIMIT ausgeführt um ein mögliches nicht setzen der maximal Frequenz und/oder das nicht Einstellen der Limitoptimierung beim Unterschreiten des Softlimits mit dem Hardlimit zu verhindern (eingestellte maximal frequenz wurde manchmal nicht gesetzt)
- Kleinere Optimierungen in Hotplug, Hotplug Block und allen Frequenz-Such-Logikteilen durchgeführt
- Debugging Sysfs Interface hinzugefügt (kann mittels Macro '#define ZZMOOVE_DEBUG' aktiviert/daktiviert werden) - credits to Yank555!
- Einige fehlende Annotationen zur Vorbereitung (hauptsächlich um Kompilierungsehler zu beheben) für Kernel Sourcen 3.4+ hinzugefügt
- Hotplugging Probleme behoben wenn das Hard Frequenzlimit unter einen oder mehrere Hotplug Frequenz Thresholds gesetzt wird. HINWEIS:
die Hotplugging Frequenz Thresholds werden nun deaktiviert und es werden nur mehr die normalen Hotplug Load Thresholds verwendet wenn das Frequenzlimit unter einen oder mehrere Hotplug Frequenz Thresholds liegt.
- Up Sclaing Stop bei 100% Load behoben wenn die Up Threhold Tunebale auf dem maximal Wert von 100 gesetzt ist
- Smooth Up Stop bei 100% Load behoen wenn die Smooth Up Tunebale auf den maximal Wert von 100 gesetzt ist
- Viele Programm Stil- und Dokumentations-Fehler behoben und massives Neuanordnen im Programmcode durchgeführt

Für diese Funktionen wurden folgende neue Tuneables eingeführt:

early_demand_sleep -> Gleiche Funktion wie Early Demand bei Screen On aber mit Fast Scaling und Sampling Rate kombiniert und nur aktiv bei Screen Off (mögliche Werte 0 zum abschalten oder 1 zum einschalten, Standard ist 1)

grad_up_threshold_sleep -> Doppelfunktion: Early Demand Sleep Load Gradient Threshold und zur selben Zeit Load Threshold um intern (Tuneables bleiben auf den eingestellten Werten!) sampling_rate_sleep_multiplier auf 2 und fast_scaling auf 2 zu schalten (mögliche Werte von 1 bis 100, Standard ist 35)

hotplug_block_up_cycles -> (ersetzt hotplug_block_cycles) verlangsamt das up hotplugging mittels Warten der eingestellten Anzahl von Zyklen bevor gepluggt wird. mögliche Werte 0 ausschalten, jeder Wert über 0 (Standard ist 0)

hotplug_block_down_cycles -> (ersetzt hotplug_block_cycles) verlangsamt das down hotplugging mittels Warten der eingestellten Anzahl von Zyklen bevor gepluggt wird. mögliche Werte 0 ausschalten, jeder Wert über 0 (Standard ist 0)

hotplug_idle_freq -> Frequenz ab welcher die Idle Sampling Rate aktiv sein soll (mögliche Werte 0 ausschalten und jede mögliche Scaling Frequenz, Standard ist 0)

sampling_rate_current -> Nur lesen und zeigt die aktuell aktive Sampling Rate

sampling_rate_idle -> Sampling Rate welche zu "Ruhezeiten" verwendet werden soll (mögliche Werte sind jede Sampling Rate > 'min_sampling_rate', 0 zum Deaktivieren der ganzen Funktion, Standard ist 0)

sampling_rate_idle_delay -> Verzögerung in Zyklen für das Schalten zwischen "Ruhezeit" zur normalen Sampling Rate and umgekehrt (mögliche Werte ist jeder Wert über 0 und 0 zum abschalten der Verzögerung, Standard ist 0)

sampling_rate_idle_threshold -> Threshold unterhalb welcher die Idle Sampling Rate aktiv sein sollte (mögliche Werte 1 bis 100, 0 zum abschalten der Funktion, Standard ist 0)

scaling_block_cycles -> Anzahl der Gradienten welche gezählt werden sollen (wenn Block Threshold gesetzt ist) und zu gleichen Zeit Up Scaling beblockt werden sollte und danach ein forcierter Down Scaling durchgeführt werden soll (mögliche Werte sind jeder Wert über 0, 0 zum Abschalten dieser Funktion, Standard ist 0)

scaling_bock_freg -> Frequenz oberhalb welcher das Blockieren starten soll (mögliche Werte sind alle möglichen Scaling Frequenzen, 0 zum permanenten aktivieren des Blockierens bei jeder Frequenz, Standard ist 0)

scaling_block_threshold -> Gradient (minimal Wert) des Loads in beide Richtungen (up/down) um die Zyklen hinauf zu zählen (mögliche Werte sind 1 bis 100, 0 zum abschalten des Gradienten-zählens)

scaling_block_force_down -> Multiplikator für die maximale Anzahl der Forced Down Scaling Zyklen (Force Down Zyklen = block_cycles * force_down) somit die Zeitspanne wo Forced Down Scaling durchgeführt wird (mögliche Werte sind 2 bis jeder Wert, 0 zum abschalten des Forced Down Scaling und nur Verwendung von Scaling Up Blocks)

profile -> Nur Lesen und zeigt das aktuell geladene Profil an ('none' = kein Profil, 'custom' = ein Profil Wert wurde manuell geändert)

profile_number -> Schaltet implementierte Profile um (mögliche Werte hängt von der anzahl of Profile in der cpufreq_zzmoove_profiles.h datei ab,
nähere informationen zu den Profilen befinden sich in dieser Datei) 0 kein Profil gesetzt = "Tuneable Modus", Standard ist 0)

version_profiles -> Nur lesen und zeigt die Version der Profile Header Datei an

wenn das Macro 'ZZMOOVE_DEBUG' definiert wurde:
debug -> Nur lesen und zeigt verschiedenste nützliche Debugging
Informationen an

Post in Arbeit....

 

[S13gfried]

Cool, danke.
Sogar halbwegs verständlich

Annektiere doch einfach die 2 Posts nach dir. Eine Volksabstimmung wird dir unter deinen Fans sicher 95,5% Mehrheit einbringen und die internationale Netzgemeinschaft wird nur tatenlos zusehen.
(Parallelen zur aktuellen politischen Lage sind Zufall)

 

[Darkman]

Hallo Leute!

indem ich es leider versäumt habe mir hier die ersten drei post zu reservieren (so was blödes!) dumpe ich den neuesten changelog einfach mal hier rein und verlinke ihn anschliessend...

Sag doch was

Ich habe dir mal zwei Beiträge eingepflegt und du hast nun die ersten drei Beiträge!!

Viel Spass und danke für deine Arbeit hier!!

P.S. es könnte sein das du die neuen Beiträge noch nicht bearbeiten kannst. Darum kümmere ich mich noch... näheres kommt dann per PN!

 

[ZaneZam]

@Darkman

Hey das is ja nett Dankeschön!

 

[peterle111]

Hey zanezam,

Nochmal danke für deinen hervorragenden 0.8 und deine ausführlichen Ausführungen.

Nur kurze Verständnisfrage.
Das early demand sleep mit automatischen fast scaling, wann ist das aktiviert?
Bei early demand sleep 1 und fast scaling sleep 13?

Grüße peterle

 

[ZaneZam]

hallo peterle,

"Bei early demand sleep 1" und fast scaling wird dann immer "überschrieben"
also falls du fast scaling sleep 4 eingestellt hast zum beispiel dann is es dann zu gegebenen zeitpunkt (wenn early demand triggert) immer 2. aja und "13" also auto fast scaling ist bei screen off gar nicht aktiv das wird immer ausgeschalten bei screen off. da hab ich was vergessen in der doku muss ich ausbessern, danke fürs indirekte hinweisen

 

[S13gfried]

Bei der Gelegenheit auch den threadtitel der Form halber.

Hab mit Battery plus auf dem 0.8er seit zwei Tagen weniger lags und mehr Akku am Abend. Ein paar Tage brauch ich noch um subjektiv zu evakuieren
Vorher hatte ich yank Battery.

Mfg

 

[Monacor3]

Hi ZaneZame,

welchen Sheduler empfiehlst du für deinen Top Governor?

 

[ZaneZam]

hi Monacor3,

also vor einiger zeit war es mal definitiv "row" aber durch die "probleme" die man damit haben kann und über die ich mir keine gedanken mehr machen wollte hab ich dann mal ne gute zeit lang auf zen gesetzt. war ok! inzwischen bin ich jetzt auch mal zu cfq gewechselt und der passt mir im moment mal fast noch besser! die unterschiede sind aber wirklich keine großen und es hängt wie immer von der "Einsatzumgebung/vom Benutzerverhalten" ab. Kann dir jetzt also keinen im Speziellen empfehlen. Das einzige was ich abgeben kann ist ne warnung bei row der hat naturgemäß manchmal eben probleme beim schreiben von "großen" datenmengen (videoaufnahmen usw.).

ich würde sagen einfach ne zeit lang probieren und dann eine auswahl für dein System treffen.

 

[Lord Boeffla]

Ich bin seit ein paar Wochen auch wieder auf CFQ zurück. Sehr gutes Gesamtpackage bezüglich Smoothness und Verbrauch (aus meiner Sicht).

Viele Grüße
Andi

 

[Monacor3]

Hab mich hier mal bisschen durchgelesen und bin auch auf cfq zurück, obwohl noop genauso gut ist bei mir

http://forums.gentoo.org/viewtopic-t-619496.html

 

[ZaneZam]

Hallo Leute!

Schnelle information für all jene die an einer neuen Version des ZZMoovers interressiert sind:

Ich habe gestern die aktuelle alpha2 auf beta1 angehoben und veröffentlicht
Es hat sich zwar nichts großartiges geändert (neben der reduzierung von meist ungenutzten code -> details im zweiten Post) trotzdem gibt es nun keinen wirklichlichen grund eine stabile version zurückzuhalten denn alpha2 wurde ohne probleme ausgiebig einige wochen getestet!

Also dann viel Spass damit!
ZaneZam

 

[Lord Boeffla]

Bau ich in die nächsten Betas meiner Kernel mit ein.

Danke
Andi

 

[Monacor3]

Hallo,

wirst du deinen Top governor (Profile)auch unter dem samsung S5 zum laufen bringen?

bin ja umgestiegen und vermisse den total


Auf meinem alten S3 und dem Note 10.1 läuft er noch weiter

 

[ZaneZam]

Hallo Monacor,

Tja das ist die frage, geplant ware es mal das ding weiter zu "verbreiten" aber wie du schon richtig schreibst muss er erst mal laufen auf höheren kernel versionen als 3.0.x. wird ganz nett viel arbeit erste versuche gab es schon aber leider nicht zufriedenstellend.wir werden sehen

 

[SaschaKH]

Ich mag da jetzt keine Ahnung haben aber ich dachte doch das ein Governor nicht wirklich hardwarespezifisch ist sondern es darauf ankommt das er in den Kernel eingebaut wird. Also müsste man da doch jemanden fragen der einen Kernel für das S5 macht. Wenn Andi (Lord Boeffla) sich den für das S5 entscheidet, und die Aussichten dafür sind wohl nicht schlecht, wird es wohl kommen.

Es gibt allerdings bisher nicht zu viel Auswahl an Kernels für das S5 und keiner beherrscht ZZmoove.

Ups ZaneZam war schneller, stimmt die Version des Kernels ist auch wichtig und ich glaub alle Kernel für das S3 sind noch bei 3.0... (aber davon hab ich dann jetzt wirklich keine Ahnung mehr, kann also auch Blödsinn sein).

 

[ZaneZam]

nein sascha, alles kein blödsinn *g* aber ich glaube nicht dass andi sich das antun wird den zzmoover auf das s5 zu portieren das bliebe dann schon an mir hängen wenn ich ihm gerätetechnisch folgen sollte (sehr wahrscheinlich! *g*) aber abgesehen davon wie gesagt ich habs ohnehin vor es is nur nicht so einfach in höheren kernel versionen is einiges anders also muss man auch einiges anders umsetzen. JP und ich haben es geschafft das ding auf 3.4 (JP) und 3.7 (ich) kernen zum kompilieren zu bringen aber damit ist es leider nicht getan denn hotplugging läuft mal gar nicht mehr muss also raus und scaling geht zwar aber da gibt es noch probleme damit dass man in neueren kernen governors per core laden kann also mutliple instanzen hat oder sogar verschiedene governors gleichzeitig tja und das sysfs macht auch noch schwierigkeiten, also gleich mehrere baustellen zum glück ist JP immer noch motiviert das ding auf seinen neueren geräten haben zu wollen somit werde ich mich da auch mal mit ihm ab und an kurzschliessen so wie früher -> 4 augen sehen mehr, vor allem seine 2

und weil ich mir hier zur abwechslung mal wieder so schön einen abtexte, kann ich auch gleich eine kurze vorschau abgeben:

es kommt sehr bald die letzte beta vor der finalen 0.9er version also genauer die beta4 mit folgendem:

• Eigenes einstellbares Thermal Throttling
• "freq_step" entfernt da intern nicht in Verwendung seit v0.1 (ja erstaunlich *gg*)
• Zum Load proportionale Frequenzberechnung und Verwendung (aus/einschaltbar)
• Automatsiche Einstellung (auch proportional) aller Frequenz Thresholds wenn die maximal Frequenz geändert wird

wie gesagt das ist die letzte beta vor 0.9 final als nächstes für die Version 1.0 steht dann eben der "outbreak" auf 3.4+ kernel sourcen am programm, aber das wird ein bissi dauern.