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

[ZaneZam]

Hallo Leute,

wie schon auf XDA hier nun auch hier das Kompentium für den ZZMoove Governor in deutsch (mehr oder weniger *g*)
Das hier sind die zuvor geposteten Beschreibungen der einzelnen Versionen inkusive der neuen Version 0.5 ich werde das alles noch ein wenig überabeiten wenn ich zeit dafür finde.

ZZMoove Governor v0.1

„ZZMoove“ Governor was ist das und wie er funktioniert:

Da der "smoove" Governor von mialwe schon damals auf dem SGS1 zu meinen Favoriten in Bezug auf Batteriefreundlichkeit/Effizienz zählte dachte ich mir ich probier den mal auch auf mein aktuelles Gerät zu übertragen. Und das ist nun das erfolgreiche Ergebnis des Experiments.

Im Grunde genommen ist dies nun die portierte SGS1 Version des schon
erwähnten "smoove" Governors des bekannten GB Midnight Kernels von Michael Weingärtner mit einer CPU Hotplug Modifikation vom ktoonservative Governor von ktoonesz Kernel KT747. Da ich bei meinen Tests beobachtet habe das die originale Hotplug Implementation von ktoonesz die meiste Zeit bei Idle nur eine CPU offline schaltet dachte ich mir das ist mir zu wenig und modifizierte diese Implementierung so das nun bei Idle 3 CPU's offline geschaltet werden (CPU0 bleibt immer an). Das bedeutet nun das je nach Einstellungen dieser Governor öfter nur mehr eine CPU verwendet was wiederum weniger Strom verbraucht. Je nach CPU Auslastung und Einstellungen stehen dann natürlich wieder sofort alle 4 Kerne zur Verfügung wenn es benötigt wird.

Kurzum:
Was ihr nun von dem Ding erwarten könnt ist ein batteriefreundlicher "conservative" Governor mit CPU Hotplug Funktionalität welcher Frequenztabellen für das upscaling verwendet (smooth scaling) Er ist also mehr ein Stromsparer als ein Sprinter.

Was ich noch erwähnen wollte:
Ich habe diesen Governor mit vielen verschiedenen Einstellungen (inkl. uv bis max light) und allen Schedulern viele Wochen lang auf meinem Gerät im selbst gebauten Boeffla Kernel getestet und hatte keine Probleme. Somit würde ich ihn als stable bezeichnen. Dieser Governor wurde jedoch noch auf keinem anderen Gerät als meinem getestet (stimmt so jetzt nicht mehr ganz *g*) und indem er nun Teil vom Boeffla Kernel wird (danke Andi!!) steigt natürlich die Möglicheit das doch Probleme auftauchen könnten. Nicht das ich Fehler erwarte aber es gibt so viele Geräte die sich unterschiedlich verhalten und zusätzlich noch viele verschiedene Konfigurationen, man weiß ja nie! Also wie immer Verwendung auf eigene Gefahr (wobei die hält sich in Grenzen *g*) und falls ihr Probleme habt bitte melden. Falls ihr keine Probleme habt dann würde es mich freuen wenn ihr eine Rückmeldung geben könnt wie der zzmoove Governor denn bei euch so läuft. Da ich durch die ganze Flasherei/Testerei leider keinen wirklichen Langzeitest gemacht habe würde mich auch diesbezüglich eine Rückmeldung sehr freuen!

Hier noch die Einstellungsmöglichkeiten des Governors:

Spoiler

Sampling Rate (default=2) /sys/devices/system/cpu/cpufreq/zzmoove/sampling_rate

Sampling Down Factor (default=4) /sys/devices/system/cpu/cpufreq/zzmoove/sampling_down_factor

Up Threshold (default=70) /sys/devices/system/cpu/cpufreq/zzmoove/up_threshold

Up Threshold Hotplug (default=68) /sys/devices/system/cpu/cpufreq/zzmoove/up_threshold_hotplug

Down Threshold (default=52) /sys/devices/system/cpu/cpufreq/zzmoove/down_threshold

Down Threshold Hotplug (default=55) /sys/devices/system/cpu/cpufreq/zzmoove/down_threshold_hotplug

Ignore Nice Load (default=0) /sys/devices/system/cpu/cpufreq/zzmoove/ignore_nice_load

Freqency Step (default=5) /sys/devices/system/cpu/cpufreq/zzmoove/freq_step

Smooth Up (default=75) /sys/devices/system/cpu/cpufreq/zzmoove/smooth_up

Links (auf XDA):
Midnight Kernel
KT747 Kernel
Allgemeine Infos zu Governor, I/O Scheduler usw.

Credits gehen an:
mialwe für seinen „smoove“ Governor
ktoonesz für die original Hotplug Implementierung

ZZMoove Governor v0.3

Also, es gibt nun eine Menge neuer Tuneables mit denen man den Governor per sysfs genauer einstellen kann.
Folgendes ist hinzugekommen:

Spoiler

So genannte "sleep" Werte welche bei Screen Off aktiviert werden und zuvor nur fix im Sourcecode verankert waren sind nun justierbar:

Das Smooth Scaling für sleep (Screen off):
tuneable -> /sys/devices/system/cpu/cpufreq/zzmoove/smooth_up_sleep
mögliche Werte von 1 bis 100, default: 100

Der up/down Threshold für sleep (Screen off):
tuneable -> /sys/devices/system/cpu/cpufreq/zzmoove/up_threshold_sleep
mögliche Werte von über "down_threshold_sleep" bis 100, default: 90

tuneable -> /sys/devices/system/cpu/cpufreq/zzmoove/down_threshold_sleep
mögliche Werte von 11 bis unter "up_threshold_sleep", default: 44

Die Sampling Rate für sleep (Screen off):
tuneable -> /sys/devices/system/cpu/cpufreq/zzmoove/sampling_rate_sleep_multiplier
mögliche Werte 1 oder 2, default: 2

Die Anzahl der Kerne die bei "Screen Off" laufen sollen:
tuneable -> /sys/devices/system/cpu/cpufreq/zzmoove/hotplug_sleep
mögliche Werte 0 = Kerne nicht ausschalten (entspricht dann dem Standardverhalten), 1, 2 oder 3 wären die Anzahl der Kerne die bei Screen Off noch laufen sollen. btw. 4 gibt es nicht da man ja 0 verwenden kann

Des Weiteren kann man nun den Hotplug Threshold der
einzelnen Kerne separat einstellen und Kerne ganz abschalten.

Zu diesem Zweck wurden folgende neue Tuneables eingeführt und ersetzen
die alten hotplug up/down threshold tuneables:
tuneable -> /sys/devices/system/cpu/cpufreq/zzmoove/up_threshold_hotplug1
hotplug up threshold für Kern 1 - 0 = Kern 1 ausschalten, möglicher Bereich von "down_threshold" bis 100, default: 68

tuneable -> /sys/devices/system/cpu/cpufreq/zzmoove/up_threshold_hotplug2
hotplug up threshold für Kern 2 - 0 = Kern 2 ausschalten, möglicher Bereich von "down_threshold" bis 100, default: 68

tuneable -> /sys/devices/system/cpu/cpufreq/zzmoove/up_threshold_hotplug3
hotplug up threshold für Kern 3 - 0 = Kern 3 ausschalten, möglicher Bereich von "down_threshold" bis 100, default: 68

tuneable -> /sys/devices/system/cpu/cpufreq/zzmoove/down_threshold_hotplug1
hotplug down threshold für Kern 1 - möglicher Bereich von 11 bis unter "up_threshold", default: 55

tuneable -> /sys/devices/system/cpu/cpufreq/zzmoove/down_threshold_hotplug2
hotplug down threshold für Kern 2 - möglicher Bereich von 11 bis unter "up_threshold", default: 55

tuneable -> /sys/devices/system/cpu/cpufreq/zzmoove/down_threshold_hotplug3
hotplug down threshold für Kern 3 - möglicher Bereich von 11 bis unter "up_threshold", default: 55

Profile:
Ich habe nun in den Profilen (bat/opt/perf) für diese neue Version die Threshold Werte so verändert dass bei Screen Off etwas später hinauf skaliert und früher herunter skaliert wird. Des Weiteren wurden die einzelnen Kern-Hotplug-Thresholds so eingestellt das sich ein stufiges Einschalten der Kerne ergeben sollte. Soll heissen es bleiben Kerne dann öfter so "lange" abgeschaltet/eingeschaltet bis ihr Threshold Wert erreicht wird. Im Falle vom Battery Profil werden zum Beispiel bei 50% Last der Zweite Kern, bei 70% der Dritte und bei 98% der Vierte dazu geschalten und bei den "down" Werten entsprechend wieder abgeschalten anstatt wie es vorher war bei jeweils nur einem up/down Wert alle kerne zu schalten. Das sollte also den Ball flacher halten in Bezug auf das Hotplugging. Theoretisch *g* das Ganze geht so schnell das es mit Monitoring tools etwas schwer zu Beobachten ist sich aber hoffentlich positiv auf den Verbrauch auswirkt!

Dazu noch ein Hinweis:
es ist nun bei allen Profilen (bat/opt/perf) bei Screen Off nur mehr ein Kern eingeschaltet! kommt man aus dem Screen Off wieder herraus werden sofort wieder alle 4 Kerne (oder was zuvor eingestellt war) aufgeweckt. Das sollte zur Folge haben das bei Screen Off nun weniger Akku verbraucht wird.

Mein Dank an:
Andi für das erneute Aufnehmen dieser Version in seinen Kernel und für die gute Zusammenarbeit!
Auch nochmals an HM.Carbide für seine tolle App!
gsw5700 für die initial Idee "Hotplug Threshold pro Kern".
brijmathew indirekt für die initial Idee "Nur ein Kern bei Screen Off".

ZZMoove Governor v0.4

mit folgenden Änderungen:

Spoiler

Freqenzlimit:
Es ist nun per sysfs möglich bei Screen Off (oder auch bei Benutzung wenn gewünscht) die Frequenz zu limitieren! Es handelt sich hierbei aber um ein von mir so genanntes "Soft-Limit" da es aus diversen Gründen (touchboost/wakeup Ereignissen) dazu kommen kann dass die Frequenz trotzdem im Sekundenbereich (meistens auf 1000mhz und/oder 800mhz) über dieses Limit steigen kann da hier offenbar der Governor keine Kontrolle darüber hat. Diese Ausreisser sollten aber akku-verbrauchstechnisch nicht groß ins Gewicht fallen vor allem nicht bei Screen Off.

Folgende Tuneables wurden zu diesem Zweck dafür eingebaut:

Das Frequenzlimit bei sleep (Screen Off):
tuneable -> /sys/devices/system/cpu/cpufreq/zzmoove/freq_limit_sleep
mögliche Werte 0 = deaktiviert, von 200000 in 100000er Schritten bis 1600000, default: 0

Das Frequenzlimit bei Screen On:
tuneable -> /sys/devices/system/cpu/cpufreq/zzmoove/freq_limit
mögliche Werte 0 = deaktiviert, von 200000 in 100000er Schritten bis 1600000, default: 0

Fast Scaling:
Ich dachte mir das Schalten von Freqenzen könnte etwas schneller vonstattengehen und habe die Scaling-Tabellen so erweitert das bei Aktivierung dieser Funktion größere Frequenzsprünge gemacht werden. Zu erwarten ist hier eine Performancesteigerung in allen Settings welche aber natürlich auch ein wenig mehr Energie kostet.

Folgende Tuneables wurden zu diesem Zweck dafür eingebaut:

Fast Scaling bei Screen On:
tuneable -> /sys/devices/system/cpu/cpufreq/zzmoove/fast_scaling
mögliche Werte 0 = deaktiviert oder 1 = aktiviert

Fast Scaling bei sleep (Screen Off):
tuneable -> /sys/devices/system/cpu/cpufreq/zzmoove/fast_scaling_sleep
mögliche Werte 0 = deaktiviert oder 1 = aktiviert

Freq Step Sleep:
Wurde analog zu Freq Step als Ergänzung eingebaut da die Möglichkeit gefehlt hat dass nur bei Screen Off zu ändern:
tuneable -> /sys/devices/system/cpu/cpufreq/zzmoove/freq_step_sleep
mögliche Werte in % wie "freq_step" von 0 = Frequenz anhalten bis 100 = von 0 auf 100 springen und retour (bei Wert 100 entspricht das in etwa dem Verhalten des ondemand governor)

Settings und Scriptpack(s):
Ich habe alle Settings (Bat/Opt/Perf) mit folgenden neuen Einstellungen ergänzt:
Freqenzlimit bei Screen Off : 500 mhz
Fast Scaling : Off
Up Threshold : 100%
Freq Step bei Screen Off: 1%

ZZMoove Governor v0.5 aka "Das Biest"

Fürs Erste: diese Version ist in nicht unwesentlicher Zusammenarbeit eines euch bekannten Mitglieds unserer Gemeinde hier entstanden nämlich Yank555 (Vielen Dank für deine Ideen und die fruchtbare Zusammenarbeit! )

Des weiteren habe ich mir wieder mal einiges an toller Arbeit
bei anderen Devs "ausgeliehen". Somit möchte ich im Vorfeld schon folgenden Leuten danken und Credits geben:

Stratosk für die Funktionen : early demand, sampling down momentum, für einige Fehlerbehbungen im original conservative governor
(wir alle die wir ja linux auf unseren smartphones verwenden werden in Zukunft die großartige arbeit diese mannes verwenden! Er hat durch sein Semaphore Kernel Projekt für Smartphones mit seiner Arbeit nun direkt einen weg in den Upstream kernel gefunden, find ich superklasse grad so nebenbei erwähnt!

Yank555: für die Komplettierng/Erweiterung (lässt nun keine wünsche mehr offen! *g*) der Dynamic Freq Scaling Funktion von AndreiLux und für die gelungen Optimierungen im Scaling Bereich!

AndreiLux: eben für diese Grundidee/Erstumsetzung "Dynamic frequency scaling"!

DerTeufel1980: für die erste Implementierung der "Early Demand" Funktion in den zzmoover 0.3 und für ein paar Fehlerbehebungen bezüglich Frequenz Skalierung.

Ktoonsez: für ein paar Codeteile aus seinem Ktoonservative Governor welche den zzmoover nun auch verbessern sollten!

so nun gleich ohne weiterere umschweife zu den Funktionen bzw. zum

Changelog:

Spoiler

- fast scaling komplett überarbeitet. Es gibt nun 4 Stufen und 2 Modi (fast up mit normal down scaling/fast up/down scaling)
- Support für dynamisches LCD Frequenz Schalten in Abhänigkeit der CPU Frequenz und/oder hotplugging hinzugefügt (vielen dank an JP für die Erweiterung/Ergänzung dieser Funktion!)
ursprünglich gemacht von by AndreiLux mehr infos (englisch): xda-developers - View Single Post - [Kernel][26/04] Perseus
- nicht funktiontüchtige Sampling Down-"down skip" Funktionalität des conservative governors reaktiviert
ursprünglich behoben von stratosk - upstream kernel 3.10rc1: https://git.kernel.org/cgit/linux/k...id=refs/tags/v3.10-rc1&qt=author&q=Stratos+Ka
- down threshold Überprüfung verbessert.
verbesseung von Stratosk - upstream kernel 3.10rc1: https://git.kernel.org/cgit/linux/k...id=refs/tags/v3.10-rc1&qt=author&q=Stratos+Ka
"early demand" Funktion von ondemand governor portiert/implementiert
ursprünglich gemacht von Stratosk - mehr info (englisch): Semaphore - Ondemand: early demand
"sampling down momentum" von ondemand governor portiert/implementiert
ursprünglich gemacht von startosk - mehr infos (englisch): Semaphore - Sampling down momentum
- einige originale conservative codebereiche bezüglich frequenz scaling verbessert.
verbesserung von DerTeufel1980: https://github.com/DerTeufel/androi...mmit/6bab622344c548be853db19adf28c3917896f0a0
- möglichkeit für die benutzung von sampling down momentum und "down skip" methode eingebaut.
- maximale sampling rate entsprechend der sampling down momentum implementation auf 100000 und den maximalen sampling rate multiplier auf 4 angehoben.
- frequenz suchlimit in "frequenztabellen" eingebaut für ein effizienteres suchen nach frequenzen und für verbesseung des "soft" und "hard" limit handlings
- cpu idle time handling hinzugefügt entspechend der verwendung im lulzactive governor
erneut arbeit von ktoonsez: https://github.com/ktoonsez/KT747-JB/commit/a5931bee6ea9e69f386a340229745da6f2443b78
beschreibung in lulzactive governor (englisch): https://github.com/ktoonsez/KT747-J...f2443b78/drivers/cpufreq/cpufreq_lulzactive.c
- kleinen fehler in den frequenzstufen behoben und overclock frequenzen bis 1800 mhz in "frequenztabellen" hinzugefügt.
- mögliche deadlocks bei start/stop/neustart und limit änderung des governors behoben. (MIT VORBEHALT! - LEIDER NOCH IMMER NICHT 100% GEFIXT)
- fehler in hotplugging logik behoben bei dem kerne hängen blieben wenn nur kern 0+3 und 0+2 online waren (oft nach umschalten auf zzmoove passiert)
hotplugging durch entfernen von locks und aussetzen von schaltvorgängen wenn es nicht benötigt wird verbessert.
- möglichkeit das hotplugging auszuschalten hinzugefügt (eigentlich ein überbleibsel aus debugging zeiten, dachte mir vlt. findet das jemand nützlich)
- versuch den gelegentlich auftretenden lags mit einschalten aller offline geschalteten cores entgegenzuwirken wenn im suspend hotplugging-limitierung aktiv war
- überflüssige codeteile entfernt / dokumentation

Tja das ist nun das "Biest" das mich so lange aufgehalten hat. hauptsächlich wegen der fixes bezüglich der freezes beim schalten. glaubt mir es mag zwar nicht so gut sein sein phone mit der Powertaste einen hardreset zu verpassen aber ich musste das wirklich sehr oft machen und es hat ihm bis jetzt nicht geschadet. Ebenfalls nur so am rande erwähnt

so nun genauer zu den Tuneables/Funktionen die da wären:

Early Demand (loadabhängiger Frequnez Booster):
early_demand -> Schalter für die early demand Funktion (mögliche werte 0 aus or 1 ein, standard: 0)
grad_up_threshold -> schaltet Frequenzen in Abhänigkeit des Loadanstiegs (im Stück) sofort hinauf (möglicher Bereich von 11 bis 100, standard 50)
kleines Beispiel zum Verständnis: wenn zb. der Load im Stück den Wert 50% hoch gehen würde wird dann nicht mehr auf das Erreichen des up_thresholds gewartet sondern die Frequenz sofort hinauf geschalten.

Fast Scaling (nun erweitert):
Fast Scaling gibt es nun in 4 Stufen und 2 Modi. Werte von 1-4 entsprechen den Sprüngen in der Scaling Tabelle aber nur nach oben nach unten geht es in diesem modus "normal". Werte 5-8 entsprechen den Sprüngen 1-4 aber mit dem Unterschied das hier fast up und down skaliert wird. HINWEIS: offensichtlich können hier zu hohe werte ruckeln verusachen 1-2 oder 5-6 sollte aber kein Problem darstellen.

Hotplugging Schalter:

disable_hotplug -> um es auf "playstore neudeutsch" zu sagen "es tut was es soll" *g* (mögliche werte alles über 0 um hotplugging abzuschalten und 0 um es zu aktivieren, standard 0 also hotplug aktiv)

Sampling Down Factor und Sampling Down Momentum:

Beschreibung: vom original Author von ondemand_sampling_factor David Niemi: "Dies verbessert die Performance mittels reduzieren des Overheads der Loadberechnung im Governor und hilft dadurch der CPU auf ihrem höchsten Wert zu bleiben wenn es gebraucht wird anstatt in der Geschwindigkeit zu schwanken."

und diese "Sampling Down Momentum" Funktion von Stratosk macht dies zusätzlich noch dynamisch

sampling_down_max_momentum -> maximaler sampling down Faktor welcher von momentum gesetzt werden soll (0 um momentum auszuschalten, möglicher bereich von sampling_down_factor bis 100000, standard 0 deaktiviert)

sampling_down_momentum_sensitivity -> wie schnell der sampling down factor geschaltet werden soll (mögliche werte von 1 bis 500, standard 50)
sampling_down_factor -> in Abhängigkeit vom aktiven Modus der Faktor für den sampling rate multiplier welcher die ganze sampling rate beeinflusst oder der wert für die stock "down skip" Funktion welche nur das down scaling beeinflusst (mögliche werte sind von 1 bis 100000, standard 1 disabled)

Die originale "down skip" oder conservative-Stock-Methode kann einfach mittels setzen der momentum tuneable auf 0 aktiviert werden. also wenn momentum ausgeschaltet ist gibt es einen Fallback zu der Stock Methode. Wie der Name "down skip" sagt arbeitet diese Methode ein "wenig" anders als die stock ondemand sampling down Methode (auf welcher momentum basiert) Hier wird einfach entsprechend dem angegebenen Wert (=samples) das down scaling unterbrochen. wenn man die sampling down geschichte
komplett deaktivieren will kann man das mit dem setzen dieser Tuneable auf 1 bewerkstelligen. Also zusammfassend: sampling_down_momentum = 0 und sampling_down_factor = 1 würde dann sampling down komplett deaktiviern (und das wären auch in den governor standard Settings so)

Dynamic Screen Frequency Scaling:

Wie der Name schon sagt schaltet diese Funktion in Abhänigkeit der Scaling- und Hotplugging-Einstellungen die man vornehmen kann dynamisch die LCD Frequenz von 60hz (stock) auf 40hz herunter. Hinweis: dies verusacht bei aktiven 40hz Modus einen leichten ruckeleffekt wie er von dem Energiesparmodus her bekannt ist. (nochmals danke an Yank555 für die ganzen Erweiterungen!)

Folgende tuneables sind für diese Funktion hinzu gekommen:
lcdfreq_enable -> ein/aus-Schalter für LCDFreq scaling (mögliche werte 0 aus oder 1 ein, Standard: 0)

lcdfreq_kick_in_down_delay -> die Anzahl der Samples die gewartet werden sollen unterhalb der Threshold Frequenz bis in den low Display Modus (40hz) geschaltet wird

lcdfreq_kick_in_up_delay -> die Anzahl der Samples die gewartet werden sollen oberhalb der Threshold Frequenz bis in den low Display Modus (60hz) geschaltet wird

lcdfreq_kick_in_freq -> unterhalb dieser Frequenz wird der low Display Frequenz Modus (40hz) aktiviert.

lcdfreq_kick_in_cores -> die Anzahl der Kerne welche online sein müssen bevor in den low Modus geschaltet wird (auch in kombination mit dem Freq Threshold benutzbar)

Boeffla Kernel Einstellungen im Unterschied zu 0.4 geändert in Version 0.5
(vlt. als Basis für eigene Einstellungen zu verwenden)

Änderungen in Battery Setting (Dank an Yank für die hotplug werte!):
Sampling rate = 1800000
Sampling rate sleep multiplier = 4
Sampling Down komplett deaktiviert
Hotplug1 Up threshold = 60
Hotplug2 Up threshold = 80
Hotplug3 Up threshold = 98
Hotplug1 down threshold = 45
Hotplug2 down threshold = 55
Hotplug3 down threshold = 65
Up threshold sleep = 100
Freq limit sleep = 700000

Änderungen in optimized Setting:
Sampling rate sleep multiplier = 4
Sampling down faktor = dynamisch
Sampling down max momentum = 20
Sampling down momentum sensitvity = 50
Up threshold sleep = 100
Freq limit sleep = 700000
Fast scaling = 1
Fast scaling sleep = 1
Early demand eingeschaltet
Grad up threshold = 25

Änderungen in performance Setting:
Sampling rate sleep multiplier = 4
Sampling down faktor = dynamisch
Sampling down max momentum = 50
Sampling down momentum sensitvity = 25
Up threshold sleep = 100
Freq limit sleep = 700000
Fast scaling = 2
Fast scaling sleep = 1
Early demand eingeschaltet
Grad up threshold = 15

LCD Freqency Scaling könnt ihr bei Bedarf mit den gängigen Apps wie SetCPU AndroidTuner & Co aktiviern.

Da es leider immer noch vor kommt das es beim umschalten des governors zu deadlocks kommt, wurden noch einer 0.5.1a version released welche dies reduzieren sollte (leider nicht 100% aber stark reduziert! ja es ist etwas schwiergig das zu beheben *g*) Des weiteren wurde das scaling in einer sich im Test befindlichen Version 0.5.1b stark verbessert (danke JP! das biest das ich geschaffen habe fühlt sich bei dir anscheinend wohl *g*)

ZZMoove Governor v0.5.1b (in kooperation mit Yank555)

Wie angekündigt hier nun die neueste Version 0.5.1b mit folgenden Änderungen:

Spoiler

- Deadlock beim Governor umschalten nun endgültig behoben!!
- Komplette Überarbeitung/Verbesserung der Scaling Logik von und mit Yank555 (Dank und Credits!)
- Einige Tuneables intern vereinfacht (Dank und Credits an Yank555)
- Komplette Überarbeitung der Hotplug Logik (löst vielleicht auch das zeitweise Problem mit dem Anhalten des Hotpluggings/Scalings)

ZZMoove Governor v0.6 (in kooperation mit Yank555)

mit folgenden Änderungen:

Spoiler

- Weitere Verbesserung/Flexibilisierung in der Scaling Logik durch Verwendung der System Frequenz Tabelle anstatt einer fixen Tabelle im Governor. (Dank und credits an Yank555)
- Support für 2 und 8 Kern Systeme hinzugefügt (schaltbar mit "MAX_CORE" macro, standard sind 4 Kerne)
- Weitere Verbesserung/Flexibilisierung der Hotplug Logik durch Reduzierung, Verwendung von seperaten Funktionen ausserhalb des cpu check schleife und durch erkennen der möglichen Kerne da wo es nötig ist.
- Fixierte standard hotplug threshold Werte auf jeweils einen up und down Wert reduziert und Verwendung einer Tabelle für alle hotplug werte.
- Fehler in allen "Frequenz tuneables" behoben (Yank555):
Schleife beenden wenn die Frequenz gefunden wurde und Rückgabe eines Fehlerwertes wenn die eingegebene Frequenz in der Tabelle nicht gefunden wurde.

ZZMoove Governor v0.6a (in kooperation mit Yank555)

mit folgenden Änderungen:

Spoiler

- Flexibilität in Scaling Logik erweitert - Kompatibilität für Systeme (wie zb. die OMAP4 Plattform) mit "invertierter" Systemfrequenztabelle (Dank und Credits an Yank555)

ZZMoove Governor v0.7 (in kooperation mit Yank555) aka "Gezämtes Biest"

mit folgenden Änderungen:

Spoiler

- Reduzierung des Eigenverbrauchs durch Hotplugging - einstellbare "Verlangsamung" des Hotplugging-Vorgangs.
- "Legacy Modus" zur Aktivierung der alten Hotplugging/Scaling Methoden der Versionen 0.4/0.5.
HINWEIS: Dieser Modus kann nur 4 Kerne und eine max Scaling Frequenz von 1800mhz "verwalten".
- "Hotlug Idle Modus" zur "Reduzierung" des CPU Loads bei idle und gegebenenfalls zur Reduzierung von erhöhter idle Temperatur.
Genauer gesagt Verteilung des Loads bei idle durch deaktivieren von Hotplugging ab einem bestimmten Load und bei minimaler idle Frequenz.
- Einführung von Hotplug Freq-Thresholds zur Einstellung von Hotplugging in Abhänigkeit der Scaling Frequenz (Yank555)
- interne Verbesserung aller hotplug tuneables (Yank555)
- Version tuneable hinzugefügt (Yank555)

folgende Tuneables sind dazu gekommen:

legacy_mode -> um auf den Legacy Modus zu schalten. Mögliche Werte 0 zum abschalten, jeder Wert über 0 zum einschalten (default ist 0)
HINWEIS: dieser Modus muss per aktivierung des Macros
"ENABLE_LEGACY_MODE" in source freigeschalten werden.

hotplug_idle_threshold -> die höhe des Loads unter welchem das hotplugging ausgeschaltet werden soll wärend die CPU im ruhezustand ist (beziehungsweise bei scaling minimum). Möglich Werte 0 zum abschalten, von 1 bis 100 (default ist 0)

hotplug_block_cycles -> verlangsamen von hotplugging mittels warten der angegebenen Anzahl von Zyklen bevor gepluggt wird. Mögliche Werte 0 abschallten, jeder Wert über 0 zum aktivieren (default ist 0)

disable_hotplug_sleep -> das gleiche wie disable_hotplug aber ist nur bei screen off aktiv. Mögliche Werte 0 abschalten (=hotplugging aktiv), jeder Wert über 0 zum einschalten (default ist 0)

up_threshold_hotplug_freq1 -> Hotplug up Frequenz threshold für Core1. Mögliche Werte 0 abschalten und Bereich von über
down_threshold_hotplug_freq1 bis maximale scaling Frequenz (default ist 0)

up_threshold_hotplug_freq2 -> Hotplug up Frequenz threshold für Core2. Mögliche Werte 0 abschalten und Bereich von über
down_threshold_hotplug_freq2 bis maximale scaling Frequenz (default ist 0)

up_threshold_hotplug_freq3 -> Hotplug up Frequenz threshold für Core3. Mögliche Werte 0 abschalten und Bereich von über down_threshold_hotplug_freq3 bis maximale scaling Frequenz (default ist 0)

down_threshold_hotplug_freq1 -> Hotplug down Frequenz threshold für Core1. Mögliche Werte 0 abschalten und Bereich von minimal Scaling bis unter up_threshold_hotplug_freq1 Frequenz (default ist 0)

down_threshold_hotplug_freq2 -> Hotplug down Frequenz threshold für Core2. Mögliche Werte 0 abschalten und Bereich von minimal Scaling bis up_threshold_hotplug_freq2 Frequenz (default ist 0)

down_threshold_hotplug_freq3 -> Hotplug down Frequenz threshold für Core3. Mögliche Werte 0 abschalten und Bereich von minimal Scaling bis up_threshold_hotplug_freq3 Frequenz (default ist 0)

version -> zeigt die Version des zzmoove governors an (funktioniert nicht mit allen Apps jedoch immer in der Konsole! )

ZZMoove Governor v0.7a (bugfix)

mit folgenden Änderungen:

Spoiler

- Kleinen Fehler in den neuen Hotplug Freq Threshold Tuneables behoben welcher ein Eintragen der "Down" Frequenzen verhindert hat wenn die "Up" Frequenzen auf 0 gesetzt waren. Achtung: in dieser Version ist der Lagacy Modus aus versehen (tschulli! :blushing aktiviert. Also wenn ihr den in eurem build nicht haben wollt einfach wieder auskommentieren!

ZZMoove Governor v0.7b (bugfix)

mit folgenden Änderungen:

Spoiler

- Fehler in der Erkennung der Frequenzanordnung in der Systemtabelle behoben wenn man unveränderte Stock Kernel Sourcen zum kompilieren verwendet welche keine OC Modifizierungen haben.
- Vergessene Suchoptimierung in der Scaling Logik wieder eingebaut (Optimierung nur bei Governor und Cpufreq Frequenz Limit aktiv)
- Vergessene kleine Optimierung in dbs_check_cpu Funktion wieder eingebaut.
- Legacy Mode wieder auf default aus
- Kleinere Code Format and Kommentar Fehlerbehebungen

ZZMoove Governor v0.7c (Kompatibilität)

mit folgenden Änderungen:

Spoiler

- Kompatibilität der Frequenz-Suchoptimierung mit Systemen welche eine aufsteigende Frequenz Tabelle haben komplett hergestellt.
- Nochmals kleinere Optimierungen an verschiedenen Punkten in der dbs_check_cpu Funktion.
- Code aufegräumt - Unnötiges und Whitespaces entfernt (sorry für das große diff dafür ist es nun aber sauber )
- Kommentar bezüglich Frequenzlimit der letzten Version korrigiert.

ZZMoove Governor v0.7d (bugfix)

mit folgenden Änderungen:

Spoiler

- Fehlerbehebung in hotplug up threshold Tuneables - Mit setzen des Wertes 0 können nun wieder Kerne manuell abgeschalten werden.
- Problem in hotplug down threshold Tuneables behoben welche durch eine "falsche" Speicherreihenfolge Werte nicht angenommen haben wenn zb. beim automatischen setzen die Down-Werte höher als die Up-Werte waren.
Achtung: Durch diese Änderung sind nun in diesem Bereich beim ersten Setzen von Tuneables im Governor unlogische Werte möglich die dann nicht richtig funktionieren. Also Vorsicht bei Verwendung von Init.d Scripts oder gespeicherten Profilen in Tuning Apps. Einfach darauf achten dass "Up" Werte immer größer sein sollten als die "Down" Werte und die "Down" Werte immer kleiner als die "Up" Werte. Nach dem ersten Setzen der Werte greift die normale Prüflogik wieder.
- Fehler im hotplug threshold tuneable Makro behoben (Wäre nur im 8-core Modus aufgetreten)
- Fehler in den Hotplug Threshold Tuneables behoben welcher ein unbeabsichtigtes abschalten des jeweilgen Kerns verursachte wenn man den höchst oder niedrigst möglichen Wert eingegeben hat. Der Fehler trat also auf bei Verwendung von 100%/11% in up/down_hotplug_threshold und/oder maximale/minimale Scaling Frequenz in up/down_hotplug_threshold_freq

 

[ZaneZam]

ZZMoove Governor 0.8
(cool down baby!)

Cangelog:

Spoiler

- 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/commits/aosp4.4/drivers/cpufreq/cpufreq_ktoonservativeq.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:

Spoiler

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

Sourcen:
Stable : https://github.com/zanezam/cpufreq-governor-zzmoove
Test: https://github.com/zanezam/cpufreq-governor-zzmoove-tests

Aktuelle Testversion:

Spoiler

Version 0.9 beta1 (aka "slimline")

- Version zum veröffentlichen auf beta erhöht
- Versionsinformationen hinzugefügt/korrigiert und hinfällige entfernt

Profile Header Datei (Version 0.2 beta1):
- Version zum veröffentlichen auf beta erhöht
- Versionsinformationen korrigiert

Version 0.9alpha-2 Changelog

- Auto Fast Scaling (afs) Schritt-Tuneables hinzugefügt:
afs_threshold1 Schritt eins (Werte von 1 bis 100)
afs_threshold2 Schritt zwei (Werte von 1 to 100)
afs_threshold3 Schritt drei (Werte von 1 to 100)
afs_threshold4 Schritt vier (Werte von 1 to 100)

Profile Header Datei (Version 0.2alpha-2):
- Dokumentation korrigiert
- Versionsinformation korrigiert
- Auto Fast Scaling Schritt-Tuneables und Werte zu allen Profilen hinzugefügt

Version 0.9 alpha1 (Yank555.lu) Changelog (credits to Yank555):
- fast_scaling in zwei separate tunables getrennt fast_scaling_up und
fast_scaling_down mögliche Werte 0-4 (springt 0-4 frequenz Schritte)
oder 5 für aufo fast scaling.

- fast_scaling_sleep in zwei separate tunables getrennt fast_scaling_sleep_up und fast_scaling_sleep_down mögliche Werte 0-4 (springt 0-4 frequenz Schritte) oder 5 für aufo fast scaling.

- Legacy Modus entfernt (nötig um fast_scaling tunables auftrennen zu können)
- LCD Frequency Scaling (DFS) entfernt

Profile Header Datei (Version 0.2):
- fast_scaling und fast_scaling_sleep aufgeteilt in fast_scaling_up/fast_scaling_down und fast_scaling_sleep_up/fast_scaling_sleep_down
- Werte in den Profilen Yank Battery und Yank Battery Extreme angepasst

Vorschau auf Kommendes:

nichts derzeit

-------
tja das wars fürs Erste, falls Ihr ZZMoove Governor spezifische Fragen habt dann bitte gerne hier Posten...

Post in Arbeit....
Danke an @Darkman fürs Einfügen der reservierten Posts!

 

[ZaneZam]

Beschreibung wie man die implementierten Profile verwenden kann

Neben den allseits bekannten Einstellungen wie "Yank...", "Battery", "Performance" usw. habe ich speziell für die neue Version 0.8 auch einige neue Einstellungen erstellt welche im Detail HIER eingesehen werden können.

Für diejenigen von euch welche nicht die Möglichkeit haben diese Einstellungen mit vom Kernel Entwicklern bereitgestellten Tools/skripts oder was auch immer verwenden zu können aber dennoch diese verwenden wollen können nun folgendes tun:

Verwendet Tools wie zB. Android Tuner, SetCPU oder ähnlche Tools welche das Umschalten mehrerer Tuneables "on-the-fly" unterstützen oder verwendet direkt das SYSFS mittels eines Terminal Emulators und gebt der Tuneable "profile_number" einen der folgenden Werte:

1.) für Default (setzt governor standardeinstellungen)
2.) für Yank Battery -> altbekannte unveränderte Einstellung
3.) für Yank Battery Extreme -> altbekannte unveränderte Einstellung
4.) für ZaneZam Battery -> altbekannte unveränderte Einstellung
5.) für ZaneZam Battery Plus -> NEU! überarbeitete 'schnellere' Einstellung in Richtung Batterieersparnis
6.) für ZaneZam Optimized -> altbekannte unveränderte Einstellung
7.) für ZaneZam Moderate -> NEU! Einstellung basierend auf 'zzopt' welche hauptsächlich (aber nicht strikt!) nur 2 Kerne verwendet
8.) für ZaneZam Performance -> altbekannte unveränderte Einstellung
9.) für ZaneZam InZane -> NEU! basierend auf der performance Einstellung mit dem neuem "Auto Fast Scaling" aktiv. Eine neue Erfahrung!
10.) für ZaneZam Gaming -> NEU! basierend auf der performance Einstellung mit dem neuen "Scaling Block" aktiviert um eine mögliche
CPU "Überhitzung" beim Spielen zu verhindern.

Übrigens Ja die Anodrnung der Profile ist richtig so ich habe versehentlich in der Dokumentation die Nummern von "Moderate" und "Optimized" vertauscht!!

Nach aktualisieren der Tuneable-Ansicht in den Tools oder in der Konsole kann man nun in der Tuneable "profile" den Namen des aktuell geladenen Profils sehen. Aber bitte beachten nicht jedes Tool unterstützt das anzeigen von "Chars" in den Tuneables weil sie intern diese nur als Zahlen behandeln. In Wirklichkeit gibt das sysfs informationen jedoch immer im "Char" Format aus. Somit wird hier dann "-1" angezeigt (zb. bei SetCPU) nicht so bei Android Tuner was zum wiederholten Male zeigt wie gut diese App ist.

Noch ein paar Worte über die "Game" Einstellung: Es könnte uU. Spielperformanceeinbrüche oder gar Lags bei diesem auftreten da ich diese recht agressiv in Bezug auf das "Herunterholen" der Frequenz gemacht habe. Mein Referenz-Spiel war Angry Birds Star Wars *g* und den ZZMoover in Verbindung mit diesem Spiel zu "beruhigen" war wirklich eine kleine Herrausforderung! Ich weiss nicht warum aber es scheint das System viel mehr zu belasten als andere Spiele und ihr wisst wie "nervös" ZZMoove sein kann! Ein anderes Referenz-Spiel war "Temple Run 2" bei welchem man mit diesem Setting alledings sehr gute Ergebnisse erziehlen kann. Es ist leider etwas schwierig hier EIN universelles Setting für alle Spiele zu finden denn diese Unterscheiden sich zu sehr in Bezug auf wie sie das System belasten. Also sollten wir unsere Erfahrung damit teilen um es gegebenenfalls noch weiter zu Verbessern bis ich die Scaling Bremse etwas "intelligenter" gemacht habe und sie dadurch automatisierter läuft (idee existiert bereits!)

Ich wünsche viel Spass mit all den Einstellungen und freue mich auf Rückmeldungen eurerseits wie sie bei euch dann so laufen!

 

[AtomEffekt]

WoW Mike. Klasse Arbeit!
Ich bin eigentlich ausschließlich auf deinem Beast unterwegs und hätte auch schon die ehre einer der frühen Tester zu sein. Wie du weißt rennt er ja auf boefella problemlos und die Performance Version kommt schon nah an lulz ran (Benchquarks )
Ich hoffe dein biest wird noch länger in vielen neuen Versionen auf meiner gelähmten Diva laufen.
Eigentlich noch nie wirkliche Probleme mit deinem Gov gehabt.

Respekt auch für die Beschreibung!

Auf - hoffentlich - noch viele viele Stunden mit deinem Beast unter der Haube!

Grüße

 

[Lycidias]

Danke Zane! Hab mich echt in den zzmoover verliebt ;-)

 

[SavanTorian]

"meine fresse, geiler scheiss, altah!" *bäm*
(originalton meiner nichte o.O.)

ich les mir das morgen abend in ruhe durch.... nach langem arbeitstag auch mal ins bett ... *gähn*...

 

[red_guard]

richtig geniale Beschreibung, thx

 

[Matthias1968]

richtig geniale Beschreibung, thx

Dem gibt es nichts hinzuzufügen.

Gruß Matthias

 

[Sakaschi]

Jo für mich der beste governor. Habe ihn in Verbindung mit dem yank Kernel. Akku ist perfekt und der speed auch. Ich bin auch froh immer die neuste beta testen zu können. Danke für die Beschreibung Zane

 

[EdgA]

erste sahne zanezame!!
mach bitte einfach weiter, so wie gewohnt... und wir alle haben hier noch ne Menge Spaß zusammen und vor allem mit unserem S3

 

[SavanTorian]

kann es sein, dass man beim tunen von Freq limit sleep = 700000 auf 900000 generell bessere werte erziehlt, vor allem was bei battery die akkuschonende wirkung betrifft? is bei mir zumindest so.

 

[ZaneZam]

kann es sein, dass man beim tunen von Freq limit sleep = 700000 auf 900000 generell bessere werte erziehlt, vor allem was bei battery die akkuschonende wirkung betrifft? is bei mir zumindest so.

Das wäre zwar ein invertiertes und unerwartetes verhalten aber wer weiss mir fehlen jetzt Vergleichswerte. wenns bei dir so ist muss ich das doch glatt mal probieren, beim biest ist alles möglich

 

[S13gfried]

Bei mir ist es auf 500mhz und alles cool.

Schöne Anleitung/FAQ oder ähnliches. Da weiß man mal, was man selber noch an seine Bedürfnisse anpassen kann.

Mir sind vor allem die down threshold´s zu tief. Könnte ehr runter feuern, macht er auch bei mir. Keine Einbußen.

 

[SavanTorian]

ich spiele derzeit mit unheimlich vielen einstellungen via setcpu rum... vielleicht auch zuviel.... wahrscheinlich flash ich dann den kernel zum reset dann nochmal

 

[ZaneZam]

An alle Bastler und Interessierten:

OP um Version 0.5.1b ergänzt mit dem endgültigen Fix des verfluchten Umschalt-Problems!!

Viel Spass damit!
ZZ

 

[ZaneZam]

ui ui vergessen zu posten also auch hier noch nachträglich und vollständigkeitshalber :

ZZMoove v0.6 veröffentlich! juhui!

wem muss ich jetzt eins überziehen das ich den Fred Titel wieder ändern kann? ne schääärz, don't mess with the god's i know!

nein im ernst an wen kann ich mich denn da wenden? an irgend einen Mod oder gibts hier einen bestimmten zuständigen, und wo find ich den? *g*
naja bei meiner blasphemie hier wird sich der nun bald bei mir melden *schluck* *g*

sorry voll der fred-nooby hier, aber das mit den 3 tagen bearbeitungsende hab ich mitbekommen! ach ja da fällt mir ein ich hatte ja mal kontakt mit einem sehr netten mod... genau, mal raus suchen *kram*

mit sinnlosem zeug bekommt man den post dann auch gefüllt, was?
auf jeden fall wünsch ich euch VIEL SPASS mit dem neuen beast (sehr brav inzwischen! *g*)

ZZ (sorry etwas durch den wind heute! *g*)

 

[AtomEffekt]

Top, Top, Top
Mehr gibt es dazu nicht zu sagen..
Klasse arbeit Maik!

 

[S13gfried]

Der hat doch getrunken

ich werde auch mal durch alle Freds ziehen und Monologe posten
Wenn mich jemand ermahnt, sag ich dir bescheid

Trotzdem, gute Arbeit

 

[ZaneZam]

Der hat doch getrunken

ich werde auch mal durch alle Freds ziehen und Monologe posten
Wenn mich jemand ermahnt, sag ich dir bescheid

Trotzdem, gute Arbeit

danke siggi *hicks*

 

[Lord Boeffla]

Oha. Mike... Wassn los? Hihi.

Und ja, schreib einem Mod mal, die müssen Deine Bearbeitungszeit höher stellen damit du zumindest mal ein Jahr lang Deinen Thread pflegen darfst. War bei mir auch so.

Andi