Are both cores working? Is there an app where I can monitor that? I use SetCPU and have it @ 1.5Ghz on-demand.
Thanks...
You can try CPU Guage from the market
Simple speedometer type guage, shows each core and if active
Both cores are operational in android roms, when needed. That is a fact.
With this app and ondemand setting, core two only kicks in if you exercise the screen quickly by switching between the cpu speed an temperature screens
There are probably other apps that will show the cores better
Good luck
In setCPU select info then CPU and it will show processor 0 and processor 1 but only when the core is been used so make sure something is running
Hi,
I have tried some kernels and they run smoothly. Most of them have some governors, such as ondemand or intellidemand, and you can set frequency for each cpu. Is there someway that you can just use one cpu, turning off all other three. Or you can use all the four cpus at the same time. The third option is that you use cpus dynamically, you can set threshold when to turning on another cpu, like the four levels in hotplug control. Thanks if you can give a hint.
stevenleelfc24 said:
Hi,
I have tried some kernels and they run smoothly. Most of them have some governors, such as ondemand or intellidemand, and you can set frequency for each cpu. Is there someway that you can just use one cpu, turning off all other three. Or you can use all the four cpus at the same time. The third option is that you use cpus dynamically, you can set threshold when to turning on another cpu, like the four levels in hotplug control. Thanks if you can give a hint.
Click to expand...
Click to collapse
I don't know of any custom kernel that allows this, though you can control frequency individually.
iElvis said:
I don't know of any custom kernel that allows this, though you can control frequency individually.
Click to expand...
Click to collapse
Turn on power saver. It shuts off core 1-3 and throttles down to 1.1Mhz from experience.
----------------------o('_')o----------------------
Sent from an HTC One using xda app and Bulletproof TrickDroid ROM 8.0
Hi,
Weird..., use a custom kernel that allows the user to set its custom hotplug settings (so with Mpdecision off or with an advanced Mpdecision control) like this one:
[kernel][Jul21][sense4.2.2|GoogleEdn]teaMSeven2.1.5|TapWake|S2W|BLN|OTG|Hotplug|OC|UV and tune the settings like your likes, explanation here and yes you can run with only one core with this kernel for example... But why...
You'll need some tests for the settings like you want, you can't control each core frequency (with this kernel) but you can control each core on/off but you need to play with the hotplug settings with this kernel...
Tetsumi06 said:
Turn on power saver. It shuts off core 1-3 and throttles down to 1.1Mhz from experience.
Click to expand...
Click to collapse
I know, but that wasn't what he was asking about.
Custom kernel is needed to manually control MPDecision.
MPDecision will be on by default and automatically turn cores on and off as needed.
Hunt3r.j2 said:
Custom kernel is needed to manually control MPDecision.
MPDecision will be on by default and automatically turn cores on and off as needed.
Click to expand...
Click to collapse
Hi,
Not totally true, just a few kernel's allows a control over Mpdecision, it's on/off (if set in the ramdisk) or it's a custom hotplug settings and in this case Mpdecision is disabled like the kernel I pointed out above (with Francisco's own hotplug routine).
And with some kernel with a "control" over Mpdecision (and I mean Mpdecision by Qualcomm, not another hotplug settings with Mpdecision totally disabled) it's not fully customisable like Flar2's kernel (3 steps) or except for Zarboz's kernel but I think it's an advanced hotplug settings named like Mpdecision (don't quote me on this) but ok fully customizable whatever it's named.
If I remember right Mpdecision is closed source and kernel devs can't make what they want with this (or nothing), maybe with some "reverse engeneering" they can tweak the thing I remember with the Nexus 4, Mpdecision (plus PowerHAL ) it's enabled/disabled, point.
Complicated all this stuff, right
If you want a total control for the number of cores online/offline uses a kernel without Mpdecision but with a custom hotplug routine and you're good, forgot Mpdecision...
Tetsumi06 said:
Turn on power saver. It shuts off core 1-3 and throttles down to 1.1Mhz from experience.
----------------------o('_')o----------------------
Sent from an HTC One using xda app and Bulletproof TrickDroid ROM 8.0
Click to expand...
Click to collapse
Is that only at idle? I thought the other cores started up when needed?
Turning off cores will make the phone unstably slow. Trust me, I've done the next best thing which was to turn C2 and 3 down to 384mhz and the leave 0 and 1 on 1728 and the phone was unusable.
Q&A for [INFO] [v1.0 beta5] [07-01-2015] CPU Governor ZZMoove
Some developers prefer that questions remain separate from their main development thread to help keep things organized. Placing your question within this thread will increase its chances of being answered by a member of the community or by the developer.
Before posting, please use the forum search and read through the discussion thread for [INFO] [v1.0 beta5] [07-01-2015] CPU Governor ZZMoove. If you can't find an answer, post it here, being sure to give as much information as possible (firmware version, steps to reproduce, logcat if available) so that you can get help.
Thanks for understanding and for helping to keep XDA neat and tidy!
ZaneZam said:
Hi Guys,
i thought it would be a good idea to put all the infos of the zzmoove governor around here together on one place
for better way to find it, to have a place to dump stuff for future versions and to give support for specific questions.
for now i just copied the allready existend posts here but will edit this further when i have more time
so lets start with the first
initial version:
ZZMoove Governor v0.1
(post from 18th December 2012, 10:27 PM)
Why that “zzmoove” governor and how it works:
I thought it were pretty cool to have one of my favorite governors back from the old SGS1-days on my actual device, so i decided to take the sources and give that a try on top of boeffla kernel. It worked well so this is now the result of that experiment.
More about the internals:
Basically this is the ported SGS1 version of the well known "smoove" governor from the good old midnight kernel from Michael Weingaertner (mialwe) with a modified CPU hotplug implementation of the ktoonservative governor from ktoonesz. The original implementation from ktoonesz worked well but I observed that on idle most of the time only one cpu was going to sleep. Well that was not enough for me so I made a modification to put the other cpu's also to sleep (except cpu0). That means that this governor uses more often only one cpu on idle and as a consequence of that it needs less energy. Depending on System load and governor settings all 4 cores will be instantly up again if it is needed.
In short:
So what you can expect now from this thingy is a battery-friendly behaving hotplug conservative governor which
uses a frequency lookup table for faster upscaling (so called "smooth scaling") So this is more a energy-safer than a performer.
Tuneables/Defaults:
Sampling Rate (default=2) tuneable: /sys/devices/system/cpu/cpufreq/zzmoove/sampling_rate
Sampling Down Factor (default=4) tuneable: /sys/devices/system/cpu/cpufreq/zzmoove/sampling_down_factor
Up Threshold (default=70) tuneable: /sys/devices/system/cpu/cpufreq/zzmoove/up_threshold
Up Threshold Hotplug (default=68) tuneable: /sys/devices/system/cpu/cpufreq/zzmoove/up_threshold_hotplug
Down Threshold (default=52) tuneable: /sys/devices/system/cpu/cpufreq/zzmoove/down_threshold
Down Threshold Hotplug (default=55) tuneable: /sys/devices/system/cpu/cpufreq/zzmoove/down_threshold_hotplug
Ignore Nice Load (default=0) tuneable: /sys/devices/system/cpu/cpufreq/zzmoove/ignore_nice_load
Freqency Step (default=5) tuneable: /sys/devices/system/cpu/cpufreq/zzmoove/freq_step
Smooth Up (default=75) tuneable: /sys/devices/system/cpu/cpufreq/zzmoove/smooth_up
Links:
Midnight kernel
KT747 Kernel
Common Infos about Governors,I/O Schedulers etc.
Credits to:
mialwe for his smoove governor
ktoonesz for original hotplug implementation
ZZMoove Governor v0.3
(Post from 25th February 2013, 05:06 PM - "more improvements")
there are now many new possibilities to adjust the governor more precisely via sysfs!
Following new tuneables were introduced in this new version:
The so called "sleep" values which were hardcoded in previous version are now changed
to sysfs-tuneables:
The Smooth Scaling for sleep (Screen off):
tuneable -> /sys/devices/system/cpu/cpufreq/zzmoove/smooth_up_sleep
possible values from 1 to 100, default: 100
The up/down Threshold for sleep (Screen off):
tuneable -> /sys/devices/system/cpu/cpufreq/zzmoove/up_threshold_sleep
possible Values from above "down_threshold_sleep" to 100, default: 90
tuneable -> /sys/devices/system/cpu/cpufreq/zzmoove/down_threshold_sleep
possible Values from 11 to under "up_threshold_sleep", default: 44
The Sampling Rate for sleep (Screen off):
tuneable -> /sys/devices/system/cpu/cpufreq/zzmoove/sampling_rate_sleep_multiplier
possible values 1 or 2, default: 2
The amound of cores which should run at "screen off":
tuneable -> /sys/devices/system/cpu/cpufreq/zzmoove/hotplug_sleep
possible Values 0 = do not touch cores (the same behaving as in standard setting of zzmoove) 1, 2 or 3
the number of cores to run on screen off. btw. setting "4" doesn't exist as u can use "0" for that setting!
Beside of that you can now change the hotplug threshold per core independently (thx to gsw5700 for the inital idea!)
and turn cores off completely.
For that purpose following tuneables were introduced and are replacing
the old hotplug up/down threshold tuneables:
tuneable -> /sys/devices/system/cpu/cpufreq/zzmoove/up_threshold_hotplug1
hotplug up threshold for core 1 - 0 = turn off core 1, possible range from "down_threshold" to 100, default: 68
tuneable -> /sys/devices/system/cpu/cpufreq/zzmoove/up_threshold_hotplug2
hotplug up threshold for core 2 - 0 = turn off core 2, possible range from "down_threshold" to 100, default: 68
tuneable -> /sys/devices/system/cpu/cpufreq/zzmoove/up_threshold_hotplug3
hotplug up threshold for core 3 - 0 = turn off core 3, possible range from "down_threshold" to 100, default: 68
tuneable -> /sys/devices/system/cpu/cpufreq/zzmoove/down_threshold_hotplug1
hotplug down threshold for core 1 - possible range from 11 to under "up_threshold", default: 55
tuneable -> /sys/devices/system/cpu/cpufreq/zzmoove/down_threshold_hotplug2
hotplug down threshold for core 2 - possible range from 11 to under "up_threshold", default: 55
tuneable -> /sys/devices/system/cpu/cpufreq/zzmoove/down_threshold_hotplug3
hotplug down threshold for core 3 - possible range from 11 to unter "up_threshold", default: 55
Thanks to:
gsw5700 for the initial Idea "hotplug threshold per core".
brijmathew indirectly for the initial idea "just one core at screen off" (i think he did'nt meant exactly that in his post but hey he switched on the led in my head! *gg*)
ZZMoove Governor v0.4
(Post from 1st May 2013, 10:59 PM - "limits")
Changelog:
Frequency Limits:
First of all there is now a (by me so called) "soft" limit function for limiting frequencies at screen off but also at screen on if u wish. however i recommend to set the screen on limit always with the (if provided) max scaling functionality of the kernel as this is the better way of doing it and "works better" for following reasons: touchboost and wake up frequencies can go above that governor-soft-limit (mostly to 800/1000 mhz) because the governor has no control over these "events" and will be "bypassed" by cpufreq driver! nevertheless by setting this soft limit at screen off the use of frequencies higher than the given limit will be strongly reduced and therefore this will reduce power consumption at screen off. and that was the main intention - saving power if u do not use your phone!
For this function following new tuneables were indroduced to set in sysfs (/sys/devices/system/cpu/cpufreq/zzmoove/):
freq_limit_sleep: limit freqency at screen off (possible values 0 disable limit, 200000-1600000, default: 0)
freq_limit: limit freqency at screen on (possible values 0 disable limit, 200000-1600000, default: 0)
Fast Scaling:
As a second feature in this new version i added the so called (again by me *g*) "fast scaling" for faster up/down scaling! This should bring more performance but on the other hand this can be of course a little bit more power consumptive. try it, it makes things snappier and some people reported that with this setting touch boost can then also be disabled which wasn't really "possible" with previous versions of zzmoove governor.
For this function following new tuneables were indroduced to set in sysfs (/sys/devices/system/cpu/cpufreq/zzmoove/):
fast_scaling: fast scaling at screen on (possible values 0 disable or 1 enable, default: 0)
fast_scaling_sleep: fast scaling at screen off (possible values 0 disable or 1 enable, default: 0)
As last "feature" and to complete the "set" the tuneable "freq_step_sleep" was included to be able to change freq step only at screen off
possible settings are the same as the "freq_step" tuneable which are values from 0% (stops freq scaling) to 100% (switches frequencies from lowest to highest frequency and vice versa like ondmand governor) default is 1 in all settings (bat/opt/perf) at screen off.
ZZMoove Governor v0.5 aka "The Beast"
(performance and fixes)
Changelog:
- completely reworked fast scaling functionality. now using a "line jump" logic instead of fixed freq "colums".
fast scaling now in 4 steps and 2 modes possible (mode 1: only fast scaling up and mode2: fast scaling up/down)
- added support for "Dynamic Screen Frequency Scaling" (original implementation into zzmoove governor highly improved by Yank555)
originated by AndreiLux more info: http://forum.xda-developers.com/showpost.php?p=38499071&postcount=3
- re-enabled broken conservative sampling down factor functionality ("down skip" method).
originated by Stratosk - upstream kernel 3.10rc1: https://git.kernel.org/cgit/linux/k...id=refs/tags/v3.10-rc1&qt=author&q=Stratos+Ka
- changed down threshold check to act like it should.
originated by Stratosk - upstream kernel 3.10rc1: https://git.kernel.org/cgit/linux/k...id=refs/tags/v3.10-rc1&qt=author&q=Stratos+Ka
- implemented/ported "early demand" from ondemand governor.
originated by Stratosk - more info: http://www.semaphore.gr/80-latests/98-ondemand-early-demand
- implemented/ported "sampling down momentum" from ondemand governor.
originated by Stratosk - more info: http://www.semaphore.gr/80-latests/80-sampling-down-momentum
- modified some original conservative code parts regarding frequency scaling which should work better now.
originated by DerTeufel1980: https://github.com/DerTeufel/androi...mmit/6bab622344c548be853db19adf28c3917896f0a0
- added the possibility to use sampling down momentum or conservative "down skip" method.
- increased possible max sampling rate sleep multiplier to 4 and sampling down factor to 100000
accordingly to sampling down momentum implementation.
- added frequency search limit for more efficient frequency searching in scaling "table" and for improving
frequency "hard" and "soft" limit handling.
- added cpu idle exit time handling like it is in lulzactive
again work from ktoonsez : https://github.com/ktoonsez/KT747-JB/commit/a5931bee6ea9e69f386a340229745da6f2443b78
description in lulzactive governor: https://github.com/ktoonsez/KT747-J...f2443b78/drivers/cpufreq/cpufreq_lulzactive.c
- fixed a little scaling step mistake and added overclocking frequencies up to 1800 mhz in scaling frequency "tables".
- fixed possible freezes during start/stop/reload of governor and frequency limit change.
- fixed hotplugging logic at online core 0+3 or 0+2 situations and improved hotplugging in general by
removing mutex locks and skipping hotplugging when it is not needed.
- added possibility to disable hotplugging (that's a debugging relict but i thought maybe someone will find that usefull so i didn't remove it)
- try to fix lags when coming from suspend if hotplug limitation at sleep was active by enabling all offline cores during resume.
- code cleaning and documentation.
for this functions following new tuneables were indroduced:
Early Demand:
early_demand -> switch to enable/disable early demand functionality (possible values 0 disable or 1 enable, default: 0)
grad_up_threshold -> scale up frequency if the load goes up in one step of grad up value (possible range from 11 to 100, default 50)
little example for understanding: when the load rises up in one big 50% step then the
frequency will be scaled up immediately instead of wating till up_threshold is reached.
Fast Scaling (improved):
Fast scaling has now 8 levels which at the same time have 2 modes included. Values from 1-4 equals to scaling jumps in the frequency table and uses the Fast Scaling up but normal scaling down mode. Values from 5-8 equals to 1-4 scaling jumps but uses the fast scaling up and fast scaling down mode.
Hotplugging switch:
disable_hotplug -> switch to enable/disable hotplugging (possible values are any value above 0 to disable hotplugging and 0 to
enable it, default 0)
Sampling Down Factor and Sampling Down Momentum:
Description: From the original author of ondemand_sampling_factor David Niemi:
"This improves performance by reducing the overhead of load evaluation and helping the CPU stay
at its top speed when truly busy, rather than shifting back and forth in speed."
And that "Sampling Down Momentum" function from stratosk does this dynamicly now!
sampling_down_max_momentum -> max sampling down factor which should be set by momentum (0 disable momentum, possible range from sampling_down_factor up to MAX_SAMPLING_DOWN_FACTOR, default 0 disabled)
sampling_down_momentum_sensitivity -> how fast the sampling down factor should be switched (possible values from 1 to 500, default 50)
sampling_down_factor -> depending on which mode is active the factor for sampling rate multiplier which influences the whole
sampling rate or the value for stock "down skip" functionality which influences only the down scaling
mechanism (possible values are from 1 to MAX_SMPLING_DOWN_FACTOR, default 1 disabled)
Original conservative "down skip" or "stock" method can be enabled by setting the momentum tuneable to 0. so if momentum is inactive there will be a fallback to the stock method. as the name "down skip" says this method works "slightly" different from the ondemand stock sampling down method (on which momentum was based on). It just skips the scaling down code for the given samples. if u want to completely disable the sampling down functionality u can achieve this by setting sampling down factor to 1. so concluded: setting sampling_down_momentum = 0 and sampling_down_factor = 1 will disable sampling down completely (that is also the governor default setting)
Dynamic Screen Frequency Scaling:
Dynamicly switches the screen frequency to 40hz or 60hz depending on cpu scaling and hotplug settings. For compiling and enabling this functionality u have to do some more modification to the kernel sources, please take a look at AndreiLux Perseus repository and there at following commit: https://github.com/AndreiLux/Perseus-S3/commit/3476799587d93189a091ba1db26a36603ee43519 After adding this patch u can enable the feature by setting "CPU_FREQ_LCD_FREQ_DFS=y" in your kernel config and if u want to check if it is really working at runtime u can also enable the accounting which AndreiLux added by setting LCD_FREQ_SWITCH_ACCOUNTING=y in the kernel config. If all goes well and u have the DFS up and running u can use following tuneables to do some screen magic: (thx to Yank555 for highly extend and improving this!)
lcdfreq_enable -> to enable/disable LCDFreq scaling (possible values 0 disable or 1 enable, default: 0)
lcdfreq_kick_in_down_delay -> the amount of samples to wait below the threshold frequency before entering low display frequency mode (40hz)
lcdfreq_kick_in_up_delay -> the amount of samples to wait over the threshold frequency before entering high display frequency mode (60hz)
lcdfreq_kick_in_freq -> the frequency threshold - below this cpu frequency the low display frequency will be active
lcdfreq_kick_in_cores -> the number of cores which should be online before switching will be active. (also useable in combination
with kickin_freq)
So this version is a kind of "featured by" release as i took (again *g*) some ideas and work from other projects and even some of that work
comes directly from other devs so i wanna thank and give credits:
First of all to stratosk for his great work "sampling down momentum" and "early demand" and for all the code fixes which found their way into
the upstream kernel version of conservative governor! congrats and props on that stratos, happy to see such a nice and talented dev directly
contibuting to the upstream kernel, that is a real enrichment for all of us!
Second to Yank555 for coming up with the idea and improving/completeing (leaves nothing to be desired now *g*) my first
rudimentary implementation of Dynamic Screen Frequency Scaling from AndreiLux (credits for the idea/work also to him at this point!).
Third to DerTeufel1980 for his first implementation of stratosk's early demand functionality into version 0.3 of zzmoove governor
(even though i had to modify the original implementation a "little bit" to get it working properly ) and for some code optimizations/fixes regarding scaling.
Last but not least again to ktoonsez - I "cherry picked" again some code parts of his ktoonservative governor which should improve this governor
too!
ZZMoove Governor 0.5.1a
(bugfixes)
urgend bugfix release:
- fix governor switching issues (deadlocks) which oviously werend fixed in version v0.5
- optimised scaling function a lot (thx and credits to Yank555!)
ZZMoove Governor 0.5.1b (in cooperation with Yank555)
(bugfixes and more optimisations)
Changelog:
- now really fixed the governor switching issues! (gotcha *****! *g*)
- again some changes in scaling logic from Yank555 (thx and credits)
- simplified some tuneables by using already available stuff instead of using redundant code (thx Yank555)
- reduced/optimised hotplug logic and preperation for automatic detection of available cores
(maybe this fixes also the scaling/core stuck problems)
ZZMoove Governor 0.6 (in cooperation with Yank555)
(flexibility)
Changelog:
- removed fixed scaling lookup tables and use the system frequency table instead
changed scaling logic accordingly for this modification (thx and credits to Yank555)
- reduced new hotplug logic loop to a minimum
- again try to fix stuck issues by using seperate hotplug functions out of dbs_check_cpu (credits to ktoonesz)
- added support for 2 and 8 core systems and added automatic detection of cores were it is needed
(for setting the different core modes you can use the macro 'MAX_CORES'. possible values are: 2,4 or 8, default are 4 cores)
reduced core threshold defaults to only one up/down default and use an array to hold all threshold values
- fixed some mistakes in "frequency tuneables" (Yank555):
stop looping once the frequency has been found
return invalid error if new frequency is not found in the frequency table
ZZMoove Governor 0.6a (in cooperation with Yank555)
(scaling logic flexibility)
Changelog:
- added check if CPU freq. table is in ascending or descending order and scale accordingly
(compatibility for systems with 'inverted' frequency table like it is on OMAP4 platform)
thanks and credits to Yank555!
ZZMoove Governor 0.7 aka "Tamed Beast" (in cooperation with Yank555)
(slow down)
Changelog:
- reindroduced the 'old way' of hotplugging and scaling in form of the 'Legacy Mode' (macros for enabling/disabling this done by Yank555, thx!)
NOTE: this mode can only handle 4 cores and a scaling max frequency up to 1800mhz.
- added hotplug idle threshold for a balanced load at CPU idle to reduce possible higher idle temperatures when running on just one core.
(inspired by @JustArchi observations, thx!)
- added hotplug block cycles to reduce possible hotplugging overhead (credits to @ktoonsez)
- added possibility to disable hotplugging only at suspend (inspired by a request of @STAticKY, thx for the idea)
- introduced hotplug frequency thresholds (credits to Yank555)
- hotplug tuneables handling optimized (credits to Yank555)
- added version information tuneable (credits to Yank555)
for this functions following new tuneables were indroduced:
legacy_mode -> for switching to the 'old' method of scaling/hotplugging. possible values 0 to disable, any values above 0 to enable (default is 0)
NOTE: the legacy mode has to be enabled by uncommenting the macro ENABLE_LEGACY_MODE
hotplug_idle_threshold -> amount of load under which hotplugging should be disabled at idle times (respectively at scaling minimum). possible values 0 disable, from 1 to 100 (default is 0)
hotplug_block_cycles -> slow down hotplugging by waiting a given amount of cycles before plugging. possible values 0 disbale, any values above 0 (default is 0)
disable_hotplug_sleep -> same as disable_hotplug but will only take effect at suspend. possible values 0 disable, any values above 0 to enable (default is 0)
up_threshold_hotplug_freq1 -> hotplug up frequency threshold for core1. possible values 0 disable and range from over down_threshold_hotplug_freq1 to max scaling freqency (default is 0)
up_threshold_hotplug_freq2 -> hotplug up frequency threshold for core2. possible values 0 disable and range from over down_threshold_hotplug_freq2 to max scaling freqency (default is 0)
up_threshold_hotplug_freq3 -> hotplug up frequency threshold for core3. possible values 0 disable and range from over down_threshold_hotplug_freq3 to max scaling freqency (default is 0)
down_threshold_hotplug_freq1 -> hotplug down frequency threshold for core1. possible values 0 disable and range from min saling to under up_threshold_hotplug_freq1 freqency (default is 0)
down_threshold_hotplug_freq2 -> hotplug down frequency threshold for core2. possible values 0 disable and range from min saling to under up_threshold_hotplug_freq2 freqency (default is 0)
down_threshold_hotplug_freq3 -> hotplug down frequency threshold for core3. possible values 0 disable and range from min saling to under up_threshold_hotplug_freq3 freqency (default is 0)
version -> show the version of zzmoove governor
ZZMoove Governor 0.7a
(little fix)
Changelog:
- fixed a glitch in hotplug freq threshold tuneables which prevented setting of values in hotplug down freq thresholds when hotplug
up freq thresholds were set to 0. NOTE: enabling the legacy mode in the source is not part of that fix i just forgot to set it back to standard (disabled) before pushing, sry to lazy to fix that fix now
ZZMoove Governor 0.7b
(compatibility improved and forgotten things)
Changelog:
- fixed stuck at max scaling frequency when using stock kernel sources with unmodified cpufreq driver and without any oc capabilities.
- readded forgotten frequency search optimisation in scaling logic (only effective when using governor soft frequency limit)
- readded forgotten minor optimisation in dbs_check_cpu function.
- as forgotten to switch in last version Legacy Mode now again disabled by default
- minor code format and comment fixes
ZZMoove Governor 0.7c
(again compatibility and optimisations)
Changelog:
- frequency search optimisation now fully compatible with ascending ordered system frequency tables (thx to @psndna88 for testing!)
- again minor optimisations at multiple points in dbs_check_cpu function
- code cleaning - removed some unnecessary things and whitespaces nuked - sry for the bigger diff but from now on it will be clean!
- corrected changelog for previous version regarding limits
ZZMoove Governor 0.7d (bugfix!)
(broken things)
Changelog:
- fixed hotplug up threshold tuneables to be able again to disable cores manually via sysfs by setting them to 0
- fixed the problem caused by a "wrong" tuneable apply order of non sticking values in hotplug down threshold tuneables when
hotplug up values are lower than down values during apply.
NOTE: due to this change right after start of the governor the full validation of given values to these tuneables is disabled till
all the tuneables were set for the first time. so if you set them for example with an init.d script or let them set automatically
with any tuning app be aware that there are illogical value combinations possible then which might not work properly!
simply be sure that all up values are higher than the down values and vice versa. after first set full validation checks are enabled
again and setting of values manually will be checked again.
- fixed a typo in hotplug threshold tuneable macros (would have been only a issue in 8-core mode)
- fixed unwanted disabling of cores when setting hotplug threshold tuneables to lowest or highest possible value
which would be a load of 100%/11% in up/down_hotplug_threshold and/or scaling frequency min/max in up/down_hotplug_threshold_freq
Click to expand...
Click to collapse
Thanks for great inputs
Hi!
Where I can read is responsible for what in one way or another option?
Now I'm interested in the inputboost options.
What's the difference between inputboost_cycles and inputboost_punch_cycles?
What give these options: inputboost_punch_epenmove and inputboost_punch_fingermove?
Forgive me if I ask stupid questions))
Thanks!
ilfat12 said:
Hi!
Where I can read is responsible for what in one way or another option?
Now I'm interested in the inputboost options.
What's the difference between inputboost_cycles and inputboost_punch_cycles?
What give these options: inputboost_punch_epenmove and inputboost_punch_fingermove?
Forgive me if I ask stupid questions))
Thanks!
Click to expand...
Click to collapse
hi ilfat12,
you can get more infos about the new features here : https://github.com/zanezam/cpufreq-governor-zzmoove/commit/75c431aeff8354f224e4c688faa1559ac463ab8a
and especially for the info u are searching i want to quote ffolkes description from here http://www.plasmakernel.com/?p=214:
Added native input booster to ZZMoove (based on faux123′s intelliactive)
I’ve added my own port of the native input booster from intelliactive into ZZMoove. Input events such as buttons, touchkeys, and the touchscreen will temporarily modify different ZZMoove settings. Using this allows for extremely conservative governor settings to be used without affecting performance. The boost is made up of two stages; the first is meant to be a very short high speed burst, just a few hundred milliseconds. The second stage is a reduced up threshold that is applied for the duration of the entire boost.
Click to expand...
Click to collapse
in short this means: inputboost_cycles = main switch = duration of whole input boost
inputboost_punch_cycles = duration of the freq "punch" therefore the freq boost duration
inputboost_punch_epenmove and inputboost_punch_fingermove are addons to this functionality
and are influencing the boost of the freq in following way: if one of these tuneables are set then
either on epen move (for devices with epen) or on finger move the punch will be reinitialized constantly
without expiring so actually its behaving like the regular system touch booster which has every device in some
way implemented. so that mode is kind of redundant if u use the system touch booster in addition, exception would be
if u want to overwrite the system booster with the governor boost. if i use it i usually like to use the native booster with
fingerdown enabled thats a good compromise i think.
hope it's somehow more understandable now for u
and hey never be sorry to ask, there are no stupid questions only stupid people who don't ask
Deep Sleep
How do I enable deep sleep mode at zzmove? Because mine is not working
Henriquefeira said:
How do I enable deep sleep mode at zzmove? Because mine is not working
Click to expand...
Click to collapse
you mean the governor "sleep" settings? it depends on the used kernel and how it has implemented zzmoove. they can be switched off by intention in the source code or are disabled automatically because no power management implementation or display state detection is used in the kernel.
but if u mean that u have wake locks and your device doesn't deep sleep then you have another problem which is not related to kernel/governors
in that case u can check what service/app is keeping your device awake with better battery stats for example to find the root cause.
Default profile Set.
Is this possible to make make yang battery extreme (3) profile set by default.....? Every time i set this but changed automatically zzrelax(11).....After unlock my phone....!
Hi ZaneZam. I use your Governor with Boeffla Kernel Beta on my S5.
I use the optimized profile with following additional tunables:
Fast Scaling Sleep Up: 5
Fast Scaling Sleep Down: 5
Fast Scaling Up: 5
Fast Scaling Down: 5
Sampling Rate Sleep Multiplier: 2
I use apps like Facebook or Chrome and than the phone freezes and reboots. This happened 2 times every day.
I checked the Insane profile and that's very similar to the optimized with my tunables. Why it doesn't work?
tuhinxp04 said:
Is this possible to make make yang battery extreme (3) profile set by default.....? Every time i set this but changed automatically zzrelax(11).....After unlock my phone....!
Click to expand...
Click to collapse
Yes it is possible either via a default value in the governor itself or maybe via the tool u use to switch it which u didn't reveal to us
i just can say that there is nothing included from my side which changes a profile "at sleep" so it must be something which is dealing with the tuneables automatically. I can imagine some kind of "at sleep changing settings" mode.
Solvin said:
Hi ZaneZam. I use your Governor with Boeffla Kernel Beta on my S5.
I use the optimized profile with following additional tunables:
Fast Scaling Sleep Up: 5
Fast Scaling Sleep Down: 5
Fast Scaling Up: 5
Fast Scaling Down: 5
Sampling Rate Sleep Multiplier: 2
I use apps like Facebook or Chrome and than the phone freezes and reboots. This happened 2 times every day.
I checked the Insane profile and that's very similar to the optimized with my tunables. Why it doesn't work?
Click to expand...
Click to collapse
hm I don't have to ask if u are using uv/oc, don't I? maybe any chance of a crash log? the S5 seems still disliking zzmoove in some situations.
ZaneZam said:
Yes it is possible either via a default value in the governor itself or maybe via the tool u use to switch it which u didn't reveal to us
i just can say that there is nothing included from my side which changes a profile "at sleep" so it must be something which is dealing with the tuneables automatically. I can imagine some kind of "at sleep changing settings" mode.
hm I don't have to ask if u are using uv/oc, don't I? maybe any chance of a crash log? the S5 seems still disliking zzmoove in some situations.
Click to expand...
Click to collapse
I don't use UV, only OC but without OC it's the same. How can I create a crashlog?
Solvin said:
I don't use UV, only OC but without OC it's the same. How can I create a crashlog?
Click to expand...
Click to collapse
good at least no uv in case of boeffla kernel its quite easy to create a crash log: just let the crash happen with kernel logger enabled (don't forget to enable it beforehand in config app!) then after system is up again right after the crash-reboot. go to action menu->create debug file. this file will be created in boeffla-data folder on your sdcard and is called "debug-date-time.txt" (the coming popup shows it more exactly) send this file to [email protected] then i can see what happend - hopefully, as the S5 crash logs are almost never much meaningful. but maybe u can give me the crucial hint with this log, lets see. the "good thing" for me is that u can reproduce it! thx in advance...
OK I will do that and send it to you. Thank you!
Currently no reboots or freezes. I think that was the problem:
http://forum.cyanogenmod.org/topic/114602-random-reboots/#entry534858
Today I got a Greenify update from playstore with that changes.
I hope that solved my problem.
And it crashed again (reboot). I send you the crashlog via mail
Solvin said:
And it crashed again (reboot). I send you the crashlog via mail
Click to expand...
Click to collapse
thx for the log, it rebooted yes but it didn't crash (at least the kernel did not!)
so in short: the log is clean, no kernel problem in my opinion but one thing: you have UV set to "custom" in boeffla config which means "the setting for custom values"
and which could still contain values u have changed previously (or have changed by a settings preset)! if u really want stock settings then choose "no undervolting"!
Lord boeffla recently changed the naming from "none" to "custom" upon the advice of me because i had one user which had a similar problem like u (i ask about uv because
of a reason, it's "smelling like that" *g*) and this user had previously tested values still active because he thought "none" is "off" so try to choose "no undervolting" then
u really have no uv values set.
hope this stabilizes things for u. otherwise feel free to get back with another log
:fingers-crossed:
ZaneZam said:
thx for the log, it rebooted yes but it didn't crash (at least the kernel did not!)
so in short: the log is clean, no kernel problem in my opinion but one thing: you have UV set to "custom" in boeffla config which means "the setting for custom values"
and which could still contain values u have changed previously (or have changed by a settings preset)! if u really want stock settings then choose "no undervolting"!
Lord boeffla recently changed the naming from "none" to "custom" upon the advice of me because i had one user which had a similar problem like u (i ask about uv because
of a reason, it's "smelling like that" *g*) and this user had previously tested values still active because he thought "none" is "off" so try to choose "no undervolting" then
u really have no uv values set.
hope this stabilizes things for u. otherwise feel free to get back with another log
:fingers-crossed:
Click to expand...
Click to collapse
Damn! I thought it was off, but you are right, my device was UV. But that was a stock setting from the kernel. I hope that was the Problem. Thank you very much ZaneZam.
Samsung Galaxy S5 - G900F
ROM: CM12.1 Nightly
Kernel: Boeffla 2.2-beta2
CP/BL: G900FXXU1BOH4
Recovery: TWRP 2.8.7.0
Can I get some help with my LG G3 zzmove profile 2 /5 settings? It runs good with the default settings, but I'd like to get some more performance and speed and get rid of the lag I have. SlimSaber 5.1.1 Nebula 12.0 using Kernel Adiutor
Someone explain about profile? i read it many time but dont understand it.
thaibinh262 said:
Someone explain about profile? i read it many time but dont understand it.
Click to expand...
Click to collapse
profiles are just predefined settings but included in the governor itself and switchable via a tuneable.
nytebird said:
Can I get some help with my LG G3 zzmove profile 2 /5 settings? It runs good with the default settings, but I'd like to get some more performance and speed and get rid of the lag I have. SlimSaber 5.1.1 Nebula 12.0 using Kernel Adiutor
Click to expand...
Click to collapse
still relevant? . sry completely missed that I would suggest to try all other settings then and see... if none of them suits u u anyway have to adjust the tuneables in particular to. make things better.. nut this is a huge topic then.
music_state
What does music_state tuneable do?
Hi
I am trying to control my CPU governor and Frequency through Tasker, and it also works to some degree, the governor works and frequency control on 4 cores works.
However I have a Sony Xperia Z5 with Linage OS custom ROM running. I can through the Action in Tasker get the frequencies for CPU 0 - 3, but not for 4 - 7. What I know ( I could be mistaken) is that the first 4 cores are low power cores and the other 4 are high performance/ power cores.
There is a file for all the cores where you can see the frequency stepping and I've check and this file is there for the first 4 cores and correctly indicates the stepping from 384MHz to 1550MHz.
However for core 4 to 7 only core 5 have a stepping file which also correctly shows the stepping for the high performance cores which is 384Mhz to 1960Mhz.
The Action in Tasker does as mentioned above only set the frequency control for the first 4 cores. not the last 4 cores. How do I fix this. ? I was thinking that i could copy the cpufreq folder from CPU 5 to the other 3 "CPU's" (4,6,7). However The Tasker Action still cannot find the correct stepping for Core 5 even though the stepping file is available.
I'm not sure the above makes sense, so please ask for clarification. Hope anyone have an input for this problem because i cannot be the only one.
Regards