Develop Bugs

[LIST] My "CPU tuner" recommandations

So many people on these forums ask about the best CPU tuner profiles to set on their Desire Z that I thought i'll make a thread here to refer to.
Note: I've been using and experimenting with CPU tuner for 5 months now, and i faced all the known issues before i came to these settings. Also, I have been listening to everyone's remarks. So i think it works the best. Now don't blame me if your phone turns into a fireball after you applied these settings (well, it's rare though...).
If you don't have it, you can download "cpu tuner" from the market. I'm using the 2.1.2 version.
Tips first:
You need a ROOTED phone to operate CPU tuner properly.
You'd better get a good kernel which allows a wide frequency range and the basic governors.
Read the help that's included with the program (Menu -> Help).
Unless you really need it, do not run the Check System Capabilities.
Not all phones can handle high CPU speed, just experiment. It's mostly a matter of luck.
The purpose of CPU tuner is to allow you to save battery life while getting the best of your phone when you need it. It allows you to change two important things in your phone, defined in "profiles":
Governor: the "brain" that decides when to lower or raise frequency, depending on what you do
Frequencies: the min/max frequencies the governor can choose between.
These profiles are applied depending on your battery status. Battery remaining life is the variable for "triggers", which fire the profile changes.
Usually, you want your phone to give you the best of its power, as long as possible, so i defined only two triggers: one for "Battery is fine, thanks" and one for "Battery is at agony, stop it now!" (below 20%).
Here we go:
Before you start, go to settings, and turn profiles off.
Virtual governors
In the virtual governors tab, we define the 3 ones we need:
VG: Screen Off: "interactive" governor
VG: Normal: "ondemand" governor, with threshold up at 95
VG: Powersave: "conservative" governor with thresholds up at 97 and down at 90
Profiles
Now, let's set 3 profiles for the different cases:
Screen off: Governor "VG: Screen Off", frequencies 691-806Mhz
Normal: Governor "VG: Normal", frequencies 806-1210Mhz
Powersave: Governor "VG: Powersave", frequencies 599-806Mhz
In all cases, let all services on "unchanged" unless you want some specific behavior.
Triggers
Ok, now that we have everything we need, let's say what to trigger, and when:
Let 2 triggers:
1.Battery Good
Level: 100
On Battery: Normal
Screen Locked: Screen off
On Power: Normal
(optional but advised) Call in progress: Normal
(optional) Battery hot: Powersave
2.Battery Low
Level: 20
On Battery: Powersave
Screen Locked: Screen off
On Power: Normal
(optional but advised) Call in progress: Normal (this is important for call stability)
(optional) Battery hot: Powersave
You're ready to go now! But we can check some options if you'd like to:
User interface:
Be sure not to enable the Calculate power usage.
Also, here you can remove the (annoying) notifications, just let the status bar icon.
Profiles and triggers
Remember this optional "Call in progress" option? Here you cna enable it.
Service Switches
It's a good idea to check the "Manual service change" box, not to be bothered when you manually turn some connection on and it goes because you run low on battery.
Buy me a beer
Honestly, you can buy him two ones...
And to thank me, just click on the "Thank" button on this forum
When you're done, turn profiles on again.
Tell me how you do with these settings!

hi. i have a desire z running virtuous 1.0.2 with advanced kernel 2.2.0.
i follow you settings and after 2 days of use i've got the screen wake up issue on incoming call.
there's something i missed?

Are you using the Call in progress settingon every trigger ?

yes, i've set both to the normal profile as in your guide.
now i've disabled the option in settings and hope that works...

Yeah, try without this setting.
If you keep having the issue, try to raise the min frequency of screenoff.

ok! now i've found a good config!
i've increased screen off min freq to 691 and enabled again the call in progress option.
if the call in progress option is disable, the phone locks during a call and the proximity sensor won't work anymore (for example if you wish to end a call).
i hope this will help some other users!
thank you for help and guide!

Please give again a feedback in some days, and then i'll add your findings in the 1st post.
Thanks

after 3 days of usage i can say that this is the right config.
no more wake up / in call locking / end call wake issues!

Alright and you're using interactive for screenoff, right? I'll edit my first post

You guys minimum frequencies look a bit too high, I have mine set to 245 minimum and it gets me much better battery life. I would also suggest using SetCpu (it's free for registered xda members). Just a thought though.
Edit: CPUTuner can also cause issues with any rom that isn't CM7; and also on CM7 under the right circumstances.
Sent from my HTC Vision using XDA App

@Ninj: yes, that's right!
@PaganAng3l: any suggestion is welcome! why don't you post an example of your settings?

Great little write up. I look forward to setting it up after work!

My profiles in SetCPU are pretty basic, but I get great preformance and around 30 hours of battery with moderate/heavy usage. Here are my profiles:
Temp > 42.0 C = 806 max / 245 min
Governor = Conservative Priority = 95
Charging = 1209 max / 245 min
Governor = On Demand Priority = 90
Battery < 25% = 806 max / 245 min
Governor = Powersave Priority = 85
Battery < 50% = 1017 max / 245 min
Governor = On Demand Priority = 80
Battery < 101% = 1209 max / 245 min
Governor = On Demand Priority = 75
That's it! I don't personally experience "wake lag" or a blank screen with incoming calls with these settings, but if you do simply bump up your minimum frequencies to above 300 mhz.
Sent from my HTC Vision using XDA App

PaganAng3l said:
[...]
Battery < 25% = 806 max / 245 min
Governor = Powersave Priority = 85
[...]
Click to expand...
Click to collapse
powersave? i can't find that governor...
i've set it on conservative.
i'm trying your settings but i still have the wake up issue.
now i'm going create a screen off profile.
if even this won't help, i'll try to increase the minimum freq to 300mhz.
however i have to say that this setup really help to increase battery life.
after 2 day of moderate usage i'm still at 66%!!

eFFeRaTuM said:
powersave? i can't find that governor...
i've set it on conservative.
i'm trying your settings but i still have the wake up issue.
now i'm going create a screen off profile.
if even this won't help, i'll try to increase the minimum freq to 300mhz.
however i have to say that this setup really help to increase battery life.
after 2 day of moderate usage i'm still at 66%!!
Click to expand...
Click to collapse
Your kernel may not support a "powersave" governor. I just flashed pershoot's kernel and I no longer have it. Try bringing all of your max frequencies to 1171mhz or lower. This helps solve the waking issue too.
Edit: having a screen off profile caused me no end of trouble. It may not be an issue for you but I thought I would share.
Sent from my shiny metal G2 w/ meXdroid V2

PaganAng3l said:
My profiles in SetCPU are pretty basic, but I get great preformance and around 30 hours of battery with moderate/heavy usage. Here are my profiles:
Temp > 42.0 C = 806 max / 245 min
Governor = Conservative Priority = 95
Charging = 1209 max / 245 min
Governor = On Demand Priority = 90
Battery < 25% = 806 max / 245 min
Governor = Powersave Priority = 85
Battery < 50% = 1017 max / 245 min
Governor = On Demand Priority = 80
Battery < 101% = 1209 max / 245 min
Governor = On Demand Priority = 75
That's it! I don't personally experience "wake lag" or a blank screen with incoming calls with these settings, but if you do simply bump up your minimum frequencies to above 300 mhz.
Sent from my HTC Vision using XDA App
Click to expand...
Click to collapse
Going to give this a try. Hope I see an increase in battery life.

Why not just get the pyromod kernal and watch it do its magic?? but cool find
Sent from my HTC G2 PyroMod 2.0

Is it normal for CPU Tuner to give a "has been granted Superuser permission" message everytime the phone comes back from standby?
Sent from my T-Mobile G2 using XDA App

jankypr said:
Is it normal for CPU Tuner to give a "has been granted Superuser permission" message everytime the phone comes back from standby?
Sent from my T-Mobile G2 using XDA App
Click to expand...
Click to collapse
Yes that is normal. However since you're an xda member you can get the app SetCPU for free and I believe it's superior to cpu tuner. Just search the forum for "setcpu download" and it should turn up.
Sent from my shiny G2 w/ meXdroid V3

[PATCH] ondemand deep cpuidle detection

[EDIT: Feel free to jump to comment #9]
[EDIT2: last version of the patch to apply to the kernel is in comment #25, applying the patch to the kernel source is all you need to test]
[EDIT3: changed name to deep cpuidle, I figured "deep sleep" is usually meant as "suspend-to-ram" and this has nothing to do with suspend, suspend is entered at fixed SLEEP_FREQ and the cpu frequency is irrelevant during suspend because CPU power is cut-off]
On my galaxy S I've been monitoring my cpufreq stats and the stats/total_trans keeps increasing every second or so with default cpufreq values and ondemand governor, when the screen is off and the cellphone is idle. This means the cpu spends some time spent at the high frequency even if the cellphone is idle and screen off.
I noticed if I increase the ondemand/sampling_rate from the default 40000 (on i9000) to 80000 the total_trans go down to one every 10 or 20 sec. But I want to decrease the sampling_rate to 20000 so it takes only 20msec to jump to 1ghz. 40msec (the default) is too much. 40msec means 25hz but the first image frame would get lost because it'd be rendered at 100mhz instead of 1ghz. at 20msec of sampling_rate the frequency is 50hz so if the first frame is lost we're still down to 25hz which is less noticeable to the eye. I think 20000 is the max that sampling_rate should be set for decent responsiveness.
However if I drop the sampling_rate to 20000 as I prefer, when the screen is off the stats/total_trans increases even faster at a couple per second, than with the default of 40000, so sampling_rate 20000 is ideal for responsiveness but it will waste power when the screen is off.
So my solution is to force the max frequency allowed by the cpu policy to the min frequency when the screen is off. After that I can easily set sampling_rate to 20000 and io_is_busy to 1, by adding this the init.rc of the initramfs. I prefer io_is_busy to be 1, because 100mhz is really slow and the I/O will take some significant percentage of CPU too if set at 100mhz, and especially because after the I/O is complete I'll avoid losing one frame.
write /sys/devices/system/cpu/cpufreq/ondemand/io_is_busy 1
write /sys/devices/system/cpu/cpufreq/ondemand/sampling_rate 20000
I'm also testing with up_threshold 80 but I'm not sure if it is better or worse... need to do more tests on the below one, could be a bad idea.
write /sys/devices/system/cpu/cpufreq/ondemand/up_threshold 80
This way I can tune the ondemand as aggressive as I need without sacrificing the powersaving when the screen is off. In fact it should use less power now when the screen is off than before.
The patch is for the ginger update2 kernel, running 2.3.4 XXJVR using the kernel modules of XXJVS (I rolled back the userland and initramfs to JVR because JVS disconnects wifi for me).
I've noticed there's a smartass2 governor which I didn't try, it may work better than this, but I tend to trust the ondemand governor to be the best for responsiveness, and my approach is much simpler than the smartass2 governor, I'm not in a mood of doing beta testing or risking instability for a feature that can be achieved so simply. If ondemand isn't aggressive enough I prefer ondemand to be improved to be more aggressive. Ondemand is what runs on most laptops/workstations so we can't afford it not to be as fast as it can.... The problem is not specific to cellphones. And when screen is off there is not point to ever increase the frequency over 100mhz on i9000 (and unfortunately it happens and it's not fair to pretend some background service to call usleep(1) just to avoid the frequency jump).
Note, you may want to remove the two printk from the patch, they shouldn't flood but they're only for debug...

I think you need to put a [MOD] in your title.

First, thx you for sharing your work !
Your .zip patch the existant ondemand governor, or it is adding a new governor which can be selected via app like voltage control & such ?

Anyone wanna try this out and share what it does actually? All thoaellse reading above are too technical for most of us I guess. I'd love to try but I'm on JVS now and you said it is for JVR.
Thanks for the share by the way...
Sent from my GT-I9000 using Tapatalk

cnn888 said:
Anyone wanna try this out and share what it does actually? All thoaellse reading above are too technical for most of us I guess. I'd love to try but I'm on JVS now and you said it is for JVR.
Thanks for the share by the way...
Sent from my GT-I9000 using Tapatalk
Click to expand...
Click to collapse
Well I'm running the JVS kernel on top of JVR userland+initramfs. It'll run perfectly on JVS but I only posted the source and it'll work for both
I'm also a bit annoyed often I see mods and tweaks and I try to search the source and it's not so easy to find it. I'd recommend people to post more source and less binaries.
You just need to ask one kernel builder that ships with the ondemand governor to apply my patch, add those 3 lines to the initramfs/init.rc file and rebuild and it'll work for JVS too. Theoretically it will drain less when the screen is off and it'll be a bit more responsive when screen is on.
---------- Post added at 07:42 PM ---------- Previous post was at 07:36 PM ----------
Rootax said:
First, thx you for sharing your work !
Your .zip patch the existant ondemand governor, or it is adding a new governor which can be selected via app like voltage control & such ?
Click to expand...
Click to collapse
The whole point of this approach is not having to change governor and to share the ondemand governor which must provide max performance and max responsiveness on laptop and desktops so I don't see the point of creating a new governor when the screen is on, considering the requirements are the same.
I thought lowering voltage was considered risky, I don't want to change voltage but if you want to change the voltage I think the best place to do it is still my two handlers I added in the patch, no new governor required, I doubt you want to change voltage when the screen is on, and when the screen is off I guess you want always the lowest voltage and lowest freq like me.
A new governor is not needed in short, just a few liner patch to set the max freq at the lowest when screen is off is my preference, especially because it's so much simpler

right... and umm... suppose that i want to apply this mod, how do we apply this patch of yours?
i'm sorry but am not really a linux frenzy...

cnn888 said:
right... and umm... suppose that i want to apply this mod, how do we apply this patch of yours?
i'm sorry but am not really a linux frenzy...
Click to expand...
Click to collapse
re-build kernel source
great work newmail !
another (non-invasive) approach
would be to use a bare screenstate_scaling (well - not really scaling)
init script and limit the max frequency via that + set those values

zacharias.maladroit said:
re-build kernel source
great work newmail !
another (non-invasive) approach
would be to use a bare screenstate_scaling (well - not really scaling)
init script and limit the max frequency via that + set those values
Click to expand...
Click to collapse
Thanks.
I figured with csipsimple with the proximity sensor, 100mhz are not enough.... so I'm now decreasing the max frequency to 800mhz when screen is off, and I'm keeping the default sampling_rate to 10000 msec (setting transition_latency to 10000, equivalent to writing 10000 into ondemand/sampling_rate).
I also changed the code a bit to call all notifiers when the max frequency changes from 1ghz to 800mhz.
Now I did quite a bit more tests and something's going wrong when screen goes off in cpufreq. The cpu is idle, but ondemand raises the frequency more than if the screen is on. That is probably why the cpu isn't very idle when the sampling_rate is reduced go give more responsiveness. If I change get_cpu_idle_time_us to return -1 unconditionally, the trans_total are greatly reduced with screen is off and the ondemand stays at the low frequency when screen is off with sampling_rate 10000 too.
I also tried to measure the cost of a frequency switch (including the overhead caused by ondemand sampling at 1khz) and it seems of the order of 38usec.
I'm wondering if there's some bug in the get_cpu_idle_time_us that is causing the jitters in the ondemand governor when screen goes off.

I found the problem with the ondemand governor while in earlysuspend suspend mode. The problem is that the cpu starts to go in deep sleep, so a sampling_rate of 10000 is applied only once in a while, the real sampling_rate becomes 1second or more.
So when that happens the CPU goes in deel sleep all the time and ondemand tends to stay stuck at the max frequency all the time, by mistake, despite the load is near 0%.
After deep sleep when a wakeup happens we return to the 10000usec sampling rate. ondemand sees activity after the deep sleep wakeup but those wakeups "loads" must be adjusted down if the previous wall_time delta was huge and the current one is tiny. We're too close to deep sleep to ramp up cpu freq.
So my solution is to tweak the ondemand to scale down the "load" according to the decrease in the wall_time delta ratio (deep_sleep_ratio variable).
When screen is on, or during a call or during playback with screen off, the deep_sleep_ratio is 1, so the ondemand behaves as aggressive as always. But the deep_sleep_ratio ramp up when the phone is idle and the idle deep sleep states starts. With this tweak I can use the ondemand governor with the default values and the sampling rate set to 10000 (for max responsiveness) and the cpu freq will stay down to 100mhz with no jitter when the screen is off and the load is near 0% (instead of staying close to 1ghz most of the time with the 10000 sampling rate setting, 40000 of the JVS tends to hide it but it still jitters a lot and it hurts interactivity to be unable to set it below 40000).
In my first post I already noticed this jittering of the ondemand governor with the screen off. And I thought to solve it by lowering the freq to min with the screen off (which screwed csipsimple). I also noticed that a sampling_rate of the order of 100000 would decrease the jittering and with 10000 the cpu freq would be set at the maximum all the time. But the real problem was the ondemand comparing apples to oranges with the deep sleep state, and this explains why the jittering wasn't as bad with the screen on, as opposed to the badness with the screen off and the CPU going in deep sleep at high freq most of the time.
So this heuristic I wrote solves the problem, and I also disabled all those dvfs magics in cpufreq that prevented to use the 100hz frequency most of the time. It works fine for me with screen on, and now with screen off (proximity sensors) voip works perfectly too (I also verified deep_sleep_ratio is 1 during calls with proximity sensor activated). Any real activity will prevent the deep sleeps so it's perfectly ok to ignore the high loads measured just after returning from the deep sleep.
Anyway feel free to experiment. I also wrote another patch to switch the governor to performance automatically when screen goes on, and return to ondemand (with deep sleep detection) when screen goes off. But I think this heuristic is better and ondemand won't be exactly as fast as "performance" but especially at 10000 sampling_rate the difference should not be noticeable. And so I prefer to save a tiny bit of power by using ondemand all the time. Plus it proofs the new logic is good if it works for both scenarios.
I still decrease the max cpu frequency when screen is off to 800mhz (not anymore to 100mhz after I found it screws the voip and playback with screen off). ondemand will immediately jump to max the moment the threshold is exceeded (default threshold is 95% of not idle time). So this helps because all csimpsimple/skype/musicplayer background non-interactive workloads that may run with the screen is off and this will avoid to ever reach 1ghz which isn't needed for any of those background apps. 1ghz returns when screen goes on again.
In addition to this patch you can also consider adding these two lines to init.rc, but they're just to tune it a bit more aggressively. In the end I couldn't measure any difference from either one (default is 0 for io_is_busy, and 95 for up_threshold) so I'm using the default values and I didn't add the below to my currently running kernel. Probably you can ignore this and only apply the patch to the kernel.
write /sys/devices/system/cpu/cpufreq/ondemand/io_is_busy 1
write /sys/devices/system/cpu/cpufreq/ondemand/up_threshold 80
I recall having read of some tweakded ondemand governor in some rom, but there was no link to source... again I recommend folks to post link to source whenever a new cooked rom is published.
Considering this is closer to a bugfix, if this is confirmed to work by others I can try push the deep_sleep_ratio as a core feature in the kernel, maybe under some better name, to enable in sysfs so in future releases changing init.rc would be enough. It may be useful to other than arm as this is a common problem of what happens after the cpuidle governor enter deep sleep and sleeps more than the sampling_rate.
You can use this to monitor the effect before/after.
adb shell 'cd /sys/devices/system/cpu/cpu0/cpufreq; while :; do cat stats/*; sleep 1; done'
With the patch applied (which also sets sampling_rate at 10000, your default currently is 40000) you will get this when screen is off.
3384
1000000 11256
800000 21625
400000 1642
200000 6266
100000 469564
3384
1000000 11256
800000 21625
400000 1642
200000 6266
100000 469669
3384
1000000 11256
800000 21625
400000 1642
200000 6266
100000 469774
3384
1000000 11256
800000 21625
400000 1642
200000 6266
100000 469888
3384
And this with screen on (without touching
3461
1000000 11316
800000 22619
400000 2067
200000 6290
100000 477547
3461
1000000 11316
800000 22619
400000 2067
200000 6290
100000 477652
3461
1000000 11316
800000 22619
400000 2067
200000 6290
100000 477758
3461
1000000 11316
800000 22619
400000 2067
200000 6290
100000 477864
3461
1000000 11324
800000 22619
400000 2067
200000 6297
100000 477956
3464
There is some seldom jitter still but nothing significant anymore (and with sampling_rate set to 10000, it wasn't just a jittering problem but it was at max freq all the time). Some minor jittering like above is just unavoidable if some userland run a bit longer, and at 100mhz it doesn't take much CPU load to run longer.
I also measured the raw performance by calculating PI and it's within the measurement range error if compared to performance governor. quadrant just fine too unchanged over 1600 at the 3rd run, so I'm optimistic it's not degrading perf.

cnn888 said:
right... and umm... suppose that i want to apply this mod, how do we apply this patch of yours?
i'm sorry but am not really a linux frenzy...
Click to expand...
Click to collapse
I could upload a .tar file to flash in odin somewhere... but I worry about the redistribution of a zImage with an initramfs including those annoying binary modules that aren't GPLv2 (or we would have the source of those too) and I can't easily get rid of.

Dividing the load by deep_sleep_ratio was too aggressive. I noticed some app was more laggy than with "performance" governor. The better approach to the long deep sleeps is to ignore jitters until the wall_time_delta converges. I added comments on the reason why this is better, and it seems also better to ignore time jitters in both directions (so also to ignore measurement of long wall_time when the wall_time_delta average is short, with screen on). I attached an update, it still avoids the jittering with the screen off and phone idle, and it works better with the phone on.
With this one phone sits at 100mhz with screen off (freq range with screen off 100mhz-800mhz), works fine when doing voip calls with proximity sensor as before. With screen on the freq range is now 200mhz-1ghz, considering that without the patch the phone may never reach 100mhz even with screen off, it is most certainly not going to make a difference and 100mhz is way too slow and we've to run at least 10msec at 100mhz before we can ramp up the freq. So this will double speedup those first 10msec compared to the prev version. The jittering with screen off completely goes away and the phone stays at 200mhz fixed if you disable the rotation sensors, otherwise there are 2 jitters from 200mhz to 1ghz and back per second, which is certainly fine.
I've been using for a while and I'm pretty happy and should work better than the previous version. That app were I noticed an higher lag with previous version, now seem to be as responsive as performance or at least I can't see a difference anymore.
If you test it let me know and please check when screen is off and phone not awake, if the battery is lasting longer or not. By looking the chart I attached (running the sleep2 version in this post) it seems my battery went down 2/3% in 6 hours with this. Frankly I don't remember if it was as good before... all I know for sure is that what happened before with ondemand didn't make much sense: a proper governor allowed to use a range from 100-800mhz must keep the cpu at 100mhz when screen is off and phone is idle, and with the deep sleep detection fix, ondemand finally behaves well, and it works fine with voip with screen off, it doesn't require to rump up the min freq from 100mhz to 200mhz with screen off, and it seems more responsive than before thanks to the 4 times more frequent sampling rate (and maybe also thanks to ignoring the long deep sleep cycles during interactive behavior but that I'm not entirely sure if it helped but it still looks good idea to ignore the infrequent wall_time_delta jitters). It's also likely that the cpu goes into very long deep sleep shutting down the cpu harder and maybe the freq it enters those states don't matter, but at least this should help if you play music in the background with the screen off, it manages to do that now at 100hz without skips.

It's certainly refreshing to see good research being done in a consistent manner. Keep up the good work

pikachu01 said:
It's certainly refreshing to see good research being done in a consistent manner. Keep up the good work
Click to expand...
Click to collapse
Thanks well it all started with my phone being 80% dischared for two mornings in a row and that annoyed me enough to look into this. I was pretty certain it wasn't a kernel problem (I think it was the broken update of the facebook app that has "keep phone awake" privilege and is buggy, I uninstalled it since then) but that still made me look into this... and what I found looking at the cpufreq stats with screen off wasn't too pretty, it just become utterly ugly if I decrease the sampling_rate to 10000, and so I spent the weekend trying to fix it. In any case I'm unlikely to post further updates until next weekend .
Another possible way to fix this would have been to have the cpuidle governors interacting with the cpufreq governors through some notifier call... but adding a small heuristic to ondemand to detect the wall_time_delta jitters was certainly simpler.

newmail said:
Thanks well it all started with my phone being 80% dischared for two mornings in a row and that annoyed me enough to look into this. I was pretty certain it wasn't a kernel problem (I think it was the broken update of the facebook app that has "keep phone awake" privilege and is buggy, I uninstalled it since then) but that still made me look into this... and what I found looking at the cpufreq stats with screen off wasn't too pretty, it just become utterly ugly if I decrease the sampling_rate to 10000, and so I spent the weekend trying to fix it. In any case I'm unlikely to post further updates until next weekend .
Another possible way to fix this would have been to have the cpuidle governors interacting with the cpufreq governors through some notifier call... but adding a small heuristic to ondemand to detect the wall_time_delta jitters was certainly simpler.
Click to expand...
Click to collapse
well, I don't know how motivated or how much time you want to spend in investigating this
but if want to dedicate some more time
make sure you also take a look how ondemandx works
(cpufreq_ondemandx.c in my repo)

zacharias.maladroit said:
well, I don't know how motivated or how much time you want to spend in investigating this
but if want to dedicate some more time
make sure you also take a look how ondemandx works
(cpufreq_ondemandx.c in my repo)
Click to expand...
Click to collapse
Thanks for the pointer! Appreciated . I won't have much time to look into this until the next weekend (I'll look into it ASAP , but with the last version I posted in comment #11 (ondemand-deep-sleep2.patch) things are going absolutely great. In fact it works much better with skype than the stock unpatched kernel: when I iconize skype during a call it won't degrade the audio anymore. I'm sure it degraded audio for a little if I iconized skype and started another app during a call. I guess it's the faster sampling rate, or maybe the fact I now ignore the long idle times if the average wall_time is short. Both are good.
The sampling_rate not being constant with long cpuidle times that disregard software timers, really requires this fix to the ondemand to perform great. So I'm super happy about this change so far. 100-800/200-1000mhz also works great. And this change won't have any effect on laptops/workstations where the timers should fire as expected. (I also tried 100-400/400-1000 for a while but there's no point it seems, 100-800/200-1000 is enough so I'm back to the exact values in the last patch I posted)
I doubt it's worth to stop the sampling like interactive governor does while cpu is idle, considering cpuidle will disregard the timers so there's no risk to wakeup too early because of a timer it seems.... I think this changes will improve ondemand in general and it is required fix for these phones IMHO.
The fact background apps like music player with screen off now run 95% of the time at 100mhz also looks great. I didn't have any sign of instability, and I run a lot of load on it (though only for the last few days...). I sent my patch to some samsung engineer who added the SLEEP_FREQ to the cpufreq upstream code (to enter suspend to ram at 800mhz which I didn't alter, that sure is fine change considering the cpu is cut off the power during suspend to ram, it'll speedup suspend to ram too in addition to not crashing phone as described in the patch . In my patch I only handle the frequency changes right when cpuidle runs for long and I doubt the cpu is cut off the power for only 60msec or 500msec when screen is off, that's too fast to cut the power completely I guess so I think it's worth it. And if it doesn't help to save power when idle, for it sure won't hurt either and the statistics now look sane and this change should help while using the phone too by allowing to lower the sampling_rate and avoiding interactive usage to be fooled by long cpuidle samplings started at high freq that decrease the freq just before the real loads come in and idle is exited (ignoring those long wall_times during interactive usage is also good and should save power too as the load will complete faster and cpu will be allowed to spend more time in idle at low freq then).

Deep Sleep
Hi, you said that you first came to this topic because some app was keeping your CPU from deep sleep, probably FB app. This night I also experienced that the phone did not go into deep sleep, it was awake all the time according the battery status. So is there a way to check, which app causes this behaviour?
See attachment for a screenshot.

newmail, against what kernel base does your patch apply ?
samsung kernel sources JVB & JVH (1st release + 1st update) ?

zacharias.maladroit said:
newmail, against what kernel base does your patch apply ?
samsung kernel sources JVB & JVH (1st release + 1st update) ?
Click to expand...
Click to collapse
Thought you were on time-out??

dachau said:
Thought you were on time-out??
Click to expand...
Click to collapse
This is his time out, wait till you see him on his kernel dedication time.
^^
Sent from my GT-I9000 using XDA Premium App

newmail said:
I could upload a .tar file to flash in odin somewhere... but I worry about the redistribution of a zImage with an initramfs including those annoying binary modules that aren't GPLv2 (or we would have the source of those too) and I can't easily get rid of.
Click to expand...
Click to collapse
Newmail, first of all your analysis + the mod for governor was awesome !
basically actually not a dev and i can't patch my kernel myself (hmm.a noob kinds when it comes to kernel stuff )
i'm wondering how would be your patch's results vs Smartassv2's coz your patch includes the stuff directly in Ondemand Governor that's a perfect approach making it more effective .
So, please could you prepare a CWM flashable if possible on behalf of those GPLv2 (idk what are those btw ) or a step by step procedure to perform the FIX .. ?
Thankyou again for your approach on CPU freq tweak !!

[INFO/DISCUSSION] STweaks Guide

*I got this complete set of STweaks config from Verizon Note 2 section and it works well with GN-N7100/N7105*
Alright, below this, I will include an almost full guide to setting up STweaks (for those who do not want to use the provided profiles)
The CPU section contains the frequencies and voltages that you want to run at.
200mHz is the minimum speed, 1800mHz is the maximum speed. You can change these to affect your overall performance or battery life. Mine is currently set to 200mHz minimum, 1800mHz maximum. I have seen no hit on battery life at all (might be miniscule.)
Now for the voltages.. Each and every person will have a different set of voltages, as every CPU will be a little bit different. You can manually set your frequency to a certain level, use a CPU stress testing app (stability test) and drop the voltage by SMALL increments until you start to lose stability (system crashes, app force closes, etc.) I usually go UP one voltage step over the borderline stable voltage. I will post my voltages, but take caution, as my voltages are set pretty low compared to stock values on the kernel.
1800mHz - set to 1200000 uV or 1.2 volts.
1704mHz - set to 1175000 uV or 1.175 volts.
1600mHz - set to 1112500 uV or 1.1125 volts.
1500mHz - set to 1100000 uV or 1.1 volts.
1400mHz - set to 1062500 uV or 1.0625 volts.
1300mHz - set to 1025000 uV or 1.025 volts.
1200mHz - set to 1000000 uV or 1 volt.
1100mHz - set to 975000 uV or 0.975 volts.
1000mHz - set to 962500 uV or 0.9625 volts.
900mHz - set to 937500 uV or 0.9375 volts.
800mHz - set to 912500 uV or 0.9125 volts.
700mHz - set to 887500 uV or 0.8875 volts.
600mHz - set to 862500 uV or 0.8625 volts.
500mHz - set to 837500 uV or 0.8375 volts.
400mHz - set to 812500 uV or 0.8125 volts.
300mHz - set to 800000 uV or 0.8 volts.
200mHz - set to 787500 uV or 0.7875 volts. * BE CAREFUL WITH THIS ONE, it can cause your device to lock up when the screen is off, and need a battery pull if the voltage is too low.
CPU Scaling Section - this controls how your device will turn up the speed when it needs to.
Governor - This contols how the device will respond overall (power management, sleep, etc.) I will keep mine set to the Pegasusq governor unless I am running a benchmark, in that case, use perfomance (which locks the device to full speed and all 4 cores online)
Sampling Rate - how often the device will 'think' about changing the CPU speed. I have mine set to 15000 uS (15 milliseconds) so it is more responsive.
Sampling Down Factor - This enables you to create 'lag' when the device is at full speed, so it doesn't jump down frequencies when you don't want it to. I leave mine at default 1 sample, because I see no need for this.
Up Threshold - When a core hits this % utilization at a set frequency, then it will scale up to the next frequency. I have mine set to 96%, so the device will scale up slower and more reliably (keep in mind it makes this decision every 15 milliseconds.)
Down Differential - When the device scales down, (drops frequency) it must get below this % utilization to scale down ( UP THRESHOLD minus DOWN DIFFERENTIAL ) I have mine set to 5%, so it drops frequency at or below 91% utilization.
Frequency for Responsiveness - This helps keep the device smooth at lower frequency, and when the frequency is below the set spot, it will use a DIFFERENT up threshold so the device scales up faster and doesn't lag. My frequency setting is 500mHz, and the up threshold for it is set at 70%.
Frequency for Fast Down - this sets the frequency at which the device can use aggressive down scaling, much like the opposite of frequency for responsiveness. I have mine set to 1400mHz, and the up threshold is set to 98%, so the device only scales up if it really needs to.
Frequency Step - This applies to the Fast Down setting, and whenever the device gets above 98% utilization, then it will increase the frequency by a SET percentage of the maximum frequency. So if you set 10%, and are have 1800mHz max, it will increase to the closest step that adds 180mHz. I have mine set to 6%, so it increases by 108mHz.
The up threshold and frequency step decrease confuse me for this, but I have the up threshold set to 2%, and the frequency step set to 3%.
I didn't touch the flexrate settings, as everything else should control this area.
CPU Hotplug - This section will control how the device turns its cores on and off.
CPU Up Rate - How many samples you want to take until a core decides to turn on. (Sampling rate times your setting) I have mine set to 12, so if the conditions are correct, it takes 180 milliseconds to turn a core on.
CPU Down Rate - How many samples you want to take until a core decides to turn off. (Same thing as CPU up rate) Mine is set to 10, so it takes 150 milliseconds to turn off a core if it isn't being used.
Core Upbring Count - How many cores you want to bring online when the conditions are right. Mine is set to 1, I'm sure more will increase performance and hurt battery life.
Configuration Overrides - These can set you device to always have a certain amount of cores online, I don't use them (leave at 0.)
Hotplug Conditionals - These perameters are set to control when the cores turn on and off. Below are MY values
Hotplug 1 Core to ONLINE (make 2 cores online) - 600mHz
Hotplug 2 Cores to OFFLINE (make 1 core online) - 500mHz
Hotplug 2 Cores to ONLINE (make 3 cores online) - 700mHz
Hotplug 3 Cores to OFFLINE (make 2 cores online) - 600mHz
Hotplug 3 Cores to ONLINE (make 4 cores online) - 800mHz
Hotplug 4 Cores to OFFLINE (make 3 cores online) - 700mHz
The rest of this section, I left at DEFAULT values, because I did not understand them.
GPU - This section controls the frequencies and voltages of your GPU.
Maximum Frequency - How high you want your GPU to clock to, mine is set to 733mHz.
Minimum Frequency - How low you want your GPU to clock to, mine is set to 108mHz.
Up Threshold - Like the CPU setting, the percentage of utilization you achieve before the GPU scales up. Mine is set to 90%.
Down Differential - When you want your GPU to scale down lower, (Up threshold minus down differential.) Mine is set to 10%, so when the GPU hits 80% utilization on a speed, it drops to a lower frequency.
Utilization Timeout - Basically is the sampling speed of the GPU (how fast you want it to make decisions to change speed.) Mine is set to 25 milliseconds.
Voltages - Test these the same way as the CPU, get a GPU stress testing app, and set a certain frequency. When you see artifacts or glitches on your screen, then the voltages are too low. Below are MY values.
54mHz - 825mV
108mHz - 875mV
160mHz - 950mV
266mHz - 975mV
350mHz - 1050mV
440mHz - 1100mV
533mHz - 1125mV
640mHz - 1150mV
733mHz - 1175mV
800mHz - 1200mV (This clock speed proved to be slightly unstable at 1175mV, though still usable)
I/O section - These values/settings control how your device writes/reads things from the SD card, or internal storage.
I left both of my storage schedulers at ROW but you can change them and play around. I believe that deadline is the best for overall performance, but can be unstable sometimes.
I/O Read Ahead - These control the cache file on the internal/external storage. I have my internal set to 1536kB, and external set to 2048kB, because those values gave me overall good write/read speeds.
Dynamic Fsync - From what I know, this helps keep the data from being corrupted by creating a buffer between data being written and the storage. Correct me if I'm wrong. I kept it enabled.
The entire audio section is pretty self explanatory, and I'm getting tired of typing all of this, so if you need help, PM me or comment.
Again, take this entire post with caution. What works with my device, may make yours unstable. I only provided mine to give you a baseline, my values offer good performance and battery life anyways. Feel free to correct any of my errors by PM or comment, and I will gladly change my post to accommodate for my errors

My phone is stable at 782.5mv on perseus but in deep sleep it just isn't. Not even on 813mv.
this is XXXDDDAAA

And 2000 is max with Redpill.
this is XXXDDDAAA

Thanks for the guide, will test your settings:highfive:

McLaren__F1 said:
Thanks for the guide, will test your settings:highfive:
Click to expand...
Click to collapse
Do post your result here. It works great for me.

[KERNEL][Sense/AOSP][aroma] lONELyX #023|3.1.10|S2W,DT2W,FC,UMS,UV,OC,MPDec,CPUQuiet

{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
src GitHub link.
CREDITS
step by step i'm porting works this guys.
maxwen (most of code)
n3ocort3x, Xmister, Alex-V, faux123
IMAGES
Configuring kernel parameters:
S2W Configs:
Turn off:
Code:
echo "0" > /sys/android_touch/sweep2wake
Button panel locks to s2w after this distance:
Code:
/sys/android_touch/s2w_register_threshold
Screen turns on/off after this distance:
Code:
/sys/android_touch/s2w_min_distance
Direction independent(1 - Yes, 0 - No):
Code:
/sys/android_touch/s2w_allow_stroke
Pocket protection(1 - Yes, 0 - No):
Code:
/sys/android_touch/pocket_detect
DoubleTap2Wake Configs:
Turn on:
Code:
/sys/android_touch/s2w_allow_double_tap
Time double taps (ms)
Code:
/sys/android_touch/s2w_double_tap_threshold
Time between double taps
Code:
/sys/android_touch/s2w_double_tap_duration
Dead area in points from top of screen
put 1780 for dt2w works only on virtual keya area
Code:
/sys/android_touch/s2w_double_tap_dead_area
Fast charge:
allow charge device from usb connected to PC as from wall wallet
can close ums connestion
Code:
/sys/devices/platform/htc_battery/fast_charge
Disable CPU freq limit in early suspend mode
Code:
/sys/module/cpu_tegra/parameters/perf_early_suspend
Disable EDP limit
Code:
/sys/module/cpu_tegra/parameters/disable_edp_limit
Backlight button brightness (0-255)
Code:
/sys/class/leds/button-backlight/button_brightness
Quick GPU OC 0 - 416 Mhz, 1 - 484 Mhz, 2 - 520 Mhz
Code:
/sys/kernel/tegra3_dvfs/gpu_quick_oc
CPU UV one digital value such as 25 or 0 or -25, -50, etc
Code:
/sys/kernel/tegra3_dvfs/cpu_millivolts
CORE UV one digital value such as 25 or 0 or -25, -50, etc
Code:
/sys/kernel/tegra3_dvfs/core_millivolts
Eco mode 0 - disabled, 1 - enabled (plug up to max 2 core)
Code:
/sys/module/intelli_plug/parameters/eco_mode_active
Click to expand...
Click to collapse
Click to expand...
Click to collapse
aroma installer
UMS Mass storage (Sense applications)
common presets
turn on/off S2W
S2W direction dependent
S2W three/two buttons distance
pocket protection on/off
turn on/off DT2W
DT2W only on the VK board
usb fast charge on/off
VK button brightness
set 0
set 10
set 60
set 140
set 255
GPU OC 416, 484, 520
set 416 Mhz
set 484 Mhz
set 520 Mhz
boost CPU on resume
disable/enable EDP limitation
disable/enable LP mode on resume
disable/enable ECO mode
limit CPU max freq
undervolting
CPU
-25 mV
-50 mV
CORE
-25 mV
-50 mV
frandom device
flash kernel image (for S-OFF device)
Sense LM seria
Sense LQ seria
Sense LI seria
Sense UV LM seria
Sense UV LQ seria
Sense UV LI seria
Sense MV LM seria
Sense MV LQ seria
Sense MV LI seria
Click to expand...
Click to collapse
CHANGE LOG
Code:
[B]Ver 023[/B]
+ added MV kernels - middle undervolting from the box (CORE -25 mV/CPU -50 mV)
- complette removed LS seria.
[SIZE=1][COLOR=navy]full kernel set now: LM, LM_UV, LM_MV, LQ, LQ_UV, LQ_MV, LI, LI_UV, LI_MV[/COLOR][/SIZE]
[B]aroma[/B]
+ added value 10 backlight button brightness
[B]Ver 022[/B] (renew)
+ the golden kernel seria LM UV -50 from the box, return back in full team UV - LM, LQ, LI, LS look in ZIP with uv predicate.
- removed quick core uv option as incompatible with UV -50 kernels, the core_millivolts stay.
[B]aroma[/B]
* fixed mistakes.
+ added eco mode option
+ added limit CPU max freq option
+ account UV -50 kernels features
[B]Ver 021[/B]
+ added intelli hot plug (faux123), LI seria in ZIP
* restored Best trade hot plug (HTC), LS seria in ZIP
[B]Ver 020[/B]
* fixed bluetooth for AOSP, checked with CM 10.2.1
[B]Ver 019[/B]
+ restored frandom compiled as separate module
* restored /sys/kernel/tegra3_dvfs/core_millivolts
[SIZE=1][COLOR=#0000ff]getter show CPU clock freq with CPU voltage, setter takes one digital value: 25 or -25 or -50 etc. Entered value applying to all CPU voltage table.[/COLOR][/SIZE]
+ added core voltage attribute /sys/kernel/tegra3_dvfs/core_millivolts
[SIZE=1][COLOR=blue]getter show GPU clock freq with CORE voltage, setter takes one digital value: 25 or -25 or -50 etc. Entered value applying to all CORE voltage table.[/COLOR][/SIZE]
+ added quick core voltage atrribute /sys/kernel/tegra3_dvfs/core_quick_mv
[SIZE=1][COLOR=blue]0 - stock mV table, 1 set -25 mV, 2 set -50 mV into core_millivolts[/COLOR][/SIZE]
* compiled two kernel files LM and LQ with stock voltage
[B]aroma[/B]
+ added undervolting option to CORE and CPU voltage.
* restored frandom option
* in zip file two kernel images LM and LQ seria packed with Sense ramdisk.
[COLOR=blue]To get AOSP repack appropriate sense kernel into AOSP image.[/COLOR]
[B]Ver 018 (renew)[/B]
* DVFS GPU table 484 Mhz set as default
- removed frandom device
[B]aroma[/B]
+ default GPU OC 484 Mhz
- removed endeavoru model checks before install
- removed rescue voltage
* in zip file now four kernels: LM seria 50 and 25 mV undervolted, LQ seria 50 and 25 mV undervolted.
[COLOR=blue]To get AOSP repack appropriate sense kernel into AOSP image.[/COLOR]
[B]Ver 017 [/B](renew)
* undervolted -50mV for all freq table from the box
* enhanced gpu_quick_oc to three position. 0 - 416 Mhz(default), 1 - 484 Mhz, 2 - 520 Mhz
* no_edp_limit reworked and renamed to disable_edp_limit. Now applied values from init.d without losing after.
+ added gaming governor
+ compiled with linaro 4.7 Cortex A9 toolchain with appropriated compiler options
+ added frandom and erandom char devices
[SIZE=1][COLOR=blue]56frandom script replace random with frandom and urandom with erandom.[/COLOR][/SIZE]
* installation via aroma installer
+ kernel repacked with AISP and CM ramdisks (tnx @[URL="http://forum.xda-developers.com/htc-one-x/member.php?u=4898058"][COLOR=#d38339]audahadi[/COLOR][/URL])
[SIZE=1][COLOR=blue]Not sure it working - need check.[/COLOR][/SIZE]
[B]Ver 016[/B]
- reverted to stock variant button backlight - removed blink virtual key supports, button_brightness stay here.
+ swap support
+ reworked init.d/55sw2wake
+ reworked min scale frequnce same as max
+ compiled with linaro 4.7
* fixed not applied CPU voltage
* fixed abnormal battery consuming
* GPU OC set default to 484 Mhz
+ added gpu_quick_oc to 520 Mgz
[B]Ver 015[/B]
* user policy max freq sync vs scaling max.
+ applied fix for proximity sensor with not enough light.
+applyed wi-fi patch.
To init.d/55sw2wake added
------------------------
##Blink VK with events
echo "0" > /sys/class/leds/button-backlight/auto_bln;
#Actual anly for cpuquiet LQ seria
#echo "0" > /sys/module/cpu_tegra/parameters/disable_lp_mode_on_resume;
[B]Ver 014[/B]
* Remade no_edp_limit attribute. Now can be applied from init.d
[B]Ver 013[/B]
+ added Backlight button brightness
[SIZE=1][COLOR=blue]/sys/class/leds/button-backlight/button_brightness (0-255)[/COLOR][/SIZE]
[B]Ver 012[/B]
* UV-mv table
[SIZE=1][COLOR=blue]/sys/kernel/tegra3_dvfs/cpu_millivolts[/COLOR][/SIZE]
* GPU OC 520 persist
[SIZE=1][COLOR=blue]removed gpu_oc and quick_gpu_oc attributies (not needed),[/COLOR][/SIZE]
[SIZE=1][COLOR=blue]but forgot to remove commented string gpu_quick_oc from init.d/sw2wake[/COLOR][/SIZE]
- Removed intellidemand, ondemand1 and touchdemand governors
[SIZE=1][COLOR=blue]old release not compatible with new kernel, may be i'm add reworked versions latter[/COLOR][/SIZE]
* Thermal throttle limitation
[SIZE=1][COLOR=blue]to disable /sys/module/cpu_tegra/parameters/no_thermal_throttle_limit (1-disable control)[/COLOR][/SIZE]
[SIZE=1][COLOR=red]i'm highly do not recommending touch it[/COLOR][/SIZE]
[SIZE=1][COLOR=#ff0000]thermal throttle prevent cpu damage from overheating more then 85 deg by C[/COLOR][/SIZE]
* EDP limitation
[SIZE=1][COLOR=blue]to disable /sys/module/cpu_tegra/parameters/no_edp_limit (1-disable max CPU freq limits in multi cpu mode)[/COLOR][/SIZE]
[SIZE=1][COLOR=#0000ff]EDP set freq limits dinamicalky decide battery level and cpu temperature below 85 deg by C[/COLOR][/SIZE]
* perf mode for awake
[SIZE=1][COLOR=blue]/sys/module/cpu_tegra/parameters/perf_early_suspend (1-enable perfomance mode in early suspend mode)[/COLOR][/SIZE]
+ Support HTC power save mode
[SIZE=1][COLOR=blue]/sys/htc/power_save (1 - enable power save mode 1.3 Ghz cpu limitation)[/COLOR][/SIZE]
[SIZE=1][COLOR=#ff0000]controlled by ROM HTC power manager no need touch it[/COLOR][/SIZE]
+ Support HTC media boost
[SIZE=1][COLOR=blue]Don't investigate it. In code it some alghoritm to boost cpu freq for audio and video processing. looks like controled by ROM[/COLOR][/SIZE]
+ Support HTC ril boost
[SIZE=1][COLOR=blue]Boost cpu freq in deep sleep mode for ril modem(incoming call)[/COLOR][/SIZE]
[B]Ver 011[/B] - died in beta stage
[B]Ver 010[/B]
+ GPU OC 520 optional in init.d/sw2wake
+ MP Decision instead HOTPLUG
+ IO Schedules (bfq, row, sio)
+ Governors (touchdemand, ondemand1)
[B]Ver 009[/B]
- GPU 520 removed
* do over again dt2w
* fixed stuck after deep sleep
* fixed vk responsible for Venom users
[B]Ver 008[/B]
+ Voltage control
+ GPU 520
+ smartmax, smartmax_eps governors.
[B]Ver 007[/B]
*Code revised and cleaned
*Pocket protection rewrited, now it work as expected
-Dead area by default revert back to 0
[B]Ver 006[/B]
+s2w Added pocket protection
[SIZE=1][COLOR=blue]/sys/android_touch/pocket_detect, enabled by default in 55sw2wake[/COLOR][/SIZE]
+dt2w Added dead area
[SIZE=1][COLOR=blue]/sys/android_touch/s2w_double_tap_dead_area, 1780 by default in 55sw2wake (dt2w work only in virtual key panel)[/COLOR][/SIZE]
[SIZE=1][COLOR=blue]put 0 for dt2w works on all screen and not only on virtual keya area.[/COLOR][/SIZE]
HOW TO FLASH
For S-OFF
1. Download ZIP file and put to SD card
2. Flash ZIP from recovery
For S-ON
1. Download ZIP file and extract kernel\[what you need].img to Kernel Flasher fastboot dirrectory on the PC
2. Rename .img file to boot.img
2. Put ZIP file to SD card and flash from recovery
3. Reboot to bootloader and flash kernel by Kernel Flasher from PC
Downloads post #2

Download section
Short explanation
Tegra 3
Tegra 3 have two CPU clasters
G cluster: 4 high performance Cortex A9 cores
LP cluster: 1 low leakage Cortex A9 core
Only 1 cluster can be active at a time
To enable use of LP cluster, must only 1 CPU to be active
No interrupts or other wakeups possible for other cores
CPU management
Handles both onlining/offlining cores and cluster switch
Use hotplug to online/offline cores
Uses the per cpu frequency targets set by cpufreq, and number of runing threads, as a measure of load
CPUFreq
The cpufreq architecture allows frequency scaling of a target CPU and is a basic driver installed in the kernel. Controlling of frequency and its corresponding voltage results in lower power of the target device. On the Android device, dynamic frequency scaling is realized by using the governors.
Governor monitors the current usage on each core at certain time intervals. When the load exceeds or falls below the threshold, frequencies are made higher or lower dynamically. Use SMP to identify power suspend/resume events.
Governors
Deside with what frequency must works cpu
Decide how long time cpu must stay with this frequency and which be next
Good guide by governors HERE.
HotPlug
The hotplug is an extended function of cpufreq, which was developed specifically for the power control of multicore processors. When cpufreq sets a core to the maximum frequency that runs for a certain period of time, the hotplug adds another core to distribute the load. Similarly, when cpufreq sets a core to the minimum frequency and the load stays low, the hotplug shuts down excess cores to reduce power consumption.
HTC best trade (HTC)
Cpu auto-hotplug/unplug based on cpufreq and runnable threads
Automatic decision wether to switch to low power core or not
Automatic decision wether to switch off cpus 1,2,3
Qualcom mpdecision (showp1984)
Cpu auto-hotplug/unplug based on system load (runqueue)
Automatic decision wether to switch to low power core or not
Low power single core while screen is off
Nvidia cpuquiet (maxwen)
Uses load status to hotplug cpus
Uses also rq_stats to detect situations with lots of threads, but low load
Froze cpus instead turn off as in best trade and mpdecision.
Cpuquiet implements pluggable policies for forcing cpu cores into a quiescent state. Appropriate policies will save power without hurting performance
Basically its a governer for the CPU cores
Runnable activates cores based on multithreading
Balanced activates based on load
Userspace basically forces them online
RQ_STATS and LOAD_STATS use the rq information to scale the CPUs
Cpu quiescent state, instead turning off it was main idea for develop cpuquiet by nvidia.
Intelliplug (faux123)
Cpu auto-hotplug/unplug based on system load (runqueue)
Automatic decision wether to switch to low power core or not
Low power single core while screen is off
Faux's mpdecision variation.
Click to expand...
Click to collapse
ver #023
LS seria - stock HTC best trade hotplug, LM seria - mpdecision hotplug, LQ seria - nvidia cpuquiet hotplug, LI seria - intelli hotplug
*for more informtyion read Short explanation
To get AOSP just repack apropriate Sense seria with wanted AOSP kernel image from installer
UV predicate mean undervolted -50 mV both CPU and CORE from the box.
MV predicate mean undervolted -25 mV CORE and -50 mV CPU from the box.
Flash UV only if you sure in your device. Other way - it try first standart version with undervolting on the fly. If your device works without problems with -50 mV can try MV version, next step UV.
*UV version MUCH power save than standart, but so undervolting can not works on your device.
androidfilehost.com
mirror
bindroid.com

Great work!!!
But upload sources please!!!

awesome mate *_* thanks for that will flash now and your rom too really great that you are doing still so much for us

Good to see kernel thread.. Thanks a lot mate. :good::good:

Will this kernel work in CM 10.2?
Enviado do meu EndeavorU através de Tapatalk

salomaoa said:
Will this kernel work in CM 10.2?
Enviado do meu EndeavorU através de Tapatalk
Click to expand...
Click to collapse
no as you see it
s made for sense only

Awh my god lyapota you are the real champ i mean real developer 1st for mod 2nd for ROM and now for even kernel also. I salute your dedication for one x. You have learned a lot. Gr8 work much appreciated
Sent from my HTC One X using Tapatalk

bhaumik555 said:
Awh my god lyapota you are the real champ i mean real developer 1st for mod 2nd for ROM and now for even kernel also. I salute your dedication for one x. You have learned a lot. Gr8 work much appreciated
Sent from my HTC One X using Tapatalk
Click to expand...
Click to collapse
+ 1
Many Thanks Maestro... :thumbup:
Sent from my HTC One X using Tapatalk 2

thats what everyone wanted.. and thats what everybody got... thanx a lot lyapota.... thanx for giving sense ROMs a new kernel...

Ty so much let's flash away

thanks man i'll try asap

Thanks to all for good words. This is what do your work enjoyable.

lyapota said:
Thanks to all for good words. This is what do your work enjoyable.
Click to expand...
Click to collapse
Thank you so much
You're really doing a lot for HOX

Thank you for this it was much needed been using this kernel since you first posted it all works well I have had a couple ogg reboots but I think that's due to minfrees it's developing well I can't wait to see some oc and uv smartmax gov ect. Is this in your plans if you don't mind me asking I am very happy the way things are but battery could use a little help however my hox runs beautifully using your kernel we all really appreciate your work and thank you again
Sent from my HTC One X using Tapatalk

Epic kernel :thumbup: thanks Lyapota :beer:
Sent from my HTC One X using XDA Premium 4 mobile app

Really fast and smooth kernel hope battery with stock like kernel is good also gaming performance
Gesendet von meinem HTC One X mit Tapatalk

Congrats,sir!It`s best choice you do.
Thanks for the great job you do for us!

I have the 004 version installed, can I flash the latest version without flashing the boot.img?
Sent from my HTC One X using Tapatalk

Now I will also switch to your ROM
Sent from my HTC One X using XDA Premium 4 mobile app

LG H440N 4G LTE battery & performance tweaks

LG H440N 4G LTE kernel performance tweaks
FINAL VERSION
any other tweaks I find useful will be posted in the "init.d" section
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
​Changelog:
27. December 2015 - added FINAL values. Everyone should use these. "They are nice!" - says Borat.
28. December 2015 - added a changelog. Heh!
29. December 2015 - added a super secret, secret testing zone. I dare you to find it. Note that it's well hidden!
30. December 2015 - new tcp tweaks in init.d section, screenshot how it should look like, Recently tweaks.
31. December 2015 - added a link to a web site with an excellent article on battery care. Added Kernel Adiutor tips by jonathansmith.
1. January 2016 - Added 7+ hours SOT settings in the testing zone. Happy New Year!
3. January 2016 - Since I achieved what I aimed for, I am taking a break from this thread. It will stay open, so feel free to keep on discussing.
18. January 2016 - Testing settings became default settings, with a few changes.
29. January 2016 - Low Memory Killer & swappiness value updated.
BATTERY CARE - a must read for everyone!
Disclaimer:
I am not to be held responsible if anything goes wrong. Simple as that. You do these mods of your own free will.
Warning:
Please, do not report issues or complain about lousy battery times/performance, if you've used any of those pre-made scripts that promise godly battery or performance - they often cause more trouble than they're worth, and are mostly snake oil. And often, you cannot easily undo those changes. If you run a lot of background apps ( for example, five different messengers that cause wakelocks or increased battery usage ), then this guide is not for you. Do not report issues if you've modded your phone with any audio scripts ( like v4a ), xposed, or anything like that! Do not report if you did any permanent system mods, period! These kernel are for CLEAN & STOCK phones, that are rooted ONLY. To summarize, I will not bother replying if you did anything to your phone besides the tweaks I recommend.
Nothing done here is permanent. Everything can be returned to stock in a matter of minutes, if you prefer so, just by uninstalling Kernel Adiutor, unfreezing the bloatware and power cycling the phone.
And hugs to all that pushed the "Thanks!" button. Hell, hugs for everyone!!!
●▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬●
BEFORE WE START...
●▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬●​
Must be done before modifying CPU values:
Open your hidden system menu by dialing 277634#*#, go down to Power, find items "High temperature property" and "Thermal mitigation daemon", and set them like this:
High Temp Prop OFF
Disabled
Thermal Mitigation
Disabled
After that, turn phone off, wait 15-20 seconds and turn back on.. The screen will not dim in hot conditions anymore. Benchmarks are higher, games run smoother. And we can tweak our CPUs.
●▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬●
KERNEL ADIUTOR SETTINGS
●▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬●​
Apply on boot time is to be decided by the user. Although Kernel Adiutor waits for boot complete, I noticed ( on few occasions ) that it takes more time to apply the settings properly. Why? Who knows. Depends on the number of apps you have running on boot, version of the firmware or how lazy it is on boot... Safest setting is 40 seconds, but 20 should cause no issues and is preferred. 10 can be a problem.
CPU:
CPU Maximum Frequency: 1209
CPU Minimum Frequency: 800
CPU Governor: interactive
*note: Minimum frequency is set to default 800, since Snapdragon 410 draws the same voltage on 200, 400, 533 and 800. That's the reason I set the frequency back to 800 idle. No need to go lower for absolutely no gain in battery life or performance.
CPU Governor Tunables subsection:
above_hispeed_delay: 20000 1094400:40000
go_hispeed_load: 80
hispeed_freq: 998400
min_sample_time: 40000
timer_slack: -1
DEFAULT ( 7+h SOT ) - target_loads: 1 800000:75 998400:80 1094400:85
PERFORMANCE ( smoother, few hours less SOT ) - target_loads: 1 800000:75 998400:80 1094400:80 1152000:85
timer_rate: 20000
max_freq_hysteresis: 40000
*note: Reason for system lags is found in the cheaper and slower memory LG has used for H440N ( my guess is, to cut cost ). You can test that yourself by running various I/O benchmark tools and noting speeds of random and sequential reads/writes. I did not manage to make that better in any way by tweaking the I/O schedulers, be it deadline, cfq or row - even testing some examples from Franco's Dev Team. Seems that it's best to leave it on cfq and cut overhead with the flashtweaks init.d script found later mentioned in this post.
Frequency changes happen VERY fast. So fast that CPU widgets or passive frequency readers have a lousy time keeping up. Only values you can trust are found in Kernel Adiutor's Frequency Table.
Those values found above are the best possible values for H440N's CPU for performance & battery saving, and I stand by them. If anyone else cares to try and do some tweaking to improve on those, by all means, please do so. If in the future I decide to add new CPU values, they will be strictly performance based, hence no battery saving.
Reason for the CPU frequency sticking to 1209600 is caused by the LG Home launcher. It contains a system call where, if you open up your apps drawer, it immediately ramps up the frequency to the max for almost 8 seconds or until you close the app drawer! That sucks, and is a lazy way for LG to provide smooth app drawer opening/swiping/closing! Bad LG, bad!!!
Two ways to solve that:
1. Spend less time listing through your apps drawer, since the frequency drops as soon as you stop swiping through it, or...
2. Freeze LG Home and use another launcher ( like Nova or Apex ), if you don't mind losing Double Tap to Wake, or work around that problem with launchers that support double tap gesture and link that gesture with a screen off app like this. Do not freeze any LG Home system apps, besides Easy Home. No need. System will automatically kill the unneeded launcher. Just follow my frozen bloatware list. Nothing more, nothing less.
Low Memory Killer values ( top to bottom ):
48
60
72
84
96
120
Virtual Memory:
vfs cache pressure: 100
swappiness: 80
Build prop Editor
dalvik.vm.heapsize: 174m
dalvik.vm.heapminfree: 512k
dalvik.vm.heapstartsize: 8m
dalvik.vm.heapgrowthlimit: 128m
dalvik.vm.heaptargetutilization: 0.75
dalvik.vm.heapmaxfree: 8m
*note: Dalvik tweaks are based upon Intel's recommended Dalvik tweaks for Lollipop phones with 1 GB RAM and xhdpi displays.
Init.d
1. Turn on "Emulate Init.d" and click that big "+" to create a new script.
2. Name the new script: flashtweaks
Contents of the "flashtweaks" script are:
Code:
#!/system/bin/sh
echo 0 > /sys/block/mmcblk0/queue/nomerges;
echo 2 > /sys/block/mmcblk0/queue/rq_affinity;
echo 512 > /sys/block/mmcblk0/queue/nr_requests;
echo 0 > /sys/block/mmcblk0/queue/iostats;
echo 0 > /sys/block/mmcblk0/queue/add_random;
echo 0 > /sys/block/mmcblk1/queue/nomerges;
echo 2 > /sys/block/mmcblk1/queue/rq_affinity;
echo 512 > /sys/block/mmcblk1/queue/nr_requests;
echo 0 > /sys/block/mmcblk1/queue/iostats;
echo 0 > /sys/block/mmcblk1/queue/add_random;
2. Name the new script: tcptweaks
Contents of the "tcptweaks" script are:
Code:
#!/system/bin/sh
#more reasonable tcp tweaks
echo 1 > /proc/sys/net/ipv4/tcp_low_latency;
echo 0 > /proc/sys/net/ipv4/tcp_timestamps;
echo 900 > /proc/sys/net/ipv4/tcp_keepalive_time;
echo 5 > /proc/sys/net/ipv4/tcp_keepalive_probes;
echo 156 > /proc/sys/net/ipv4/tcp_keepalive_intvl;
Example of properly added scripts. I just named them differently:
Ignore the "99SuperSUDaemon" script unless you know what it is. It's not needed for our tweaks, and if you don't have it, it's perfectly fine.
Here are some screenshots on clearing / checking Kernel Adiutor's Frequency Table, by our fellow XDA member jonathansmith:
How to clear timers?
Check correct frequency usage.
Now, since you've finished with Kernel Adiutor, power cycle the phone. You're almost done. All that's left are:
●▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬●
OTHER SETTINGS
●▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬●​
In Developer options, set animation scale values to OFF.
In Settings / Display / Brightness enable Night Brightness. Who needs anything over 0% brightness from midnight to six in the morning?
Visit Play Store and install these apps:
Recently by Chainfire
Trimmer (fstrim)
Recently! settings ( preferred ):
Age limit: No limit
Entry limit: 12
Apply on boot: Yes
Freeload: Checked ( yeah, we're cheapskates )
EVERYTHING ELSE DISABLED / UNCHECKED.
Recently! settings ( much faster version ):
Age limit: Running apps only
Entry limit: Running apps only
Apply on boot: Yes
Freeload: Checked ( yeah, we're cheapskates )
EVERYTHING ELSE DISABLED / UNCHECKED.
Do a "Clear all" in recent apps list after a reboot. It will make things faster. Believe me.
As for Trimmer (fstrim), run that every week or so, on "/data", "/cache" and "/system". No need to run it daily.
Apps frozen with Titanium Backup ( freeze bloatware, do not delete it - you'll thank me later ):
Chrome
Drive
E-mail
EasyHome
Gmail ( I am using Aqua Mail. )
Google Play Books
Google Play Games
Google Play Movies
Google Play Music
Google Play Newsstand
Google Search
Google+
Hangouts
HTML viewer ( do not disable if using stock browser or Chrome )
Internet ( I am using this version of Opera. It's the best one.
LG Keyboard ( disable only if already using another keyboard. I am using Smart Keyboard. )
LG Keyboard Black Theme ( disable only if already using another keyboard. I am using Smart Keyboard. )
LG MLT ( disable LG MLT in the hidden service menu before freezing it! Menu code is 277634#*# )
Live Wallpaper
Music ( both widget and app - I am using PlayerPro. )
Trusted Face
Weather
Weather Theme
WeatherPlatform
Do not touch anything else! Don't say I did not warn you.
If you prefer blocking ads on web sites, like I do... then download AdAway from XDA forum, and enjoy ad-free surfing.
That's it. Have fun, and enjoy your buttery smooth phone. One of this year's best-buy smartphones. Too bad it doesn't get the attention it deserves. Really, an unsung hero if there ever was one.
Although there are a lot of other CPU tweaking values throughout the thread, these values are the standard ones you should use. Other ones are experiments, or just plain testing values.
H440N is compatible with DriveDroid - in case you want to boot an operating system or a Linux distro off of it.
●▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬●
SUPER SECRET, SECRET TESTING ZONE
●▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬●
by WellHidden™​
THESE SETTINGS BECAME THE DEFAULT SETINGS. SEE ABOVE.
With the latest test settings I achieved 7+ hours SOT. And yes, it can be done! You got the proof below.
Everything else besides these TESTING values below stays the same as in FINAL values ( dalvik, init.d, etc. ).
CPU:
CPU Maximum Frequency: 1209
CPU Minimum Frequency: 400
CPU Governor: interactive
CPU Governor Tunables subsection:
above_hispeed_delay: 20000 1094400:40000 1152000:20000
go_hispeed_load: 82
hispeed_freq: 998400
min_sample_time: 40000
timer_slack: -1
target_loads: 72 998400:82 1094400:85 1152000:86 1209600:90
timer_rate: 20000
max_freq_hysteresis: 40000
Virtual Memory:
Swappiness: 60 ( I recommend 100, but go back to 60 if you feel the memory gain is not worth a slight performance drop. )
Vellamo 3.2 scores:

My phone was originally set at frequency max 1200 and min 1200. After all the changes you suggest, do you set the min cpu frequency at 200 or leave it on 1200?

polfrank said:
My phone was originally set at frequency max 1200 and min 1200. After all the changes you suggest, do you set the min cpu frequency at 200 or leave it on 1200?
Click to expand...
Click to collapse
Min 200 Max 1200
Interactive / Noop
Other values as suggested.
But, damn. Those original settings must've drained the battery like hell... Are people at LG crazy?
EDIT: Sometimes, SetCPU will show the lowest frequency as 1200, but don't worry. Set it to 200, and verify it's at 200 in Times in state on the last SetCPU tab. It seems to be a bug in the app. That's why I used Kernel Adiutor.

ondemand + noop + lmk set to agressive and the phone flies like never before! looks like constant 60 fps. Thanks op!

Always glad to help out. Like I mentioned before, this phone has good hardware and is capable of stellar performance. Only problem is LG did not pay much attention on the tweaking side of things.
It's easy for them to tweak flagships
EDIT: Just found out about another gem! The app is called Recently by chainfire.
Installed, tried and it's marvelous even on default settings. I encourage everyone to try it. It's what Recent cards were supposed to be, in my opinion.

So I installed Busybox and Kernel Adiutor, set CPU min frequency to 200 Mhz, cpu governor to interactive and and I/O scheduler to noop. I've set both to apply on boot. Is that everything I need to do?

Fobos531 said:
So I installed Busybox and Kernel Adiutor, set CPU min frequency to 200 Mhz, cpu governor to interactive and and I/O scheduler to noop. I've set both to apply on boot. Is that everything I need to do?
Click to expand...
Click to collapse
It is, if you don't mind the default Interactive values. Otherwise, go a bit lower to "CPU Governor Tunables". Click that and set values as mentioned in first post. Those give a much better battery life.
After that, my recommendation is to visit the Low Memory Killer section and set that to Aggressive and apply on boot.
I can say that, after a bit of tweaking, this phone rocks! Glad to have bought it. Still hoping for a unlocked bootloader and maybe a CM port

Can you please take a screenshot of your CPU Governor Tunables section? I'm not completely sure that I did it right.

No problem, my good man. Here they are:
http://imgur.com/yDbXHE3
http://imgur.com/3uDi04u

holy ..! this really does make a difference. is it ok if i set cpu to "performance" and dont mess anything else with it? i dont care about battery life that much. cuz it seems that with agressive setting for ram, and changing to "noop" made wonders for me performance wise

Performance governor forces 1200, so that's not desirable.
For the best performance with lowest idle, set it to Ondemand / Noop. You will lose a bit more battery with those, but the phone will fly.
Otherwise, set as I've set it. Tweaked interactive.

userspace,powerspace hotplug and performance is what i have in karnel auditor.. which one should i choose then? tyvm!
p.s. thanks again for these tips man

That's strange. Are you using the LG Spirit H440N or some other variation?
See here ( list of governors ):
http://imgur.com/hxZOoDz

ah right. that could be a reason.. i use 3g version, with mediatek cpu

* moved to first post *

Tomo123 said:
Performance governor forces 1200, so that's not desirable.
For the best performance with lowest idle, set it to Ondemand / Noop. You will lose a bit more battery with those, but the phone will fly.
Otherwise, set as I've set it. Tweaked interactive.
Click to expand...
Click to collapse
amazing speed and multitasking (with Recently), thank you for this

Can you help me with target loads? Is this ok?
Sent from my LG-H440n using Tapatalk

String seems to be written ok, but my guess is it will clash with go_hispeed_load value.
If go_hispeed_load has a value of 85, then your initial value in target loads can't be "1". It must be higher than 85.
We're using our hispeed frequency ( 400000 ) as idle. It often drops to 200, so I see no reason of adding 200 to target loads.
Did you check out my post above?
Also, take a look at my KA frequency table:
http://imgur.com/BikoQk2

It seems that ive messed up something. Now my phone wont go deepsleep. This is the result over night.
Sent from my LG-H440n using Tapatalk

Can you make a screenshot of your target loads. Im having a hard time making it work. Performance is on point but i get a lot of battery drain.
Sent from my LG-H440n using Tapatalk