yashsingh1/xdaforums huggingface dataset:
[Galaxy S III Android Development] alberber:
Finally we have a thread for zzmove governor!! :victory: :D:D

Great explanations Zane! I don't understand a few things though haha.

This is very useful, thank you very much. I'll try to learn and test tweaks for this governor, but will be probably asking you about some new features I don't get to understand :(

Thanks!! :good::good:

Enviado desde mi GT-I9300 usando Tapatalk 2
[Galaxy S III Android Development] core720:
the best is disable touchboost or enable=?
[Galaxy S III Android Development] ginzo:
I'm very happy for this thread! !

I will study it to understand better zzmove :D

un pò di tap qui e là... :)

Rom: Maya Rom v5.2

Kernel: Boeffla 2.12 beta 8

Modem: Buemc2

Operator: Tim

Recovery: Philz touch
[Galaxy S III Android Development] STAticKY:
[MENTION=3279788]ZaneZam[/MENTION]

I've been trying to setup lcdfreq to stay on 40hz regardless of frequency and cores.. No matter how I set it up I can't get it to sit on 40... I can get it to sit on 40 MOST of the time, but not ALL the time...

Any help appreciated..

Oh and I'm using temasek's ROM (RC5.4.1) and kernel (160613 wolfston with abb)..

Thanks

TP.
[Galaxy S III Android Development] ZaneZam:
since version 0.4 u can if u want, on earlier versions it lagged like hell.

it works quite well without touchboost on v0.5.x but for my taste i leave it on as i want my phone as touch responsive as possible.

but just try it maybe u like it without touchboost. ;)
[Galaxy S III Android Development] ZaneZam:
ok have u tried to enter 1300000? (assuming 1400000 is your max scaling setting) that should enable it all the time.

i dunno exaclty which lcd freq scaling implementation is used in temaseks kernel but i assume it's the original from

andreilux. in this implementation there is an additional touchboost switch which we removed in the boeffla

implementation. if i remember right this touchboost switch enabales hi frequency on touch. so your settings

might be overwritten by this. ;)
[Galaxy S III Android Development] STAticKY:
Using max CPU freq at 1400 with lcdfreq freq threshold at 1300. Touch boost turned off.... Baffles me. I've also tryed setting max CPU freq to 1200 and lcdfreq freq threshold to 1300 because of something tema or yank said.. Can't remember what it was off hand.. I'll have a look back

TP.
[Galaxy S III Android Development] core720:
Zane

Enviado desde mi GT-I9300 usando Tapatalk 2
[Galaxy S III Android Development] STAticKY:
He answered you 3 posts up...

TP.
[Galaxy S III Android Development] Yank555:
What Zane meant is that in Perseus, there was a touch boost

for LCDfreq

(I believe to remember sth like that at least), this has nothing to do with CPU touch boost. Whenever you touched the screen, LCDfreq would be bumped to 60Hz no matter what, with the idea to remove lags when actively using the device.

In case Temasek has that in his kernel, that would be something we do not have in either Boeffla nor mine ... LCDfreq scaling is purely based on the CPU freq (as per the tunables), touching the screen will not change anything in our implementation.

Might be worth checking...

JP.
[Galaxy S III Android Development] STAticKY:
Yea I don't think he has that implemented. Upon touching the screen while benching, while its at 40hz it stays at 40hz

TP.
[Galaxy S III Android Development] ZaneZam:
yeah and according to yank it calms down scaling also. that makes sense to me due to more frequent checks that are done with this setting

but i can't really talk about that stuff yet because i first i have to start my own tests *g*, but i trust Yank if he says that this will be the behaving then! :)
[Galaxy S III Android Development] JustArchi:
[MENTION=3279788]ZaneZam[/MENTION]

Oh, sorry then, I was sure that it's higher according to old 180000 :eek:

Pardon~!
[Galaxy S III Android Development] ZaneZam:
hey no problem man, wasn't sure either if that is right ;)
[Galaxy S III Android Development] Yank555:
180000 was the old value I took over from Zane's I think before starting to play arount with sampling rate ;)

JP.
[Galaxy S III Android Development] habylab:
Surely you mean "added possibility to enable hotplugging only at suspend", as I believe the hotplug sleep setting already does this.
[Galaxy S III Android Development] Yank555:
Hotplug sleep allows to set "up to how many cores may be used during screen off".

Hotplug disbale in sleep means, all cores are up, no hotplugging happens whenever the screen is off, just like what hotplug disable means in screen on, no hotplugging = all cores up all the time.

JP.
[Galaxy S III Android Development] ZaneZam:
hehe another one which is stumbling, but i admit it's quite confusing :)

nope it's exactly how i wrote in the changelog. with the hotplugging sleep setting u can only disable cores separately and hotplugging is still active. with the disable_hotplug tuneable u can disable hotplugging completely (=all cores online and the whole hotplugging routines in the governor will be passed) with the disable_hotplugging_sleep tuneable u will only get this at screen off. so thats for guys which want to have all cores online at sleep with no further hotplugging attempts from the governor but at the same time want a normal behaving with hotplugging at screen on.

EDIT: Yank was faster *g*, so now after that double explanation it should be quite clear :D
[Galaxy S III Android Development] tincmulc:
Does hotplug_sleep override disable_hotplug during screen off?

Or to be more specific having both these options set to 1, how many cores will be online during screen off? (if all other options are defaults, including disable_hotplug_sleep = 0)
[Galaxy S III Android Development] ZaneZam:
Nope will not overwrite. Hotplugging off tuneables are overwriting at screen on and off. And all cores will be online then as stated.
[Galaxy S III Android Development] tincmulc:
How about an option to disable hotplug only on screen on and keep the hotplug_sleep in effect? So you can effectively disable hotplugging - the governor will not make decisions about plugging cores in or out depending on load, but will force all cores online if the screen is on and force only 1 core online when the screen is off.
[Galaxy S III Android Development] Hbohd:
To my mind, it is possible right now :p
[Galaxy S III Android Development] DirkStorck:
Hi ZaneZam one thing I don't understand is why I would want to have cores online...specialy at screen off? Wouldn't it be more efficient in terms of battery live if only one core for example would be online when screen is off?

Thank you!
[Galaxy S III Android Development] Yank555:
It's not intended at saving battery, but it is one more option to tweak it to your liking.

Might help in stuff like listening to music via BT, or faster reaction when dialing via car kit and certainly use cases I can't think of ;)

It's there for you to use it, or not, as you prefer according to your goal.

JP.
[Galaxy S III Android Development] DirkStorck:
Ok. Thank you Yank555 :)
[Galaxy S III Android Development] ZaneZam:
that's right since version 0.7 this scenario is possible by just setting disable_hotplug to 1. when screen is off hotplugging will start and

the hotplug_sleep setting applies. ;)
[Galaxy S III Android Development] tincmulc:
These two statements are contradictory. Is this behavior changed since v0.7 and was you first reply regarding the old version? I thought it was clearly about the new version, because it included the new disable_hotplug_sleep tunable in it.
[Galaxy S III Android Development] ZaneZam:
yeah exactly JP. just one possibility more as i wrote in changelog some time ago

well fine it seems someone find it usefull now! :good: :)
[Galaxy S III Android Development] ZaneZam:
yeah u got me sorry was to fast with answering :o

forget my first statement it was for previous versions yes ;)

i had no time to test all the stuff a lot and honestly just found

out that this scenario works! ;)
[Galaxy S III Android Development] davtse:
Hey zanezam, quick question about 0.7.. Does setting hotplig up freq threshold to 1400mhz disable it?
[Galaxy S III Android Development] ZaneZam:
Quick answer : no :)

Long answer : if not plugged already because of any hotplug up threshold it would do it at 1400mhz then ;)
[Galaxy S III Android Development] davtse:
awesome.

on a side note,

I've used all your mooves, but I must say you broke the mold with 0.7. *insert expletive here*-ing awesome
[Galaxy S III Android Development] ZaneZam:
thank u very much man appreciate your words but not forgetting my co-dev's [MENTION=2033478]Yank555[/MENTION] considerable work which is even more fraking (yeah BSG rulez! *g*) awesome, at least for me :) very nice and productive cooperation going on here, and will go on in the future :good:
[Galaxy S III Android Development] davtse:
Yes, of course, my bad for missing out [MENTION=2033478]Yank555[/MENTION] !

Google/Samsung/android should totally make this an inbuilt governor!
[Galaxy S III Android Development] oae08:
Testing out [MENTION=2033478]Yank555[/MENTION] extreme battery profile implemented in temasek kernel bu [MENTION=5161352]JustArchi[/MENTION]

Thanks to all of you guys and zane!

Hope this new profile will give me more battery since pegasusq is always better for me battery wise but its not as smooth as zzmoove.
[Galaxy S III Android Development] AndroidGX:
Something looks weird, I just made my own kernel based from samsung update 11, and added zzmoove governor v0.7. Once selected via SetCPU, the first core (cpu0) always stuck at 1400 Mhz, no problem with other governors. Is this normal ?
[Galaxy S III Android Development] ZaneZam:
Definitely not, but interesting. U added nothing in addition to the source? Which compiler/flags did u use? Changing governor cures this problem or does it always stuck at 1400mhz when u change to zzmoove? This Infos would be highly appreciated because I'm trying to reproduce this bug which sometimes appears but unfortunately not on my phone with boeffla kernel!
[Galaxy S III Android Development] AndroidGX:
Thanks for your answer,

I just added boeffla sound compatibility aswell, nothing else for the moment.

I used arm-eabi-4.4.3 as toolchain, with stock flags (no errors when compiling) which did the job.

I tried to change governor to pegasusq for exemple from zzmoove and everything works well again, once returning to zzmoove : same problem.

Finally after rechecking, it seems that every steps are locked from 0 Mhz (offline) to 1400 Mhz when jumping, and always and only this step (no 800, neither 500, etc).

I upload you my kernel test so you can see this strange behaviour.

Just tested with pure stock XXEMG4 ".ko" files to replace (was using NeatROM stock one before) and same problem occurs :(

Btw, on my test kernel, phone calls are not working (no SIM pin unlock appears), no idea why, it's hard when you are not a dev like me :D but I will try to look into this :good: (*edit* : works well on XXEMG4+ roms and XXEMG4+ modems)
[Galaxy S III Android Development] AndroidGX:
Bringing more news : just tried to recompile my test kernel with version 0.4 of zzmoove (from Adam kernel) and it works now perfectly (scales, no more stuck at 1400, quickly back to 1 core at 200 Mhz and others offline, etc). So it looks like there is something weird in this v0.7. One thing I wanted to check is to get 0.7 from Googy Max kernel (which works well on his kernel), but unfortunately his github hasn't been updated since 3+ months so totally outdated :(

*edit* tried with zzmoove v0.6 and works well also!
[Galaxy S III Android Development] mehmet184:
hi [MENTION=3279788]ZaneZam[/MENTION]

i am using yank extreme batter profile.

which best battery saving scheduler ?

i am on N7100 CM10.1
[Galaxy S III Android Development] tommi.a:
ZZMoove Battery - Stick to core 0

Hi Zanezam,

just want to tell you that I did not observe the issue with Boeffla 3.0-beta10 which I used for 2.5days now before I switched to Boeffla 3.0 official a few minutes ago where I saw it again already.

Maybe a bug which appears only with a certain (shifted) memory address range for governor variables? Just an idea...

As Boeffla still uses ZZMoove 0.6 - already results regarding this unwished behaviour with 0.7?

Greetings,

Tommi
[Galaxy S III Android Development] Yank555:
Strange, I've been using the current scaling logic since the night I made the last changes to it, which was on 2013-07-24 for zzmoove 0.6a, when I added autodetect CPU freq. table sorting.

That part of the code has not changed in that regard since then I think...

JP.
[Galaxy S III Android Development] AndroidGX:
Very strange yup :(

Hmm, what I can do now is to test with zzmoove v0.6a (currently with 0.6), and report here. I will edit this message. Stay tuned! :good:
[Galaxy S III Android Development] ZaneZam:
thx guys for reporting!

and yes JP as we talked about multiple times indeed very strange! but i don't beleve it's related to the sclaing logic i more suspect hotplugging. i had that problem too ages ago on first versions of zzmoove. first i could fix that by temporary changing governor and now since several versions it bizarrely disappeared completely on my phone, no clue since which version exactly (i surely flashed 200+ testversions *g*). the last time i saw it was with a messed up test version (yeah happens sometimes *g*), i think i even reported it to you JP, do u remember ? :) i did something wired in hotplugging logic but fixed it instantly and didn't mind afterwards. can't remember what that was unfortunately

anyways, can someone who has that problem pls try to disable hotplugging for some time and see if that changes anything. and maybe can someone also try in addition to disable hotplugging during the freq stuck when it appears and see if that cures it?

looking forward to your reports, thx!
[Galaxy S III Android Development] AndroidGX:
As you guys know I'am definitely not a dev, but just an idea : could this be caused by toolchains we use to compile our kernels ? I'am using stock arm eabi 4.4.3 for mine.

Btw, about what I said for testing v0.6a, could someone please send me it ? will be pleased to test and report :good:

Maybe it would be a good idea to keep older zzmoove version aswell on your github for easier searchs, just a suggestion :cowboy:
[Galaxy S III Android Development] temasek:
Git keeps a history of file changes.

You can then grab that particular change.
[Galaxy S III Android Development] AndroidGX:
Damn, definitely need to learn how github works now :D many thanks :good:
[Galaxy S III Android Development] MIKEMON:
@ ZaneZam

Thanks for the great gov.0.7, use boeffla 3.1 beta1 and is absolutely super.
[Galaxy S III Android Development] AndroidGX:
As promised, I tried compiling my kernel with zzmoove 0.6a, and it's sadly the same problem as 0.7 :(

I'll stick with 0.6 for the moment.
[Galaxy S III Android Development] kozmikkick:
Curious if there is a know 3.4 kernel base for snapdragon version of this floating around? I searched but haven't had much luck.
[Galaxy S III Android Development] MIKEMON:
I do not know, I can confirm absolutely super work from,, Zanezam,, developer

Nothing is better for core
[Galaxy S III Android Development] AndroidGX:
I confirm it cannot be toolchain related as I just tested v0.7 with linaro gcc 4.7.4 and I have the same problem as before.
[Galaxy S III Android Development] Yank555:
Where can I have a look at your sources ? It's funny, it's the first and only report of such issues ??

Maybe having a look can make me figure out the problem...

JP.

Sent from my SlimBean 8 / Yank555.lu CM10.1 kernel v1.6f-beta6 (Linux 3.0.91) powered Galaxy S3 i9300
[Galaxy S III Android Development] AndroidGX:
Yes I have to agree that zzmoove governor v0.7 definitely does not like me ^^

But I'am very astonished to be still alone in this case yup.

As already talked in my kernel thread, I'am encountering difficulties to upload full source to github. *Blame my connection...*

Anyway take full update 11 samsung pack, just add it zzmoove v0.7 and see by yourself. It will be the same.

I will try soon to upload a small package which contains the only modified files of my kernel in the corresponding tree, in an archive. That's the only thing I can do. So you can replace them in update11 and see like if you were in my current source.
[Galaxy S III Android Development] Yank555:
Well, my Sammy kernel, just like all the other, are also just Sammy kernel dump based ?!

I don't see what could be specifically different compared to all other kernels, zzmoove 0.7 made it to most of the i9300 / i9305 kernels, and even on other platforms :confused:

I saw in your thread that you're having some issues with github upload, I suppose that will be sorted anytime soon, git (and related online repo services) is very powerfull, I couldn't live without it ;)

I'll wait for you to up your sources, and have a look then. Just drop me a PM, I might miss it else ;)

JP.
[Galaxy S III Android Development] STAticKY:
Maybe something upstream...

TP.
[Galaxy S III Android Development] AndroidGX:
Ok mate, with pleasure. I'll PM you as soon as it's ready :good:

'laters
[Galaxy S III Android Development] Yank555:
Nope, it's purely inside the zzmoove sources (one single .c file), not linked to anything from kernel.org since zzmoove is not in kernel.org nor Samsung at all, so no changes can come from there...

I just don't quite understand where it could come from.

JP.

Sent from my SlimBean 8 / Yank555.lu CM10.1 kernel v1.6f-beta6 (Linux 3.0.91) powered Galaxy S3 i9300
[Galaxy S III Android Development] habylab:
Does anything, by design or effect, improve battery life in 0.7 vs 0.6?

Sent from my maybe one day to be CM i9300. That day won't come unless the camera improves!
[Galaxy S III Android Development] andrewfung888:
I set the down_threshold_hotplug_freq to just 100M below the up_threshold freq, and found the cores stay online more often, Seems setting them to 0 is better. is it normal?
[Galaxy S III Android Development] JustArchi:
0.7 contains small but big in terms of battery changes based on my observations (and not only mine, [MENTION=2033478]Yank555[/MENTION] [MENTION=3279788]ZaneZam[/MENTION] :)) about hotplugging and cpu load caused by that. Point directly to changelog to read more.
[Galaxy S III Android Development] Yank555:
If you want cores to fire up 'later', use a rather high up threshold freq. and keep down close to it (maybe not as close as 100MHz).

This is what I use currently :

2013-08-21 00:24:26 : CPU governor set to zzmoove.
2013-08-21 00:24:26 : zzmoove - yank-battery profile :
2013-08-21 00:24:26 : zzmoove - sampling rate set to 75000.
2013-08-21 00:24:26 : zzmoove - sampling down factor set to 1.
2013-08-21 00:24:26 : zzmoove - up threshold set to 60.
2013-08-21 00:24:26 : zzmoove - down threshold set to 40.
2013-08-21 00:24:26 : zzmoove - ignore nice load set to 0.
2013-08-21 00:24:26 : zzmoove - frequency step set to 10.
2013-08-21 00:24:26 : zzmoove - smooth up set to 65.
2013-08-21 00:24:26 : zzmoove - up threshold hotplug1 set to 85.
2013-08-21 00:24:26 : zzmoove - up threshold hotplug2 set to 90.
2013-08-21 00:24:26 : zzmoove - up threshold hotplug3 set to 98.
2013-08-21 00:24:26 : zzmoove - up threshold hotplug1 freq. set to 700MHz.
2013-08-21 00:24:26 : zzmoove - up threshold hotplug2 freq. set to 1.0GHz.
2013-08-21 00:24:26 : zzmoove - up threshold hotplug3 freq. set to 1.2GHz.
2013-08-21 00:24:26 : zzmoove - down threshold hotplug1 set to 65.
2013-08-21 00:24:26 : zzmoove - down threshold hotplug2 set to 75.
2013-08-21 00:24:26 : zzmoove - down threshold hotplug3 set to 85.
2013-08-21 00:24:26 : zzmoove - down threshold hotplug1 freq. set to 600MHz.
2013-08-21 00:24:26 : zzmoove - down threshold hotplug2 freq. set to 800MHz.
2013-08-21 00:24:26 : zzmoove - down threshold hotplug3 freq. set to 1.0GHz.
2013-08-21 00:24:26 : zzmoove - hotplug block cycles set to 0.
2013-08-21 00:24:26 : zzmoove - sampling rate sleep multiplier set to 4.
2013-08-21 00:24:26 : zzmoove - up threshold sleep set to 85.
2013-08-21 00:24:26 : zzmoove - down threshold sleep set to 75.
2013-08-21 00:24:26 : zzmoove - CPU step for standby set to 1.
2013-08-21 00:24:26 : zzmoove - smooth up sleep set to 90.
2013-08-21 00:24:26 : zzmoove - hotplug sleep set to 1.
2013-08-21 00:24:26 : zzmoove - yank-battery profile applied.
2013-08-21 00:24:26 : zzmoove - CPU freq. max for standby set to 600MHz.
2013-08-21 00:24:26 : zzmoove - 1 step up/down fast scaling enabled.
2013-08-21 00:24:26 : zzmoove - fast scaling for standby disabled.
2013-08-21 00:24:26 : zzmoove - early demand enabled.
2013-08-21 00:24:26 : zzmoove - early demand threshold set to 50.

JP.

Sent from my SlimBean 8 / Yank555.lu CM10.1 kernel v1.6f-beta8 (Linux 3.0.91) powered Galaxy S3 i9300
[Galaxy S III Android Development] davtse:
Something I noticed but I'm not sure what exactly is going on,

on cm10.2, if I set 1400mhz(my max freq) as the freq to upthreshold, it does eventually utilise the core.

on sammy based roms, if I set the same settings, the core is not brought online at all.

I'm not sure which one is supposed to be the correct behaviour but personally I do prefer the first lol
[Galaxy S III Android Development] Yank555:
In pure theory, the first is correct, hotplugging should occur when threshold is reached.

JP.
[Galaxy S III Android Development] habylab:
Awesome, I read about them, and was just trying to have it a bit simpler put!
[Galaxy S III Android Development] Yank555:
Put simpler :

0.6 : hotplugging (starting / stopping cores) is only triggered by CPU load

0.7 : hotplugging is triggered by CPU load and / or current CPU frequency (depending on your settings)

So in essence, in 0.6 both freq. upscaling and hotplugging would potentially occur at the same time due to the same CPU load increase, which might be just excessive.

Now in 0.7 you can calm this down (hence the codename "

tamed

beast" ;)) as load will first trigger freq. scaling up, and once the freq. threshold is reached and if load is still there, hotplugging will occur as well. So you will delay hotplugging and first try to cope with the load by scaling up the currently running cores.

This will also avoid excessive hotplugging, since load = work / available power (higher freq. and more cores up = more power), going from 1 to 2 cores at the same freq. will instantly divide the load by half, potentially triggering downscaling and returning to 1 core, which might then again not be enough, triggering the opposite again and so on and so forth, so it'd be going up and down quite a lot until it stabilises (if the load is contstant of course, which it actually almost never is).

Of course it's important to set all those (old & new) tunables "wisely", like most of this kind of stuff ;)

Hope I could shed some light on this for you...

JP.
[Galaxy S III Android Development] habylab:
Thank you, that's excellent. I believe I have done so, with the settings more or less the same as what you posted here on this page.
[Galaxy S III Android Development] ZaneZam:
ZZMoove v0.7a little bugfix release

Hi Guys,

just pushed a bugfix version!

no big deal just a little glitch in the

new hotlpug tuneables.

enjoy and have a nice day! :)

ZZ
[Galaxy S III Android Development] fusionjack:
is it intended that the ENABLE_LEGACY_MODE gets enabled in 0.7a by default?

do i understand correctly that i shouldn't use legacy mode for device that has dual core only? (i9100 galaxy s2)

thanks. :)
[Galaxy S III Android Development] AndroidGX:
Coudn't resisted to give a try to v0.7a on my kernel, and still the same problem, damnit! :D

Anyway I sent my full source package to Yank555 via PM as promised, he will take a look at it soon :good:

Thanks Zane for your great governor anyway, still stick with v0.6 by waiting :cool:
[Galaxy S III Android Development] ZaneZam:
Nope as stated in the changelog I just forgot to disable it (sorry again! *g*) and yes legacy mode can only handle 4 cores and max scaling of 1800mhz as there is no flexibility included in this mode like it was in versions 0.4 and lower ;) so there would be some modifications necessary to make it run on 2 core Systems.