Database Develop

SetCPU settings for double battery life

Hey guys can someone share what's the best profile and configuration to double the battery life in our devices using setCPU..
Thanks in Advance!
Sent from my CSL-MI410 using XDA App

Hi there,
I think, it depends on how is your settings now. You can try 500 mhz and disable mobile data first.

hmm.. okay.. will 500Mhz double the life and also give a decent performance??

i'm more concern on the voltage control.
can everyone share their fine profile for voltage?
btw, my setcpu setting were recommended by CacingKalung.
25mhz and 1125mhz with smartassv2.

thepranam said:
Hey guys can someone share what's the best profile and configuration to double the battery life in our devices using setCPU..
Thanks in Advance!
Sent from my CSL-MI410 using XDA App
Click to expand...
Click to collapse
The following works for me all the time
Main Profile - MAX - Dont set it all the way to OC if you are using any of the modded kernels, keep it just above 1Ghz, i set at 1200.
MIN - around 600. Use SmartassV2, if unavailable use Performance.
Turn on Profiles and set 2 important profile
Screen Off - MAX & MIN - 122Mhz. Priority 90%, Set governer Conservative
In Call - MAX - Around <=500, MIN = Around 300, Priority - 100, Set governer Performance. This is to avoid any lags when call comes in
With this I am able to stretch the battery easily to 1.5 days. I have observed the performance to be uniform whether on CM7 or MIUI.
Additionally I also configure Adv Task Killer Pro - Always on, Kill Task when screen off, and dont forget to set Ignore for - SetCPU.
This combo of SetCPU and Task Killer works for me ! Try and see if it meets your expectations

How are you able to set exact values of 122 MHz or 300/500 MHz?
On stock ROM, SetCPU only allows for a slider to control the frequency which doesn't allow for precision setting since after about 368 MHz the slider only goes to around 700+ MHz skipping all the frequencies possible in between.
Rgds
Sandy

Im using SET CPU and the ondemand governer gives very good battery life. I keep the min speed to 122 MHZ and Max to 1024 MHZ.
Made three profiles for screen off, temp >40deg and In call. Screen off profile kept to 122MHZ, certainly improved my battery by leaps and bounds.

[Info] MBQs CPU Guide thread. (Tips, IO Schedulers, TCP Algorithms, and more!)

MBQsnipers Guide to Kernel Knowledge
It lives again!
----
CPU Guide app:
Want this in app form? Lucky for you, I made one!
Get it here:
https://play.google.com/store/apps/details?id=com.kyler.mbq.mbqscpuguide&hl=en
----
CPUGuide website:
(If you're using it on a mobile browser, enable desktop mode).
http://CPUGuide.MBQonXDA.net
----
Contribute to the app!
It's always very appreciated. I also need translations.
https://github.com/MBQs-CPU-Guide/MBQs-CPU-Guide
---------------------------------------------------------------------------
Governors:
OnDemand:
Ondemand stands for that it scales up on load in frequency and then detects the load and scales back to a frequency which is fullfills the "demand" of the current load dynamically. (AndreiLux)
Interactive:
Interactive scales by default in steps towards max frequency, Ondemand in its default implementation scales immediately to max frequency. (AndreiLux)
InteractiveX(v2):
The same as Interactive, but when you turn your screen off it forces the second CPU core offline until the screen turns on again.
Performance:
Will constantly run at the highest set CPU speed.
Powersave:
Will constantly use your lowest set CPU speed.
Conservative:
Conservative means that it scales conservatively, not that it is conservative. It pretty much very similiar to Interactive in that it scales up and down in frequency steps. It actually can be one of the most aggressive governors out there. (AndreiLux)
Userspace:
Rare in the word of kernels. Typically not used for mobile phones. But what it basically does is, it runs on whatever CPU speeds the user sets through an app.
Lagfree:
More aggressive kernel. It scales the CPU faster, reducing lag and performance, while maintaining decent battery life. Its main goal is to increase performance without reducing battery life.
Min Max:
Only uses your max screen on frequency, and your min screen on frequency.
Hotplug:
Based off of Ondemand. It allows a CPU to go offline with minimal usage. When you're sending messages, browsing settings, or other simple tasks, most likely one of your CPUs will be offline.
PegasusQ:
Samsungs Governor for multi-core phones. Based off of Ondemand. This kernel controls hotplugging as well.
Lazy:
This Governor doesn't scale as fast. It's really a lazy governor, it tends to stick in the same CPU frequency without changing as much. Which can be beneficial to your battery (if your CPU settings are conservative) or can reduce battery life (if your chosen frequencies are aggressive).
Nightmare:
A modified PegasusQ, less aggressive (Which means not as good performance-wise), and doesn't usually hotplug. It is good for a balance between performance and battery life. May prevent the 'Screen of death' as well, since it doesn't hotplug.
HotplugX:
Its basically a smarter Hotplug, to my knowledge, it shuts off the second core much faster, and is a little bit smarter with CPU scaling and power efficiency.
LulzActive:
Based off of the Smartass and Interactive governor(s), the newer version of this Governor gives more control to the user, and he CPU frequency parameters (Ask for a description if you need one) are smarter. Smart at scaling both up and down.
Smartass:
Based off of the Interactive Governor, this is an older version, but this Governor is (or was) one of the smartest Governors, and is smart with performance and battery. More below.
SmartAssV2:
A re-thought version of the original Governor. This one aims for ideal frequencies, meaning it makes up its own frequences in order to meet the requests the CPU needs. Scales down the CPU extremely fast once the screen is turned off, meaning you will get amazing standby times. No upper limit for the CPU frequencies in both the screen on and screen off state(s). (If you want a better detailed explanation of that, please ask.)
Lionheart:
Conservative-based governor off of Samsung update3 source (Line copied directly from a guide, thank you 'Amal Das'), scales aggressively. This Governor is strictly for performance.
BrazilianWax:
Similar to smartassV2, the only real difference is, it scales more aggressively than SAv2 does, which reduces battery life, while improving performance.
SavagedZen:
Based off of SmartassV2, similar to BrazilianWax, but this Governor tends to favor battery over performance. From personal experience, I can say it does a great job of doing so.
Scary:
Conservative-based Governor with some smartass features. Ramps speed up one at a time, and ramps speed down one at a time (ask for description if you don't understand). Caps your screen off speed at 245MHz. Scales just like conservative would. This Governor is more for battery life than performance.
Sakuractive
A governor based off of hotplug and ondemand. The phone hotplugs (when it can) when the screen is on, and can be described as a 'hybrid' of hotplug and ondemand
OnDemandPlus
A governor based off of OnDemand and Interactive. It provides a balance between performance, and saving battery.
DynInteractive
A dynamic interactive Governor. This Governor dynamically adapts it's own CPU frequencies within your parameters based off the system(s) load.[/SIZE]
Advanced CPU Governor settings:
I got most of my information from this thread.
Sampling rate:
Microsecond intervals the governor polls for updates. Assists in the Governor determining whether or not to scale up or down in frequency.
Up threshold:
Defines the percentage from 1 to 100 (percent). Happens less often when clocked at a lower speed, overclocks when you get up into higher CPU frequencies. Using a Governor such as OnDemand prevents it from overclocking nearly 100% of the time.
Ignore nice load:
If you set the value to '1' the Android system will ignore 'nice' loads when the CPU Governor scales up or down.
'Nice' load:
When you turn a process into a 'nice' load, it prevents low activity processes randomly becoming high priority processes, which prevents lag. What a 'nice' load is, is how it handles processes. You can 'Re-Nice' processes, and re-set how processes are determined, based on your current processes that you have. Which helps eliminate lag due to processes being re-prioritized.
Frequency Step(s):
Determines how much the Governor will increase, or decrease, based on your CPU speeds. *This doesn't apply to some Governors
I/O schedulers:
Deadline:
Set to minimize starving of requests. In other words, it is designed to handle system requests as quickly as possible.
Noop:
It handles requests in a basic 'first in, first out' order. So any requests that come in, will also be the first to be executed.
SIO:
A mix between Noop and Deadline. Basic process/request merging. One of the most reliable schedulers out there.
BFQ:
Gives each request a time budget. If the request is not met by the time it is given, the request is skipped. Smarter than the CFQ governor.
CFQ:
'Completely Fair Queuing' scheduler. Scales its requests in an effort to insure smooth task handling. Attempts to give each request equal I/O bandwidth. Typically, lag happens with this scheduler due to the effort of competing tasks on the disk because it tries to give equal bandwidth amongst all requests.
FIOPS:
Relatively new. No I/O seek time, ( potentially better for performance), balanced read/write times, one of the smarter I/O schedulers
ROW:
Read Over Write. It will cause better read times for pictures/media, but when transferring data/installing apps, significant reduction of performance will be present.
V(R):
Best for benchmarks due to performance of requests, but is considered unstable due to random drops in performance. Semi-based off of the CFQ scheduler.
FIFO:
Takes each process in one by one, fair process queuing, balanced queue handling as well, processes go in and out in a numerical fashion.
TCP Congestion Avoidance Algorithms:
Tahoe:
Limits unknown packets being received. Limits the congestion window, and reset itself to a slow-start state.
Reno:
Basically the same as Taho, but.. if 3 of the same packets are received, it will halve the window, instead of reducing it to one MSS. It changes the slow start threshold equal to that of the congestion window.
Vegas:
One of the smoothest (next to cubic), it increases the timeout delay for packets, which allows more to be received, but at a higher rate. It also has set timeouts, which helps with speed because it's constantly being refreshed.
Hybla:
Penalizes connections that use satellite radio. Not usually used with phones.
Cubic:
One of the best, most recommended TCP options available. Less aggressive, Inflects the windows prior to the event. Used in Linux.
Westwood:
A newer version of Reno, and another commonly used one. It controls parameters better, helping out streaming and overall quality of browsing the internet. One of the most 'fair' algorithms out there, and is one of the most efficient algorithms to date.
CPU Governor recommendations:
Performance: Use Wheatley, or Performance.
Battery life: Use lagfree, Hotplug, PegasusQ, InteractiveX, or Sakuractive.
A fine balance: Use SmartassV2, Hotplug, or Sakuractive at less aggressive CPU frequencies.
Android tips:
Developer options:
Go to settings>build number... And tap 'build number' 7 times, go back, and you have now enabled developer options.
Force GPU rendering:
What it does is, it force enabled 2D drawing (such as scrolling, and anything non-game/app related) to the Graphical Processing Unit, instead of the Central Processing unit. What does/can this do? It has the potential to save battery life, and takes some of the load off of your CPU, which increases overall smoothness and reduces lag.
Keeping WiFi on during sleep:
What it does is, as this ^ suggests, keeps WiFi on while your phone is awake. To enable this, (and there are many ways.. I'll give you the way I'd do it.) Go to settings>WiFi>WiFi settings (3 vertical dots)>Advanced settings>keep WiFi on during sleep.. And set it to 'always' or.. You can use tricksterMOD and enable that via the GUI (Graphical User Interface)
WiFi Supplicant Scan Interval:
Before you freak out, I will give you what it means. What it means is this: how often your phone scans for a WiFi signal. Typically, it is 15 seconds. The recommended number is 300. To change it, you can typically find it in the build.prop manually edit it on your computer, or use an app such as ES file explorer and run it as root. Go to build.prop and look for: wifi.supplicant_scan_interval=x. And change x (usually 15) to 300, save, exit, and reboot. Please note it is not available with some ROMs that are driven towards a stock-ish feeling. Such as CM ROMs, or any derivative of that ROM.
Tips to get better battery life:
Turn off sync, location, Bluetooth when you're not using it, along with WiFi and data, don't use app-killer apps, lower CPU frequencies, and change your Governor to something less aggressive if you don't use it for heavy gaming.
Status bar with 1 finger, panel with 2:
If you want to access the tile settings quicker. Drag your status bar down with two fingers. If you want to bring down the status bar, touch the top of your screen and slide your finger down.[/I]
Autobrightness sucks!!:
Download an app called 'lux' and use that app. It'll take of any problems you're having, plus it'll save battery.
Changing your phones screen density:
In your build.prop, there is a line of code that looks like this: ro.sf.lcd_density=320, change it to 240 for a tablet-ish feel. Don't go under 160 though, you'll have endless bootloops
Change your bootanimation:
Go to system/media, you'll see bootanimation.zip, replace it with your desired bootanimation, change permissions to r-w-rr (read-write-read-read), and reboot. (Assuming you're doing this on your phone)
Block ads:
Download an app called 'adblock' on the play store, run it normally, accept the SU request, hit 'skip' and run the program, exit out, and reboot!
4x MSAA:
4 times MultiSample Anti-Aliasing. What this does is smooths out edges in apps that support AA. It makes your game look better, enhances graphics, but has the potential to degrade performance due to the screen enhancement. To enable this, go to settings>developer options>and check the box that says 'Force 4x MSAA'
zRAM:
Avoids disk paging, compresses your RAM. Disk paging means the way your phone saves temporary data. It helps with fragmentation of your disk and the physical space, which, over time, keeps speed stable and prevents any system slowdowns.
Explanation of TricksterMOD Settings:
General:
TCP:
Affects download speed
Scheduler:
How your system responds to, and handles tasks
Readahead:
How far ahead your internal SD caches when you put stuff on it
Frequency profile:
Save your frequencies
Min:
Minimum screen on time
Max:
^Opposite of minimum
Max screen off:
Max screen off frequency
Governor:
How your CPU essentially scales
Specific:
Wifi high performance:
Keep wifi on when the screen is off
Content adaptive brightness:
Better whites at low screen
Force fast charge:
Fast charge when your phone is hooked up to your PC/whatever
Group task:
Equally distribute loads amongst the CPUs
High performance sound:
Better sound
Headphone volume boost:
Boost the headphone volume for louder audio
Touch wake:
Touch your phone after you turn the screen off, and itll turn it back on
Vibrator strength:
Set the strength of the vibration of your phone
FSYNC:
When disabled, provides faster writing (not reading) of files with the risk of data loss if the phone crashes or is shut down improperly. (Thanks renaud)
Temperature limit:
How high your phones temperature can get before your phone reacts
Temp. throttle:
Enable the temperature limit
GPU OC:
Graphical Processing Unit overclock
MPU:
Mathematical Processing Unit
zRAM:
RAM compression to speed up your phone
*Leave on Core, IVA, and MPU
Voltages:
Set the voltages of each CPU frequency.​
Feel free to 'thank' me for this, but.. it isn't expected.

Little outdated.
Will update as time goes on.

thanQ vvvery much!!
very useful thread..
can i ask you something?
my phone is very fast and responsive sometimes.. but if i keep screen off for some hours, after turning on when i click on an app (even if it's running on background) it'll
launch with some delay.. i don't like it at all..
i don't play heavy games.. but i need my phone response each touch and launch certain app as quick as possible.. which Governor, Scheduler do you suggest?

Dark Fear said:
thanQ vvvery much!!
very useful thread..
can i ask you something?
my phone is very fast and responsive sometimes.. but if i keep screen off for some hours, after turning on when i click on an app (even if it's running on background) it'll
launch with some delay.. i don't like it at all..
i don't play heavy games.. but i need my phone response each touch and launch certain app as quick as possible.. which Governor, Scheduler do you suggest?
Click to expand...
Click to collapse
Raise your min screen-off frequency

Thanks for taking the time to put this together, you really have outdone yourself. :thumbup:
Sent from my Nexus 4 using XDA Premium 4 mobile app

yeah little outdated but very informative thread for many new android explorers to understand things better. :highfive:

just a suggestion: UI card like in google now, keep

aLNG said:
just a suggestion: UI card like in google now, keep
Click to expand...
Click to collapse
I don't follow...
Sent from my Galaxy Nexus using XDA Premium 4 mobile app

MBQ_ said:
I don't follow...
Sent from my Galaxy Nexus using XDA Premium 4 mobile app
Click to expand...
Click to collapse
i will give you a prototype what i mean by User Interface (UI) card later

This is great, clears up many concepts! Good work bro!

feedtheducks said:
This is great, clears up many concepts! Good work bro!
Click to expand...
Click to collapse
Myyy pleasure.
Have another version of the CPU Guide app coming soon too.
Sent from my Galaxy Nexus using XDA Premium 4 mobile app

Interactive governor highly efficient profile for SmartPack Kernel - Android N/O/P

Hello all.
After about a month of researching and testing with the Galaxy S5, I'm finally happy with my SmartKernel profile, with the interactive governor carefully tuned, using known resources and countless trials and errors, as well as other various tweaks, like VM and I/O scheduler, and decided to publish on it's own thread.
The main resources I've used for the Interactive governor tuning includes the well known:
Android Modders Guide;
[GUIDE] Advanced Interactive Governor Tweaks; Buttery smooth and insane battery life! for Nexus 5X; and it's twin
[GUIDE] Advanced Interactive Governor Tweaks; Buttery smooth and insane battery life! for HTC Evo 4G.
First of all, this tweaks should be a little sensible to the ROM, kernel, apps, and other tweaks your using. Like, I just found out that Havoc pie style quicktile settings use way more juice then if I turn it off and go back to Oreo default. Bellow you will see the apps I mainly crafted this profile in mind.
For reference: I have a klte with latest Oreo Havoc installed, nano OpenGapps, Magisk and the SmartPack kernel. For apps I use Facebook lite, cause the normal app is just a big hog, whatsapp and instagram social apps. Chrome. I don't use the Google App or Greenify(uninstall/delete velvet). And play lots of games like Clash Royale, Star Wars Force Arena and Arena of Valor. BetterBatteryStats.
And a lot of random apps that normally don't stay on the background.
DESCRIPTION
On the SmartPack manager profile:
. HIghly Efficient Interactive Governor Tunables (most important part);
. No Touchboost or any other boost, only the governor dictates to CPU in which clock it should to be;
. Overclock disabled, but can be enabled at you will;
. No underclock, I do undervolt my CPU but this you need to find your specific device numbers, mine won't cut;
. LazyPlug Hotplug with all 4 cores on all the time (better performance while using and battery savings while at idle);
. I/O Schedulers: ZEN (the L-Speed profile complement this part, with it's scheduler tunables);
. READ-AHEAD internal 1024kb (for 16GB or more) and external 512 kb (for my 8GB SDCard, adjust accordingly to yours SD Card size conform described here
. Adreno Idler disabled: it doesn't make any effect;
. Speaker Driver Leakage disabled and Boeffla Sound enabled with 0 gain as it does make a difference, at least with ViperFX magisk module installed;
. Screen minimum RGB set to 1 (0 won't stick), for a darker dark on our AMOLED, plus some tweaks;
. Led blinking fade enable;
. VM tweaks: dirty_ratio 30 and dirty_background_ratio 15; for minor battery improvement, with a perceptible lower termperature/cpu usage and almost imperceptible performance hit;
. VM tweaks: page-cluster 1; for better multitasking/memory management
. VM tweaks: oom_dump_tasks 0; disable depuration of dumping tasks, less cpu needed.
. LMK values: 32 48 64 128 176 208 (MBs)
L-Speed Profile
. Logging and I/O stats disabled;
. Animations speed set to 0.25x;
. System battery save trigger at 20%;
If you need to provide or read logs, enable logging and i/o stats back on l speed; i/o stats and oom_dump_tasks 1 on smartpack manager
INSTALLATION
Unzip the attached file and import with SmartPack Manager:
The attached profile should be imported, applied and marked as to run "On Boot" to make effect. It will only work with SmartPack Manager and Kernels for both Nougat and Oreo, maybe even Pie. Just try it, and report back. If you wanna fine tune it. You need to use an app or enable the "show cpu clocks" option if your rom supports it (like Havoc, RR and many more), and monitor at which frequencies the lags happens, while doing the jobs you want the CPU to be efficient at. And mainly tweak the target_load according, maybe above_high_speed delays of 1,7GHz clock and above. You need to read the guides more in-dept too see exactly how to do it, but I'll paste here the most important parts on how to tweak this settings more to your Galaxy S5, with your particularly apps and ROM:
soniCron said:
Optimize Idle Frequency
Now that you've got the base configuration, we need to tweak it so that the CPU stays at your efficient idle frequency (384Mhz in this case) without spontaneously jumping when your phone is actually idle. To do this, open a CPU monitor that displays the current core frequencies (I like CoolTool, but you can use what you like as long as it doesn't significantly impact the CPU use--you're best off using a passive monitor and checking the results after 30-60 seconds of no activity), watch the frequencies and see how often they go above your efficient idle frequency when you're not doing anything at all, and adjust the following:
timer_rate - If your idle frequency is not being exceeded much, adjust this downward in increments of 5000 until it is, then increase it by 5000. If your idle frequency is being exceeded often, adjust this upward in increments of 5000 until your CPU primarily stays at or below your desired idle frequency.
above_highspeed_delay - Only if your timer_rate has matched or exceeded 50000 and still won't stay at or below your desired idle frequency most of the time, set timer_rate to 50000 and adjust the "20000" portion of the value upwards in increments of 5000 until the idle frequency has stabilized.
The lower these two values are, the more snappy/lag free your system will be. So try to get them as low as possible without the idle frequency being exceeded too much, as this inversely affects the snappiness and efficiency of your phone when you're not doing anything. Lower = snappier but uses more CPU when you're not doing anything (such as reading a webpage); higher = less snappy but stays in a power saving state more often reducing CPU use when you're not interacting with the device. These are the most critical in determining your idle power savings, so keep that in mind if you want the most battery life!
Enhance Task Responsiveness
Now use the efficiency and nominal clock rate correlations you made for your master clock rate list in the section above and adjust your frequencies to suit your usage patterns. For example, I had web page scrolling as my 710Mhz/864Mhz rates, so I will open a web page and scroll and see how everything feels. If it feels sluggish, I will increase all the references to "710000" in both above_highspeed_delay and target_loads upwards to the next available clock rate until that task is smooth. What you are looking for is constant poor/sluggish performance when the task you're testing for is using its highest CPU use. If the task becomes sluggish/stuttery as it winds down (such as a scrolling webpage slowing to a stop), we will address that next, so do not take that behavior into consideration as you adjust these values! If the task is smooth until (or after) it slows down, then you have reached your optimal clock rate and can move on.
If you need to exceed your nominal clock rate for a particular task, first measure it again just to be sure you had it correct. If you did indeed have it correct, leave it at your nominal clock rate and adjust the value after the colon next to the task frequency you're tuning downward in increments of 5. For example, if my setting of "864000:80" is still not sufficient, I will adjust it first to "864000:75", then "864000:70", and so on until the task is smooth. However, it almost certainly won't come to this, but if you reach ":50" and the task still isn't performing how you want, set it back to ":80" and increase the clock step once more, then decrease the ":80" until it is smooth.
Do the same for each other frequency in your master clock rate list until you are satisfied. If you have chosen to use more than 2 primary clock rates, add them and use ":##" values between the two surrounding frequency values.
Fix Stuttering
Now that you have adjusted your frequencies for optimal high CPU use in each given task, you may notice some stuttering as the task winds down. (Such as a scrolling webpage slowing to a stop.) If this bothers you, you can tweak this at the expense of some (minor) battery life by adjusting min_sample_time up in increments of 5000 until you are satisfied.
If you have exceeded a value of 100000 for the min_sample_time setting and still are not satisfied, change it back to 40000 and increase (and re-optimize) your idle frequency by one step. This will impact battery life more, but less than if you were to keep increasing the value of min_sample_time.
Adjust High Load Clock Rates
You're almost done! Now you can leave everything as is and be satisfied with your amazing, buttery smooth, snappy experience, or you can optionally tweak things further to either increase the responsiveness of high load tasks (such as loading image previews in Gallery) or increase battery life somewhat.
Adjust the final delay value in above_highspeed_delay to suit your needs. The default ("150000") means that the CPU load at the highest set frequency (default "1026000") will have to be sustained for 150ms before it allows the load to go above that frequency. Increasing this value will prevent the CPU from reaching higher frequencies (which may be unnecessary) as often, saving battery life. This will come at the expense of burst-type high CPU load tasks. Reducing it will allow the CPU to reach higher frequencies more often, at the expense of battery life. However, adjusting this is probably unnecessary, as it will most likely not yield any perceptible difference in performance. It is recommended to leave this value at its default.
Click to expand...
Click to collapse
Besides CPU Voltage and Battery, all tabs on the manager are modified and tuned to achieve best performance, while having best efficiency possible. Is not a battery or a performance, but a efficiency profile.
Refer to this thread if you wanna undervolt your device with a well know secure margin for the CPU Snapdragon 801 2.5ghz MSM8974AC, which our Galaxy S5 contains:
[GUIDE] Snapdragon 805/801/800/600 Clock & Voltage (PVS bin) guide by HD2Owner I've managed to achieve much lower voltages then PSV15+ devices (refer to the sheets).
I also attached the excel spreadsheet I've made with all this thread information, both governor guide equations on target loads, undervolting guide findings, and made my own base calculations and settings. Feel free to use, modify, and discuss it with me. You will see that I based the most efficient clocks in an original thought about which ones are the most efficient, instead of plotting the differentials between voltages of each clocks, I did plotted the difference of the clock divided by voltage, which on itself should be how much voltage 1 mhz uses, on each clock rate. So, the higher the number, more speed each clock rate give us by voltage used. It's kinda complicated and idk if I explained it the right way, and even if it really makes sense under scrutiny, but I couldn't think why not myself, so, any inputs are welcome.
I own my thanks to all the following XDA fellows, without them, I could not have achieved this:
@sunilpaulmathew for the SmartPack Kernel which is the only kernel for the S5 that can turn that damned MPDecision off and SmartPack Manager;
@soniCron for both of the governos Guides;
@Saber for the Android Modders Guide which is immensely helpful.
CHANGELOGS
L-Speed Profile (download the app on PlayStore):
011118 lspeed profile
- first release
031118 lspeed profile
- Removed most tweaks, only left minor stuff, refer to the OP.
L Speed profile is not really needed, SmartPack will do 99% of the job.
SmartPack Manger Profile (download the kernel and the app here):
301018
- first release.
011118 smartpack profile:
- A few Interactive governor tweaks;
- Removed Virtual Memory and LMK tweaks, let it on default or use L-Speed to optimize, as it does a much better job then me.
031118 smartpack profile:
- Governor tunning: better high load management;
- Included back only 3 sane VM configurations, no more freezing, better cooling (less cpu needed, while performance barely took a hit)
- Sane LMK configurations, kills apps not being used faster, retain some multitasking while not let it slow down the device
081118 smartpack profile:
- target_load (no changes up to 1497600) ...1728000:89 1958400:91 2265600:95 -> ...1728000:88 1958400:90 2265600:95
- above_hispeed 20000 1190400:60000 1497600:64000 1728000:77000 1958400:84000 2265600:130000 -> 20000 1190400:60000 1728000:68000 1958400:79000 2265600:110000
- external storage read-ahead from 512 -> 2048 (because I've gone from a 8GB to a 32 GB SDCard, ADJUST YOURS ACCORDINGLY TO https://androidmodguide.blogspot.com/p/io-schedulers.html)
- cleaned unused and already default values from profile
101118 smartpack profile:
- Turned Alucard off, accidentally activated it with Lazyplug also enabled, not good!
- Managed to go 1 point higher on freq 1497 MHz, the 2 hotplugs enabled were messing with me trying to test this change before, also 1 point lower on the idle freq 268 MHz for smoother scrolling while still staying at freq 268 while idle. And some more high load optimizations now that I only got 1 hotplug enabled as it should always be.
- target_loads from 268800:29 ... 1497600:86 1574400:5 1728000:88 1958400:90 2265600:95 to -> 268800:28 ... 1497600:87 1574400:5 1728000:89 1958400:91 2265600:94
- above_hispeed 20000 1190400:60000 1728000:68000 1958400:79000 2265600:110000 -> 20000 1190400:60000 1728000:74000 1958400:82000 2265600:120000
- dirty_background_ratio 15 -> 10
221118 smartpack profile:
. Reverted new SmartPack Kernel v14r4 changes to Virtual Memory back to original default configurations, if you've have had reboots this should fix it, please report back here and/or the kernel's thread;
. More changes to Interactive governor aiming to optimize high load scenarios according to the profile philosophy:
. above_hispeed_delay 20000 1190400:60000 1728000:74000 1958400:82000 2265600:120000 -> 20000 1190400:60000 1728000:74000 1958400:80000 2265600:105000;
. Enabled fast charge configurations, set at 1200 mhA as I found it's a good charging speed without heating the phone too much on my hot city, nothing you can't change at your will.
241218 smartpack profile:
. Restored missing min_sample_time tunable since 081018 profile
. dirty_ratio 30 -> 25
. General cleanup
. Tested on Pie

@justjr
Nice work friend. Great to see that your finally open a place to share your findings. In my opinion, your profile should work on any klte device with minimum kernel support. I haven't seen much SmartPack specific stuff in your profile except some hotplug related things. So, if you make it as a shell script instead of KA/SP-Kernel Manager profile, it shall be beneficial for everyone. Anyway, as usual, I'll kang your changes to my kernel default profile

sunilpaulmathew said:
@justjr
Nice work friend. Great to see that your finally open a place to share your findings. In my opinion, your profile should work on any klte device with minimum kernel support. I haven't seen much SmartPack specific stuff in your profile except some hotplug related things. So, if you make it as a shell script instead of KA/SP-Kernel Manager profile, it shall be beneficial for everyone. Anyway, as usual, I'll kang your changes to my kernel default profile
Click to expand...
Click to collapse
I think this profile should work on original Kernel Adiutor, or any fork of it, shouldn't it?
It should work on any other kernel if the changes really stick, and uses the same paths, but MPDecision will mess with frequencies all the time. It would still follow the governor tunables anyway, but it will interfere with it and in the end will not gain too much efficiency out of it.
Actually I only state it is for SmartPack specifically because of the fact that is the only one I can disable MPDecision on our device, and because I included all the tweaks other then just governor tweaks.
Actually I'm kinda lazy right now, but I could do a shell script if any demand for it shows up.

justjr said:
I think this profile should work on original Kernel Adiutor, or any fork of it, shouldn't it?
It should work on any other kernel if the changes really stick, and uses the same paths, but MPDecision will mess with frequencies all the time. It would still follow the governor tunables anyway, but it will interfere with it and in the end will not gain too much efficiency out of it.
Actually I only state it is for SmartPack specifically because of the fact that is the only one I can disable MPDecision on our device, and because I included all the tweaks other then just governor tweaks.
Actually I'm kinda lazy right now, but I could do a shell script if any demand for it shows up.
Click to expand...
Click to collapse
Well, official KA (free version) doesn't allow to import profiles (paid feature), but all other mods does.
and yes, it is supposed to work on every klte device as long as the sysfs paths exist. Means it should work on any custom Kernel with lazyplug support (most of the other stuff are actually included in the stock kernel itself). Of course, the default settings provided by the kernel devs might conflict. e.g., as you said, MPDecision, although the line "stop mpdecison" in your profile will disable it. By the way, I'm not the only one who disabled mpdecision and relay on other hotplugs in this klte community

sunilpaulmathew said:
Well, official KA (free version) doesn't allow to import profiles (paid feature), but all other mods does.
and yes, it is supposed to work on every klte device as long as the sysfs paths exist. Means it should work on any custom Kernel with lazyplug support (most of the other stuff are actually included in the stock kernel itself). Of course, the default settings provided by the kernel devs might conflict. e.g., as you said, MPDecision, although the line "stop mpdecison" in your profile will disable it. By the way, I'm not the only one who disabled mpdecision and relay on other hotplugs in this klte community
Click to expand...
Click to collapse
Oh, really? Which one? I must had missed it. I've tested all kernels I could find. At least all the remotely up-to-date, like venom, tuned and boeffla kernels. I didn't see any option to change hotplugs on any. There were hotplug profiles, to keep cores online and stuff, but everyone of them keep changing min and max frequency at MPDecision will.

justjr said:
Oh, really? Which one? I must had missed it. I've tested all kernels I could find. At least all the remotely up-to-date, like venom, tuned and boeffla kernels. I didn't see any option to change hotplugs on any. There were hotplug profiles, to keep cores online and stuff, but everyone of them keep changing min and max frequency at MPDecision will.
Click to expand...
Click to collapse
Boeffla and Venom largely depends on MPDecision. However, as I remember correctly (on the basis of the code review, not from my experience, I never used it by myself), the Tuned kernel by @fbs disabled MPDecision upon booting to work well with its own Tuned hotplug.

sunilpaulmathew said:
Boeffla and Venom largely depends on MPDecision. However, as I remember correctly (on the basis of the code review, not from my experience, I never used it by myself), the Tuned kernel by @fbs disabled MPDecision upon booting to work well with its own Tuned hotplug.
Click to expand...
Click to collapse
I tested it too. And although he claims he uses hes own hotplug, it behave the same as boeffla and venom, it has the same profiles, and it does changes min and max freq out of my control.

justjr said:
I tested it too. And although he claims he uses hes own hotplug, it behave the same as boeffla and venom, it has the same profiles, and it does changes min and max freq out of my control.
Click to expand...
Click to collapse
no it doesn't change any freqs
it works by disabling or enabling cores, just that.
if any cpu reaches the maximum frequency, it enables one more core (as the other ones are already giving their best)
if any cpu reaches the minimum frequency too many times, it disables it (as it doesn't seem to be needed)
so in any moment you can have all 4 cores enabled or only 1. even with display on or off, it doesn't matter
mpdecision will NEVER let you use just 1 core, and it doesn't react as fast: battery hog

fbs said:
no it doesn't change any freqs
it works by disabling or enabling cores, just that.
if any cpu reaches the maximum frequency, it enables one more core (as the other ones are already giving their best)
if any cpu reaches the minimum frequency too many times, it disables it (as it doesn't seem to be needed)
so in any moment you can have all 4 cores enabled or only 1. even with display on or off, it doesn't matter
mpdecision will NEVER let you use just 1 core, and it doesn't react as fast: battery hog
Click to expand...
Click to collapse
Alright, sorry then, it seems my memories got clouded or something, as I've tested it about a month ago. I might go back any day just to test that. Thanks for giving us one more kernel option! :good:

UPDATE OP WITH
Description
Changelogs
New profile 011118, changelog:
. Few governor tweaks
. Removed Virtual Memory and LMK tweaks, let it on default or use L-Speed to optimize, it does a much better job then me
Also uploading the L-Speed profile I use so those who want to use it like I do, but you can choose any VM and LMK profile that fits your needs on the app. Just don't use the governor tuner because it will mess with my tunings, and l-speed governor tuning is a generic one for all devices, VM and LMK is OK to use generic tweaks, but not on governor.
@sunilpaulmathew I took a look at l-speed virtual memory and lmk profiles and they make incredible sense, take a look yourself, they may be what you need to put o that spectrum profiles, because above all they are device independent and do make a noticeable difference.

Is it valide for stock rom (6.0)?

lollazzo said:
Is it valide for stock rom (6.0)?
Click to expand...
Click to collapse
What kernel? It should work if the kernel have lazyplug or alucard hotplug, if is the late you just have to enable it.

Updates
SmartPack Manager Profile 031118:
. Governor tunning: better high load management;
. Included back only 3 sane VM configurations, no more freezing, better cooling (less cpu needed, while performance barely took a hit)
. Sane LMK configurations, kills apps not being used faster, retain some multitasking while not let it slow down the device
LSpeed Profile 031118:
. Removed most tweaks, only left minor stuff, refer to the OP.
L Speed profile is not really needed, SmartPack will do 99% of the job.
OP: descriptions for both profiles updated.

New profile.
I returned to Nougat, RR 5.8.5, same configs works awesomely and the device is cooler/faster then with Oreo. But still will works the same with both N/O and even Pie, not tested.
I also reinstalled Hearthstone as a high load app so I could tune the governor better for it, and up to 1490 MHz nothing is changed, and changed a bit target_loads and above_hispeed of the clocks above it so Hearthstone (and any other high load apps, or, using split screen with youtube) runs smoother/without lags and tasks like opening an app will finish faster, and also go back to a lower clock faster because of that. So, in the end it stays most of the time at lower clocks anyway, only difference is that it will jump faster when needed for less waiting time/lag.
Just to clarify, this is not suppose to waste battery, or drain it faster. As an efficiency profile the goal is to do the job you the want faster the possible, ramping up to the clocks that the jobs demands, without lags (or minimal lags) and go back to idle/lower clocks as soon as high clocks aren't needed anymore, so it don't overstay at a higher clocks then it's needed, very simple.
So, going to a high clock doesn't mean less battery life, finishing a job fast and going back to idle is the key to achieve more battery life, specially during deep sleep, when you really want your device go back to deep sleep fast, but also at any other time. Watching youtube, browsing and using low demand apps still uses the same clocks.
Also, on top of that you will spend more time USING the device instead of WAITING for it to finish a job. Battery life is very subjective, and SoT doesn't mean nothing IRL, I mean, are you spend that SoT waiting for a job to finish or to actually use the device?
081118 smartpack profile:
- target_load (no changes up to 1497600) ...1728000:89 1958400:91 2265600:95 -> ...1728000:88 1958400:90 2265600:95
- above_hispeed 20000 1190400:60000 1497600:64000 1728000:77000 1958400:84000 2265600:130000 -> 20000 1190400:60000 1728000:68000 1958400:79000 2265600:110000
- external storage read-ahead from 512 -> 2048 (because I've gone from a 8GB to a 32 GB SDCard, ADJUST YOURS ACCORDINGLY TO https://androidmodguide.blogspot.com/p/io-schedulers.html)
- cleaned unused and already default values from profile
File attached on OP.

I don't use SD card so what do I do?

razor17 said:
I don't use SD card so what do I do?
Click to expand...
Click to collapse
In that case nothing is needed, the configurations related to the absent sd card will not be applied.

Ok guys. I was wondering why my device was heating a lot more these last 2 days. Turns out both Alucard and Lazyplug were accidentally activated on 081119 profile. Turn one of them off and everything will be a lot better. Sorry for that. I will upload a new profile very soon.
edit:
101118 smartpack profile:
- Turned Alucard off, accidentally activated it with Lazyplug also enabled, not good!
- Managed to go 1 point higher on freq 1497 MHz, the 2 hotplugs enabled were messing with me trying to test this change before, also 1 point lower on the idle freq 268 MHz for smoother scrolling while still staying at freq 268 while idle. And some more high load optimizations now that I only got 1 hotplug enabled as it should always be.
- target_loads from 268800:29 ... 1497600:86 1574400:5 1728000:88 1958400:90 2265600:95 to -> 268800:28 ... 1497600:87 1574400:5 1728000:89 1958400:91 2265600:94
- above_hispeed 20000 1190400:60000 1728000:68000 1958400:79000 2265600:110000 -> 20000 1190400:60000 1728000:74000 1958400:82000 2265600:120000
- dirty_background_ratio 15 -> 10

I will give this a try. Hope it works well...

Yeah.
You know, try it and report back. I don't see any reports, so I assume is working well for people.
Any reports are welcome.
lentm said:
I will give this a try. Hope it works well...
Click to expand...
Click to collapse
Enviado de meu SM-G900M usando o Tapatalk

justjr said:
Yeah.
You know, try it and report back. I don't see any reports, so I assume is working well for people.
Any reports are welcome.
Enviado de meu SM-G900M usando o Tapatalk
Click to expand...
Click to collapse
No problems so far...greats for daily use..scrolling smoother than default..but pubg still laggy on lower res...may i know which rom are u using?

Interactive Governor Tweaks; Buttery Smooth And Insane Battery Life For Our S5

(If you are too lazy to read the whole article, head down to The Final Results section and use those values for your kernel but i don't recommend that.)
The Introduction
First of all i am not a pro or something i am just a noob, so if i did any mistake in this post then please let me know. This thread can highly improve your SOT without compromising with the performance. I will try to make this thread as shorter as i can. I was getting 1 hour of SOT on my S5 a few days back, then i discovered this thread. I recommend everyone to leave this thread and read that one because everything is way better explained there but i am writing this for our S5 separately. Other device users can also read this if they want a shorter and simpler version of that original one.
The Setup
I am using smartpack kernel manager to tweak kernel values and i will also use cool tool for some reason (will explain it later.). Open smartpack kernel manager and go to cpu and open CPU Governor Tunables. We are going to tweak these values one by one.
above_hispeed_delay
To understand what's best under a variety of tasks, we have to identify two types of load profiles: nominal clock rates and efficient clock rates.
Efficient Clock Rates
Efficient clock rates are CPU clock rates that are unique in that they are the most optimal frequency given the range of voltage requirements. If you map out the frequency jump and the voltage requirement jump between each of the available clock rates, you will find that occasionally the voltage requirement will jump significantly without the frequency jumping proportionally to the previous differentials. To check this i jumped to cpu voltage section in smartpack kernel manager. My values are:
300MHz=775mV
422MHz=775mV
652MHz=775mV
729MHz=775mV
883MHz=780mV
960MHz=790mV
1036MHz=800mV
1190MHz=820mV
As you can see my voltage was same till 729MHz then it increased by 5mV, So 729MHz is an efficient clock rate for me. Now the volage was increasing by the same rate of 10mV till 1036MHz, So 1036MHz is also an efficient clock rate. Because i am too lazy to do this for every frequency i did that till 1728MHz and these are the efficient clock rates for me:
729MHz, 1036MHz, 1267MHz, 1728MHz
Nominal Clock Rates
Nominal clock rates are the minimum CPU clock rates that perform a given task smoothly and without stuttering or lag. To find the nominal clock rate for a given task, turn on only the first CPU using the Performance governor and turn them both down incrementally until you find the minimum clock rate that works best for what you're trying to do, without introducing hiccups.
I really didn't understood the above method, i think because it was for a device with 2 cores but i knew that we don't need perfect values for this because we have to round up these values to our next near efficient clock rate.
So i figured out my own way: I turned off every hotplug and then turned off every core and changed the maximum frequency to the same as minimum (300MHz) and did every task by increasing the maximum frequency till i get the lag free experience. Figure out your nominal clock rates for atleast these tasks:
Idle
Web Page Scrolling
Video
Clock Rate Biases
Using the information provided above, figure out both your nominal clock rates for the tasks you perform most often and your efficient clock rates depending on your kernel/custom voltage settings. Now round up your nominal clock rates to the next near efficient clock rates, For example 652MHz was lag free for me for web page scrolling and the next near efficient clock rate is 729MHz. I got these values:
Idle=300MHz
Page Scrolling=729MHz
Video=1036MHz
App Loading=1267MHz
High Load Processing=1728MHz
The Setup
I won't explain all of the settings of the Interactive governor--there are plenty of summaries all around. (Go search now if you don't know what any of the settings for Interactive governor do.)
The above_highspeed_delay setting, for example, defines how long the governor should wait before escalating the clock rate beyond what's set in highspeed_freq. However, you can define multiple different delays that the governor should use for any specified frequency.
For example, we want the above_highspeed_delay as low as possible to get the CPU out of the idle state as quickly as possible when a significant load is applied. However, we don't want it to jump immediately to the fastest clock rate once it's gotten out of idle, as that may be overkill for the current task. Our target trigger (which you will later adjust to suit your system and usage profile), will begin at 20000μs. That means 20,000μs (or 20ms) after our idle max load has been reached, we want to assume idle has been broken and we want to perform an actual task. (We want this value as low as possible without false positives, because it is one of a few factors that determine how snappy and lag free the CPU's response is.)
But at this point we're not ready to take on a full processing load. We may just be briefly scrolling a webpage and don't need the full power of the CPU now that we've allowed it to break out of idle. So we need it to reach a particular frequency and then hold it there again until we're sure the load is justified before we allow it to push the frequency even higher. To do that, rather than just setting
above_highspeed_delay - 20000
we will instead use the format "frequency:delay" to set
above_highspeed_delay - 20000 729000:60000
"Waaaait... What does that do?!"
This tells the Interactive governor to hold out 20ms after our target load when it's at our highspeed_freq (which we're actually using as our idle frequency--not a burst frequency as originally intended), but then it tells the governor to hold for 60ms after it's reached 729Mhz. Once it has exceeded 729Mhz, it then has free reign to scale up without limitation. (This will be optimized with the target_loads setting in a minute.)
These settings are among the most important, because they limit the phone's clock rates when you are not interacting with it. If it needs to do something in the background, chances are it does not need to run full throttle! Background and idle tasks should be limited to the lowest reasonable clock rate. Generally speaking, if you're just looking at your phone (to read something, for example), you want the phone to use as little CPU power as possible. This includes checking in with Google to report your location or fetching some pull data or... whatever. Things that you don't need performance for.
My Values: 20000 729000:60000 1036000:150000 1267000:300000
Optimize Idle Frequency (timer_rate)
Now that you've got the base configuration, we need to tweak it so that the CPU stays at your efficient idle frequency (300Mhz in this case) without spontaneously jumping when your phone is actually idle. To do this, open a CPU monitor that displays the current core frequencies (I like CoolTool, but you can use what you like as long as it doesn't significantly impact the CPU use--you're best off using a passive monitor and checking the results after 30-60 seconds of no activity), watch the frequencies and see how often they go above your efficient idle frequency when you're not doing anything at all, and adjust the following:
timer_rate - If your idle frequency is not being exceeded much, adjust this downward in increments of 5000 until it is, then increase it by 5000. If your idle frequency is being exceeded often, adjust this upward in increments of 5000 until your CPU primarily stays at or below your desired idle frequency.
above_highspeed_delay - Only if your timer_rate has matched or exceeded 50000 and still won't stay at or below your desired idle frequency most of the time, set timer_rate to 50000 and adjust the "20000" portion of the value upwards in increments of 5000 until the idle frequency has stabilized.
The lower these two values are, the more snappy/lag free your system will be. So try to get them as low as possible without the idle frequency being exceeded too much, as this inversely affects the snappiness and efficiency of your phone when you're not doing anything. Lower = snappier but uses more CPU when you're not doing anything (such as reading a webpage); higher = less snappy but stays in a power saving state more often reducing CPU use when you're not interacting with the device. These are the most critical in determining your idle power savings, so keep that in mind if you want the most battery life!
Enhance Task Responsiveness
Now use the efficiency and nominal clock rate correlations you made for your master clock rate list in the section above and adjust your frequencies to suit your usage patterns. For example, I had web page scrolling as my 600Mhz rate, so I will open a web page and scroll and see how everything feels. If it feels sluggish, I will increase all the references to "600000" in both above_highspeed_delay and target_loads upwards to the next available clock rate until that task is smooth. What you are looking for is constant poor/sluggish performance when the task you're testing for is using its highest CPU use. If the task becomes sluggish/stuttery as it winds down (such as a scrolling webpage slowing to a stop), we will address that next, so do not take that behavior into consideration as you adjust these values! If the task is smooth until (or after) it slows down, then you have reached your optimal clock rate and can move on.
target_loads
Now here's where we get a little math-heavy to determine what the optimal target_load frequencies are for each clock rate. (Might want to bust out a spreadsheet to do the math for you if you're not using a Nexus 5X.)
We want to determine 2 values for every available clock rate: the maximal efficient load and the minimal efficient load. To make this determination, we need to bust out our calculators. (Or spreadsheets!)
We have to calculate maximal efficient load for our efficient clock rates only and minimal efficient load for the other frequencies.
For the maximal efficient load, we want to correlate a load value no higher than 90% of a given clock rate before it would be more efficient to jump to the next clock rate–to avoid overwhelming a particular rate while avoiding premature jumps to the next. For this value, we calculate it as:
(clock rate * 90) / next highest clock rate​
For example, the maximal efficient load for 729Mhz would be caluclated as:
(729000 * 90) / 883000 = 74.30% (rounded and normalized: 74)​For the minimal efficient load, we want to correlate a load value at which anything higher would be better served by a higher clock rate. To calculate this:
(1 - clock rate / previous highest clock rate) * -1​For example, the minimal efficient load for 422Mhz would be calculated as:
(1 - 422000 / 300000) * -100 = 40.67% (rounded and normalized: 41)​For our Galaxy S5, the maximal efficient loads are:
729:74
1036:78
1267:76
1728:79
For our Galaxy S5, the minimal efficient loads are:
300:0
422:41
652:55
883:21
960:9
1190:15
1497:18
1574:5
Using Optimal Loads
Now, you might be asking, "Why the heck did I do all this math?! WHAT IS IT GOOD FORRRR????!!!!"
See, for all of our nominal clock rates, we want the CPU to hang out on them for as long as possible, provided they're doing the job. For each frequency tagged as our nominal clock rate, we want to use the maximal efficient load in target_loads. For every other frequency, we want to use our minimal efficient load value.
We don't care about those other frequencies. We don't want the CPU to hang out in those states for very long, because it just encourages the device to be reluctant to jump to a higher nominal frequency and causes stuttering. We eliminate the desire for the governor to select those frequencies unless it is absolutely efficient to do so. For all the nominal clock rates, we want the CPU to hang out there... but not for too long! So we set those values to the maximal efficient load, so they can escape to the next nominal frequency before they overwhelm the current frequency.
All said and done, this reduces jitter and lag in the device while providing optimal frequency selection for our day-to-day tasks.
My Values: 98 422:41 652:55 729:74 883:21 960:9 1036:78 1190:15 1267:76 1497:18 1574:5 1728:79
Fix Stuttering (min_sample_time)
Now that you have adjusted your frequencies for optimal high CPU use in each given task, you may notice some stuttering as the task winds down. (Such as a scrolling webpage slowing to a stop.) If this bothers you, you can tweak this at the expense of some (minor) battery life by adjusting min_sample_time up in increments of 5000 until you are satisfied.
If you have exceeded a value of 100000 for the min_sample_time setting and still are not satisfied, change it back to 40000 and increase (and re-optimize) your idle frequency by one step. This will impact battery life more, but less than if you were to keep increasing the value of min_sample_time.
However, this step should not be necessary if you properly calibrated your maximal and minimal efficient loads!
The Final Results
I recommend you to read the whole article first and calculate everything on your own. It will be fun, trust me! Maybe you will find out better values than these.
above_highspeed_delay - 20000 729000:60000 1036000:150000 1267000:300000
boost - 0
boostpulse_duration - 80000
go_highspeed_load - 99
hispeed_freq - 1190400
min_sample_time - 80000
target_loads - 98 422:41 652:55 729:74 883:21 960:9 1036:78 1190:15 1267:76 1497:18 1574:5 1728:79
timer_rate - 50000
timer_slack - 80000
The Conclusion
I have achieved unprecedented performance, smoothness, snappiness, and battery life with the default settings I outlined above. However, your mileage may vary, as every phone, ROM, kernel, installed applications, etc are different. This is a very sensitive governor profile and must be tweaked to just meet the requirements of your system and your usage patterns!
If it is not optimally tuned, performance and battery life will suffer! If you're not seeing buttery smooth, snappy performance, you have not correctly tuned it for your system!! However, if you do have superb performance (and you tweaked the values conservatively and not in large steps), then you will also get the aforementioned battery life.
You may have noticed that i copied and pasted so much things directly from original post, without any changes. That's because there is nothing to change. I only changed some things that i thought are required to better understand this guide for our device.

Thanks a lot... but I cannot change the numbers for interactive frequencies in 5''s it jumps too high.

[KERNEL][11] Placebo Kernel - LOS 18.1 Undervolting

Changelog:
2021-06-06
-Merge to 54ffccbf053b5b6ca4f6e45094b942fab92a25fc
Disclaimer: I have no idea what I'm doing, I just copy pasted some stuff together and compiled the kernel. This kernel was only momentarily tested on an SM-G900T (klte). If there's a compatibility problem you will probably boot loop until you fix it. Undervolting can cause issues. You have been warned!
This is the LOS 18.1 kernel from https://github.com/LineageOS/android_kernel_samsung_msm8974/ with the KTOONSEZ undervolting control mods from https://github.com/alaskalinuxuser/...mmit/37664e51977ccd27563458526463f53c6be0490a
The gcc version is a 4.9 I got from this GitHub page:
https://github.com/Duhjoker/arm-linux-androideabi-4.9
Intro:
This kernel allows tweaking CPU voltages. We're interested in undervolting the CPU so it uses less voltage to operate. The extent you can undervolt your CPU is based on luck. While your CPU will run more efficiently with an undervolt, real-world benefits are sometimes hard to tell. For example, your phone may compensate for cooler operation by running at a higher speed more often. Any battery life benefits to undervolting this one part of the phone are ambiguous, it's really hard to test.
Prerequisites:
You will need root on your phone! If you don't have root you can get it by installing Magisk. First install Magisk's apk file in Android. Then rename the apk so it has a .zip file extension and leave it in your phone's storage.
Releases · topjohnwu/Magisk
The Magic Mask for Android. Contribute to topjohnwu/Magisk development by creating an account on GitHub.
github.com
Instructions:
0. Keep a copy of Magisk's .zip on your phone!
1. Download the latest *boot.img and place it in your phone's storage
2. Boot to TWRP recovery or the recovery you use
3. Tap Install -> Tap "Install Image" to toggle the button
4. Select boot.img and FLASH TO YOUR BOOT PARTITION
4a. If you use Magisk it's broken now. Tap "Install Zip" to toggle the button and flash Magisk's zip
5. Reboot
6. Install SmartPack Kernel Manager OR Kernel Adiutor and grant it root privileges. You may now tweak your CPU voltage in the app. Once you are happy with your settings use the "Apply on Boot" to make the settings permanent.
https://f-droid.org/en/packages/com.smartpack.kernelmanager/
https://f-droid.org/en/packages/com.nhellfire.kerneladiutor/
Note: The kernel does not persist. You will need to reinstall it after every LOS update.
(Not) Optional: Consider making a TWRP backup of your phone. Unstable undervolting can result in data loss.
Help, I'm boot looping/can't boot because of unstable undervolt:
Download your phone's particular LineageOS zip from https://download.lineageos.org/ and unzip it. Put the boot.img file on your phone and flash it to the BOOT partition in recovery.
Undervolting guide:
Not all two phones are the same. Look at your stock voltages or old forum posts for reference. The S5's SoC is the MSM8974PRO/MSM8974AC, marketed as the Snapdragon 801. Also see the binning info at the bottom of this guide to learn your phone's binning.
Open SmartPack and go to CPU Voltage in the menu. It will display a big list of CPU clock speeds and voltages. These are your stock voltages. Your goal is to lower them some amount without your phone crashing. On the top part of the app you can scroll to "Global Offset" and enter one number to lower all the voltages at once.
I recommend trying a -30 mV or -40 mV global offset first, it seems like most phones can handle this. After you set your undervolt you should test for stability before making it permanent. Here are some ideas:
-Use your phone as you normally would.
-Keep playing videos on your phone
-Try the stress test in the bottom of this guide
Do not daily drive your phone for work until you're reasonably sure your undervolt is stable. You don't want it to crash when doing something important.
Once you have a good global offset you can start tweaking individual CPU states to lower voltages even more. This can get really annoying since there are so many. If you want to fine-tune I recommend only giving special attention to the top speed (2457), the middle speeds (1574 in particular, but include everything up to 1267 if you have to), and the lowest speed (300.)
The average phone tends to spend the most time in those states so focusing on those will help save your sanity.
To set your undervolt permanently enable "Apply on Boot" and SmartPack will set the values when your phone starts.
Spotting an unstable undervolt:
If one or more CPU states are unstable your phone will suddenly hang, hard reboot, fast reboot or other anomalies. You will probably also see CPU problems in the logs. Do "su; dmesg" in a Terminal or "su;logcat" to see. The cure for a bad undervolt is not undervolting so much. It can be hard to tell which CPU states are unstable unfortunately, you may have to adjust all of them to be sure,
Tips:
-Undervolts can be hard to test for stability, so try to leave some overhead if you don't have all day. SmartPack/Kernel Adiutor lets you set a global offset if you only want a small UV!
-You can set unusually low voltages for 300 MHz. Its stock voltage is about 750-800 mV but it will usually work on 650 mV and go as low as 600 mV if you're lucky.
-Low freqs are usually better at getting undervolted than the top freqs
-Not all cores will run at the same freqs/voltages. Disabling most of your cores is a good way to prevent your phone from heating up during stress tests but may lead to instability when you reactivate all of your cores.
-Your phone's battery draining may spontaneously cause your undervolt to become unstable. Unfortunately you just have to make the UV less aggressive if this happens.
-Try not switch the governor. To change CPU behavior go to Settings > Battery >Battery Saver and Performance > Performance Profile and toggle the slider as you see fit.
I recommend using Balanced and switching to Quick when you need your phone to be faster.
Performance is very energy inefficient. It prevents all cores from parking and tries to peg at least some of them to top speed. One core performance can be better than quick but multi-core makes it very easy for the phone to throttle.
LOS uses Qualcomm's MPDecision hotplugger. Switching governors causes glitches MPDecision and prevent CPU cores from parking. If you really want to try out governor tweaks, you should disable MPDecision in SmartPack first. Disabling MPDecision will incur a battery life penalty since your CPU will no longer park.
Synthetic stress test:
Install Termux and run this one-liner to stress one core:
Code:
while true; do openssl speed -evp aes-256-gcm; sleep 15s; done
For 4 cores:
Code:
while true; do openssl speed -multi 4 -evp aes-256-gcm; sleep 15s; done
You can also use this test to compare performance or to observe thermal throttling. OpenSSL will return a performance score after each run.
Sample stock/undervolt values from my speed3-pvs9-bin-v1 SM-G900T:
{
"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"
}
Very minor LOS power saving tweaks that don't help very much but they're funny:
-Search "Backlight" in the settings and turn off the backlight for the Menu and Back keys.
-The battery/notification LED can be adjusted down to about 7% brightness
-LOS has several settings for turning off haptic feedback/vibrations. I turned them off for the touch keyboard and the Menu/Back keys.
SoC Binning Information:
Your phone's SoC is tested for quality and assigned a PVS number at the factory. For S5, it ranges from PVS0 (low quality) to PVS15 (high quality). Higher quality have lower stock voltages. Check by running these in a terminal:
Code:
su
cat /sys/module/clock_krait_8974/parameters/table_name
You can compare the bins here

boot loop

vlad3647 said:
boot loop
Click to expand...
Click to collapse
Which device do you use?
I left some default undervolts in the PVS tables because they didn't work for me, maybe it's causing the problem. I'll remove them and compile it again later.

Klte

I don't mind boot loop,I reinstall everything

vlad3647 said:
I don't mind boot loop,I reinstall everything
Click to expand...
Click to collapse
You can always fix the boot loop by flashing boot.img from the lineageos zip.
I compiled build PlaceboKernel05072021V2.img without modified PVS tables in the first post. Still works on my phone.
I uploaded a V3 as boot.img, I don't know if this makes a difference. Works on my phone.

I didn't know thanks

Thanks, is working great

Flashed the `boot.img` file itself; verified working on my G900P!

Merged changes (includes the sdcard related ones.)

can't change the values on the voltage. phone keeps on rebooting. using g900t
update: got it to work. testing in progress

Boatshow said:
Changelog:
2021-06-06
-Merge to 54ffccbf053b5b6ca4f6e45094b942fab92a25fc
Disclaimer: I have no idea what I'm doing, I just copy pasted some stuff together and compiled the kernel. This kernel was only momentarily tested on an SM-G900T (klte). If there's a compatibility problem you will probably boot loop until you fix it. Undervolting can cause issues. You have been warned!
This is the LOS 18.1 kernel from https://github.com/LineageOS/android_kernel_samsung_msm8974/ with the KTOONSEZ undervolting control mods from https://github.com/alaskalinuxuser/...mmit/37664e51977ccd27563458526463f53c6be0490a
The gcc version is a 4.9 I got from this GitHub page:
https://github.com/Duhjoker/arm-linux-androideabi-4.9
Intro:
This kernel allows tweaking CPU voltages. We're interested in undervolting the CPU so it uses less voltage to operate. The extent you can undervolt your CPU is based on luck. While your CPU will run more efficiently with an undervolt, real-world benefits are sometimes hard to tell. For example, your phone may compensate for cooler operation by running at a higher speed more often. Any battery life benefits to undervolting this one part of the phone are ambiguous, it's really hard to test.
Prerequisites:
You will need root on your phone! If you don't have root you can get it by installing Magisk. First install Magisk's apk file in Android. Then rename the apk so it has a .zip file extension and leave it in your phone's storage.
Releases · topjohnwu/Magisk
The Magic Mask for Android. Contribute to topjohnwu/Magisk development by creating an account on GitHub.
github.com
Instructions:
0. Keep a copy of Magisk's .zip on your phone!
1. Download the latest *boot.img and place it in your phone's storage
2. Boot to TWRP recovery or the recovery you use
3. Tap Install -> Tap "Install Image" to toggle the button
4. Select boot.img and FLASH TO YOUR BOOT PARTITION
4a. If you use Magisk it's broken now. Tap "Install Zip" to toggle the button and flash Magisk's zip
5. Reboot
6. Install SmartPack Kernel Manager OR Kernel Adiutor and grant it root privileges. You may now tweak your CPU voltage in the app. Once you are happy with your settings use the "Apply on Boot" to make the settings permanent.
https://f-droid.org/en/packages/com.smartpack.kernelmanager/
https://f-droid.org/en/packages/com.nhellfire.kerneladiutor/
(Not) Optional: Consider making a TWRP backup of your phone. Unstable undervolting can result in data loss.
Help, I'm boot looping/can't boot because of unstable undervolt:
Download your phone's particular LineageOS zip from https://download.lineageos.org/ and unzip it. Put the boot.img file on your phone and flash it to the BOOT partition in recovery.
Undervolting guide:
Not all two phones are the same. Look at your stock voltages or old forum posts for reference. The S5's SoC is the MSM8974PRO/MSM8974AC, marketed as the Snapdragon 801. Also see the binning info at the bottom of this guide to learn your phone's binning.
Open SmartPack and go to CPU Voltage in the menu. It will display a big list of CPU clock speeds and voltages. These are your stock voltages. Your goal is to lower them some amount without your phone crashing. On the top part of the app you can scroll to "Global Offset" and enter one number to lower all the voltages at once.
I recommend trying a -30 mV or -40 mV global offset first, it seems like most phones can handle this. After you set your undervolt you should test for stability before making it permanent. Here are some ideas:
-Use your phone as you normally would.
-Keep playing videos on your phone
-Try the stress test in the bottom of this guide
Do not daily drive your phone for work until you're reasonably sure your undervolt is stable. You don't want it to crash when doing something important.
Once you have a good global offset you can start tweaking individual CPU states to lower voltages even more. This can get really annoying since there are so many. If you want to fine-tune I recommend only giving special attention to the top speed (2457), the middle speeds (1574 in particular, but include everything up to 1267 if you have to), and the lowest speed (300.)
The average phone tends to spend the most time in those states so focusing on those will help save your sanity.
To set your undervolt permanently enable "Apply on Boot" and SmartPack will set the values when your phone starts.
Spotting an unstable undervolt:
If one or more CPU states are unstable your phone will suddenly hang, hard reboot, fast reboot or other anomalies. You will probably also see CPU problems in the logs. Do "su; dmesg" in a Terminal or "su;logcat" to see. The cure for a bad undervolt is not undervolting so much. It can be hard to tell which CPU states are unstable unfortunately, you may have to adjust all of them to be sure,
Tips:
-Undervolts can be hard to test for stability, so try to leave some overhead if you don't have all day. SmartPack/Kernel Adiutor lets you set a global offset if you only want a small UV!
-You can set unusually low voltages for 300 MHz. Its stock voltage is about 750-800 mV but it will usually work on 650 mV and go as low as 600 mV if you're lucky.
-Low freqs are usually better at getting undervolted than the top freqs
-Not all cores will run at the same freqs/voltages. Disabling most of your cores is a good way to prevent your phone from heating up during stress tests but may lead to instability when you reactivate all of your cores.
-Your phone's battery draining may spontaneously cause your undervolt to become unstable. Unfortunately you just have to make the UV less aggressive if this happens.
-Try not switch the governor. LOS uses Qualcomm's MPDecision hotplugger. Switching governors will glitch MPDecision and prevent CPU cores from parking. If you really want to try out governor tweaks, you should disable MPDecision in SmartPack first. Disabling MPDecision will incur a battery life penalty since your CPU will no longer park.
Synthetic stress test:
Install Termux and run this one-liner to stress one core:
Code:
while true; do openssl speed -evp aes-256-gcm; sleep 15s; done
For 4 cores:
Code:
while true; do openssl speed -multi 4 -evp aes-256-gcm; sleep 15s; done
You can also use this test to compare performance or to observe thermal throttling. OpenSSL will return a performance score after each run.
Sample stock/undervolt values from my speed3-pvs9-bin-v1 SM-G900T:
View attachment 5302815View attachment 5302817
Very minor LOS power saving tweaks that don't help very much but they're funny:
-Search "Backlight" in the settings and turn off the backlight for the Menu and Back keys.
-The battery/notification LED can be adjusted down to about 7% brightness
-LOS has several settings for turning off haptic feedback/vibrations. I turned them off for the touch keyboard and the Menu/Back keys.
SoC Binning Information:
Your phone's SoC is tested for quality and assigned a PVS number at the factory. For S5, it ranges from PVS0 (low quality) to PVS15 (high quality). Higher quality have lower stock voltages. Check by running these in a terminal:
Code:
su
cat /sys/module/clock_krait_8974/parameters/table_name
You can compare the bins here
Click to expand...
Click to collapse
LMAO imagine undervolting a 7 year old device...

ralovesoc said:
LMAO imagine undervolting a 7 year old device...
Click to expand...
Click to collapse
Are you here just to make a fun of something? That's rude.
Yes, it's a 7 years old 28nm CPU, which is obviously isn't as power efficient as modern ones. 28nm is huge by today's standards.
7 years ago, this phone came in a box with additional battery and a battery charger, because it was an issue even then. What's the problem in undervolting or underclocking the device when performance isn't a priority, to make it last longer?

To change CPU behavior go to Settings > Battery >Battery Saver and Performance > Performance Profile and toggle the slider as you see fit. I think this is how you're supposed to do it because changing governor settings directly causes glitches. Performance preset pegs most cores to top speed.
Garry58 said:
7 years ago, this phone came in a box with additional battery
Click to expand...
Click to collapse
Maybe in some markets but I don't think that was true. Have an ad that didn't age well.

Boatshow said:
Maybe in some markets but I don't think that was true. Have an ad that didn't age well.
Click to expand...
Click to collapse
Maybe only in EU? I don't know. I have 900F model. That ad is just typical Samsung ad. They're openly laughing at iPhone, but literally next year do the same thing with Galaxy S6. At this point, I don't think marketing team has any communication with development team.

Boatshow said:
You can always fix the boot loop by flashing boot.img from the lineageos zip.
I compiled build PlaceboKernel05072021V2.img without modified PVS tables in the first post. Still works on my phone.
I uploaded a V3 as boot.img, I don't know if this makes a difference. Works on my phone.
Click to expand...
Click to collapse
what do you mean V3?

@vlad3647 That was an old post, there is no V3 anymore. Now I name by date. Currently the latest is 06-06-2021_boot.img.

@Boatshow
Are you able to add some hotplug options to the kernel? Without all cpu cores stay online all the time, what of course means unnecessary energy wasting.

@v00d007 Not sure what you mean, the default hotplugger MPDecision still works with the modified kernel. If the cores stop parking it's probably because MPDecision is disabled or a CPU settings change caused it to glitch.
If you're talking about an alternative hotplugger fbs wrote one here. Nobody can compare it to MPDecision because that is closed source. I read several years ago that hotpluggers only save small percents over a few hours so I don't know if testing differences is worth trying.
tuned-kernel-S5/drivers/staging/tuned at ten · bemerguy/tuned-kernel-S5
Contribute to bemerguy/tuned-kernel-S5 development by creating an account on GitHub.
github.com
Maybe a hackjob you can do is compile the tuned plugger (or get the binary from the zip) and swap it out with the MPDecision binary. It should be at /system/bin/mpdecision or somewhere similar.

Boatshow said:
Not sure what you mean, the default hotplugger MPDecision still works with the modified kernel. ...
Click to expand...
Click to collapse
Well, the problem for me is that in kernel adiutor the category "hotplug" doesn't show up. And category "cpu" shows that no core goes offline at any time. If MPDecision was active, 1 or 2 cores should go offline from time to time if there's no load. Normally I use Intelliglug and for me it makes a noticable difference in battery cycles (~10-15%).