Related
I take no credit of these codes. All i did is create a patch against with the leo kernel tree.
cpufreq: interactive: New 'interactive' governor
New interactive governor.
This governor is designed for latency sensitive workloads, UI interaction for
example.
Advantages:
+ significantly more responsive to ramp cpu up when required (UI interaction)
+ more consistent ramping, existing governors do their cpu load sampling in a
workqueue context, the 'interactive' governor does this in a timer context, which
gives more consistent cpu load sampling.
+ higher priority for cpu frequency increase, rt_workqueue is used for scaling
up, giving the remaining tasks the cpu performance benefit, unlike existing
governors which schedule rampup work to occur after your performance starved
tasks have completed.
Existing governors sample cpu load at a particular rate, typically
every X ms. Which can lead to under powering UI threads when the user has
interacted with an idle system until the next sample period happns.
The 'interactive' governor has a different approach. Instead of sampling the cpu
at a specified rate, the governor will scale the cpu frequency up when coming
out of idle. When the cpu comes out of idle, a timer is configured to fire
within 1-2 ticks. If the cpu is 100% busy from exiting idle to when the timer
fires then we assume the cpu is underpowered and ramp to MAX speed.
If the cpu was not 100% busy, then the governor evaluates the cpu load over the
last 'min_sample_rate' (default 50000 uS) to determine the cpu speed to ramp down
to.
There is only one tuneable for this governor:
/sys/devices/system/cpu/cpufreq/interactive/min_sample_rate:
The minimum ammount of time to spend at the current frequency before
ramping down. This is to ensure that the governor has seen enough
historic cpu load data to determine the appropriate workload.
Default is 5000 uS.
Click to expand...
Click to collapse
2.6.32-sched-bfs-318.patch.zip: is the patch is downloaded from official BFS site.
oc_uv_ab.patch.zip : this patch includes under volt, overclocking (upto 1.3GHz, any frequency above 1.15G is unstable on some of HD2s) and audio boost.
how does it work?
Sounds great. Maybe someone can integrate this into a kernel?
thanks for this!!
How to apply patch
I could really use the audio boost. Is there anyway you could explain how to apply the patches. Or is it possible you could apply them and post the patched kernel files? Thanks.
Would this actually have an improving effect on the touchscreen being unresponsive from time to time?
Hello,
Would it be possible to add the newer versions for oc_uv_ab.patch and interactive governor or I just don't know how to use GIT to well?
I don't have too much experience with C++, PHP dev here , and I'd like to compile my own kernel from the official GIT + change the MAC of the build to my own HD MAC + maybe some other small changes (adjust max freq and such).
Thank you very much for your hard work.
Kind regards.
dlsniper said:
change the MAC of the build to my own HD MAC + maybe some other small changes (adjust max freq and such).
Thank you very much for your hard work.
Kind regards.
Click to expand...
Click to collapse
This would be great.If someone can guide us how to make our wifi mac address
dolby71 said:
how does it work?
Click to expand...
Click to collapse
Just sit down and relaxed lol,michelle (michyprima kernel) or the topic starter build them i guess in few days
Whoops,nevermind,old topic i see
I've implemented a generic cpufreq range regulation based on a previous work proposed by newmail here.
With "generic" I mean that it can work with any cpufreq governor, the whole logic is implemented in the core cpufreq subsystem using early_suspend hooks.
How does it work?
Without this patch set applied, using for example the ondemand governor, the cpu frequency ranges always between 200MHz to 1200MHz (without overclocking/underclocking the device) that are the min and the max frequency supported by the processor.
With this patch set applied the frequency is regulated in the range [min ... max/2] when the screen is off and [max/2 ... max] when the screen is on. If the cpu doesn't support exactly max/2 an appropriate frequency is chosen, as close as possible to the theoretical value (for the GT-I9100 it's 500MHz).
Advantages
This forces background apps to always run at lower frequencies, reducing the power consumption when the phone is not used interactively, and, at the same time, boost the cpu at max speed when used interactively. IOW, it's faster and it drains more battery life when the phone is used interactively, and the battery last longer when the phone runs background tasks.
An additional side-effect using 'ondemand' is that the heuristic always works with shorter ranges, so the cpu ramps up / down faster to the target frequency. The feeling is that everything seems smoother and more responsive. I only tested ondemand for now, but the same logic should apply to the other available governors as well.
Source code
I like to post source code, more than binaries, so in attach you can find only the patches that implement this feature. The patches can be applied on top of the original Samsung kernel - Update2. These patches are also included in my kernel tree on github.
Patch set description
The 1st patch 0001-cpufreq-frequency-regulation-based-on-screen-on-off-.patch, implements the dynamic cpufreq range regulation logic. This patch is totally generic, so theoretically you can use it with any Android device.
The 2nd patch 0002-cpufreq-do-not-forget-min-max-clock-frequency-on-cpu.patch is required by multicore systems with cpu hotplugging enabled. It allows to resume the right frequency range on a cpu when it goes offline and then back online.
The 3rd patch 0003-mach-s5pv310-cpufreq-800MHz-sleep-death-fix.patch is specific for the GT-I9100 hardware. It's the 800MHz sleep death fix: the hardware requires to suspend the cpu always at 800MHz, so with the dynamic cpufreq range regulation this is always needed, independently of the particular governor you're using.
The 4th patch 0004-pm-hotplug-do-not-consider-frequency-in-the-cpu-hotp.patch is specific for the GT-I9100 hardware. It makes the cpu hotplug heuristic independent of the cpu frequency; this is required to properly offline the secondary cpu when screen is on _and_ the dynamic cpufreq range regulation patch is applied.
The 5th patch 0005-pm-hotplug-disable-secondary-cpu-auto-hotplug-when-s.patch is specific for the GT-I9100 hardware. It always sets the secondary cpu offline when the screen is off.
The 6th patch 0006-mach-s5pv310-cpufreq-smooth-scaling.patch is specific for the GT-I9100 hardware. It is needed to fix a wrong behavior with governors that run at a fixed frequency (like 'performance', 'powersave' or 'userspace'). Basically, the low-level driver doesn't allow to switch from a very low frequency to a very high frequency, so in some cases the actual cpu frequency can be different than the frequency requested by the higher layers. This fix introduces a smooth scaling mechanism in the low-level driver that allows to switch to the target frequency incrementally in multiple steps.
Everything is transparent to the higher layers, so in this way we are sure that the actual cpu frequency is always the same value requested by the cpufreq governor. See also the commit in my kernel on github.
NOTE: the last patch (0006-mach-s5pv310-cpufreq-smooth-scaling.patch) is a fix for the low-level cpufreq driver of the GT-I9100 that should be _always_ applied IMHO, even without the dynamic cpufreq range regulation patch.
ChangeLog
v2 -> v3
fix a wrong behavior (cpu stuck at 800MHz) with fixed-frequency governors (i.e, performance, powersave, or userspace).
v1 -> v2
fix: allow to offline the secondary cpu when screen is on
always disable the secondary cpu when screen is off
Looks promising, hope it works well, will sure try it out, but some kernels has almost the same built in...
Great work!
Uploaded a new version of the dynamic frequency range regulation patch.
There're two additional patches in the patch set:
The first patch (0004) is a fix that allows to properly offline the secondary cpu when screen is on.
The other patch (0005) applies the same concept of the dynamic frequency range regulation to the secondary cpu hotplugging: when the screen is off also the secondary cpu (cpu1) is kept offline, when the screen is on the secondary cpu is turned on/off depending on the load on the primary cpu (cpu0).
thanks a lot for your hard work.apply patch without problem, good for battery life.
a developper like me is very happy to have a master developper like you.
thank you very much it looks cool.
a noob question, how will I apply this zip just CWM or what?
arighi: one thing i don't like the freq min is set to 500 mhz . it is too high.
edit:excuse when screen off the freq reach 200 mhz .it's ok perfect and cpu1 is well disable when screen off
edit2: yay1974 ,apply all patch in the order they are all necessary. but this patch is only for developper who compil his kernel.
pixiebob said:
arighi: one thing i don't like the freq min is set to 500 mhz . it is too high.
edit:excuse when screen off the freq reach 200 mhz .it's ok perfect and cpu1 is well disable when screen off
edit2: yay1974 ,apply all patch in the order they are all necessary. but this patch is only for developper who compil his kernel.
Click to expand...
Click to collapse
hmm i see i wish you had a cwm flashable file for this to apply
yay1974: if you wish you can try my own kernel i have apply patch from this thread and some other good stuff(like sched autogroup, etc...).i obtain more 4000 quadrant:
flash with odin or heimdall:
http://www.megaupload.com/?d=TCQFKISK
commit:
https://github.com/pixiebob/pixie-kernel/commits/master
pixiebob said:
yay1974: if you wish you can try my own kernel i have apply patch from this thread and some other good stuff(like sched autogroup, etc...).i obtain more 4000 quadrant:
Click to expand...
Click to collapse
pixiebob, I see you've applied also the CONFIG_FILE_SYNC_DISABLE patch. Be careful to enable this, it may cause loss of data if applications crash in unsafe ways. Probably if you run quadrant in a kernel with CONFIG_FILE_SYNC_DISABLE=y you'll get about 4500-4600. But actually you're just cheating.
what kernels have this built in (if any)
cheers
@arighi great job on the patches... looking forward to more cool stuff from you.
Great patch, thank you.
pongster said:
@arighi great job on the patches... looking forward to more cool stuff from you.
Click to expand...
Click to collapse
Hey pongster, you are always hanging around here!! When can we see your rom running all tweaks and fixes... looking forward to it...
Sent from my GT-I9100
arighi said:
pixiebob, I see you've applied also the CONFIG_FILE_SYNC_DISABLE patch. Be careful to enable this, it may cause loss of data if applications crash in unsafe ways. Probably if you run quadrant in a kernel with CONFIG_FILE_SYNC_DISABLE=y you'll get about 4500-4600. But actually you're just cheating.
Click to expand...
Click to collapse
thanks i will be careful but until by now i didn't have crash
great patch! I was also working on something similar but your patch is so complete that I gave up working and used yours
just a perfect patch!
pongster said:
@arighi great job on the patches... looking forward to more cool stuff from you.
Click to expand...
Click to collapse
Hey Sar ! You here ?!? .. didnt know ... cook some MIUI stuff dude ... I'll help out
v-b-n said:
Hey Sar ! You here ?!? .. didnt know ... cook some MIUI stuff dude ... I'll help out
Click to expand...
Click to collapse
cooking something up... not a MIUI based one though...
PM me
arighi said:
I've implemented a generic cpufreq range regulation based on a previous work proposed by newmail here.
With "generic" I mean that it can work with any cpufreq governor, the whole logic is implemented in the core cpufreq subsystem using early_suspend hooks.
How does it work?
Without this patch set applied, using for example the ondemand governor, the cpu frequency ranges always between 200MHz to 1200MHz (without overclocking/underclocking the device) that are the min and the max frequency supported by the processor.
With this patch set applied the frequency is regulated in the range [min ... max/2] when the screen is off and [max/2 ... max] when the screen is on. If the cpu doesn't support exactly max/2 an appropriate frequency is chosen, as close as possible to the theoretical value (for the GT-I9100 it's 500MHz).
Advantages
This forces background apps to always run at lower frequencies, reducing the power consumption when the phone is not used interactively, and, at the same time, boost the cpu at max speed when used interactively. IOW, it's faster and it drains more battery life when the phone is used interactively, and the battery last longer when the phone runs background tasks.
An additional side-effect using 'ondemand' is that the heuristic always works with shorter ranges, so the cpu ramps up / down faster to the target frequency. The feeling is that everything seems smoother and more responsive. I only tested ondemand for now, but the same logic should apply to the other available governors as well.
Source code
I like to post source code, more than binaries, so in attach you can find only the patches that implement this feature. The patches can be applied on top of the original Samsung kernel - Update2. These patches are also included in my kernel tree on github.
Patch set description
The 1st patch 0001-cpufreq-frequency-regulation-based-on-screen-on-off-.patch, implements the dynamic cpufreq range regulation logic. This patch is totally generic, so theoretically you can use it with any Android device.
The 2nd patch 0002-cpufreq-do-not-forget-min-max-clock-frequency-on-cpu.patch is required by multicore systems with cpu hotplugging enabled. It allows to resume the right frequency range on a cpu when it goes offline and then back online.
The 3rd patch 0003-mach-s5pv310-cpufreq-800MHz-sleep-death-fix.patch is specific for the GT-I9100 hardware. It's the 800MHz sleep death fix: the hardware requires to suspend the cpu always at 800MHz, so with the dynamic cpufreq range regulation this is always needed, independently of the particular governor you're using.
The 4th patch 0004-pm-hotplug-do-not-consider-frequency-in-the-cpu-hotp.patch is specific for the GT-I9100 hardware. It makes the cpu hotplug heuristic independent of the cpu frequency; this is required to properly offline the secondary cpu when screen is on _and_ the dynamic cpufreq range regulation patch is applied.
The 5th patch 0005-pm-hotplug-disable-secondary-cpu-auto-hotplug-when-s.patch is specific for the GT-I9100 hardware. It always sets the secondary cpu offline when the screen is off.
ChangeLog
v1 -> v2
fix: allow to offline the secondary cpu when screen is on
always disable the secondary cpu when screen is off
Click to expand...
Click to collapse
Hi,
Can you make it also for ninphetamine source code?
netchip said:
Hi,
Can you make it also for ninphetamine source code?
Click to expand...
Click to collapse
All the patches apply fine, except patch 0003, because the ninphetamine kernel already has a 800MHz sleep death fix.
The following patch set should apply cleanly (UNTESTED!!!).
Hi.
My question is: Is there a way to overclock the cpu by specifying a set frequency, to run at, when opening a 3d application?
For example: The cpu is running by default at 480/600 (on any min/max like governor). When a 3d app is started the max value should scale up to 787 and then revert back to the default of 600 when the app is stopped/unfocused.
I checked out the profile creation feature of some cpu overclocking apps but didn't find any to provide this kind of functionality.
BobbyLoblaw said:
Hi.
My question is: Is there a way to overclock the cpu by specifying a set frequency, to run at, when opening a 3d application?
For example: The cpu is running by default at 480/600 (on any min/max like governor). When a 3d app is started the max value should scale up to 787 and then revert back to the default of 600 when the app is stopped/unfocused.
I checked out the profile creation feature of some cpu overclocking apps but didn't find any to provide this kind of functionality.
Click to expand...
Click to collapse
I don't think you can because setCPU doesn't have that option from what i saw.
Play with the governors, see which one fits your needs. Some of them won't go to 787 anyway if you don't force it to.
Check the governors out :
ondemand – Available in most kernels, and the default governor in most kernels. When the CPU load reaches a certain point (see “up threshold” in Advanced Settings), ondemand will rapidly scale the CPU up to meet demand, then gradually scale the CPU down when it isn't needed.
interactive – Available in newer kernels, and becoming the default scaling option in some official Android kernels. The interactive governor is functionally similar to the ondemand governor with an even greater focus on responsiveness.
conservative – Available in some kernels. It is similar to the ondemand governor, but will scale the CPU up more gradually to better fit demand. Conservative provides a less responsive experience than ondemand, but can save battery.
performance – Available in most kernels. It will keep the CPU running at the “max” set value at all times. This is a bit more efficient than simply setting “max” and “min” to the same value and using ondemand because the system will not waste resources scanning for CPU load.
powersave – Available in some kernels. It will keep the CPU running at the “min” set value at all times.
userspace – A method for controlling the CPU speed that isn't currently used by SetCPU. For best results, do not use the userspace governor.
smartass – Included in some custom kernels. The smartass governor effectively gives the phone an automatic Screen Off profile, keeping speeds at a minimum when the phone is idle.
BobbyLoblaw said:
Hi.
My question is: Is there a way to overclock the cpu by specifying a set frequency, to run at, when opening a 3d application?
For example: The cpu is running by default at 480/600 (on any min/max like governor). When a 3d app is started the max value should scale up to 787 and then revert back to the default of 600 when the app is stopped/unfocused.
I checked out the profile creation feature of some cpu overclocking apps but didn't find any to provide this kind of functionality.
Click to expand...
Click to collapse
Use tasker
Sent from my LG-P500 using xda premium
karthiknayak94 said:
Use tasker
Sent from my LG-P500 using xda premium
Click to expand...
Click to collapse
Gahhhhh I was going to reply 5 minute ago with those exact words and a wink!
Sent from my Legend using XDA
is there a way to overclock by going into system files
Asovse1 said:
Gahhhhh I was going to reply 5 minute ago with those exact words and a wink!
Sent from my Legend using XDA
Click to expand...
Click to collapse
Haha i beat you to it =P
Sent from my LG-P500 using xda premium
karthiknayak94 said:
Use tasker
Sent from my LG-P500 using xda premium
Click to expand...
Click to collapse
I did try tasker but didn't find such options.
BobbyLoblaw said:
I did try tasker but didn't find such options.
Click to expand...
Click to collapse
I'm using it , for games, higher oc and performance governor xP
Search harder
Sent from my LG-P500 using xda premium
Hello developers!
What's files I need to look at to overclock my CPU with minimum changes?
I added frequencies to arch/arm/boot/dts/msm8974.dtsi, compiled my kernel and works fine,
But new frequencies are not displaying in any of cpu tweaking programs.
My CPU is msm8974.
There are so many questions asked over and over again about how to configure the kernel for a desired outcome..... max performance, best battery holdup, fix freezing etc.
I will post this for those who did not attend school just for the bus ride or playtime. All dumb questions ignored so if I don't respond, you asked a dumb question or made a dumb comment.
We have a choice of 1 custom kernel (Eureka) that can be comprehensively tweaked thanks to many of the settings being moved into the DTB partition. Currently, there are 20 versions of the DTB image that can be selected on kernel installation - 10 enforcing and 10 permissive with 10 different mixes of cpu and gpu frequencies to suit most needs. The default sets everything to maximum and is the cause of the majority of freezing / crashing on an A205 phone that has a lower quality SoC than the other A series compatible phones. Most will end up using DTB2 to fix instability but even this might not be enough. You then have to consider a lower frequency DTB which lessens the attractiveness of using this custom kernel. Why not make your own flavor of DTB that can more accurately reflect what you can run on your specific SoC? Here's how:
Open up the Eureka Kenel zip file in whatever zip extractor you use.
Extract DTB2.img from the zip file (either permissive or enforcing version depending on what your chosen ROM needs)
Now open DTB2.img using a hex editor
Now look at the following which is a list of addresses (in hex), what the value at this address is defining and a list of possible settings. Frequencies are in MHz and the hex code to set it is the frequency in kHz example: 343MHz is 343000kHz, 053BD8 is hex for 343000.
GPU:
5CA5 GPU max freq
5CB5 GPU boost freq
5CC7 GPU boost %load
Possible freqs (MHz):
343 053BD8
450 06DDD0
545 0850E8
676 0A50A0
845 0CE4C8
1001 0F4628
1100 10C8E0
1200 124F80
1300 13D620
CPU smalls:
71B1 CPU min freq
71C1 CPU min freq
71D1 CPU max freq
71E1 CPU max freq
71F1 CPU boost freq
Possible freqs (MHz):
208 032C80
343 053BD8
449 06D9E8
546 0854D0
676 0A50A0
757 0B8D08
839 0CCD58
902 0DC370
1014 0F78F0
1144 1174C0
1248 130B00
1352 14A140
1482 169D10
1586 183350
1690 19C990
1794 1B5030
CPU bigs:
73B9 CPU min freq
73C9 CPU min freq
73D9 CPU max freq
73E9 CPU max freq
73F9 CPU boost freq
Possible freqs (MHz):
208 032C80
312 04C2C0
520 07EF40
728 0B1BC0
936 0E4840
1144 1174C0
1352 14A140
1560 17CDC0
1664 196400
1768 1AFA40
1872 1C9080
1976 1E26C0
2080 1FBD00
2184 215340
2288 22E980
First thing: The default min freq of 208MHz does not save any more battery than setting this to 343MHz (for small cpus) and 312MHz for bigs.
Next thing: The A205 more than likely will become unstable at anything above 2080MHz for the big cpus but can probably cope with 1794MHz on the small cpus. Each SoC is slightly different so you must test what your phone can handle, not what someone else's phone can do!
Next: It is highly unlikely that your A205 will be stable with the GPU maxxing out at 1300MHz. You will not be aware of this until the gpu governor actually cranks the gpu up to that frequency i.e. you can remain oblivious to it for some time and incorrectly assume something else is causing freezes / crashes / glitching.
Next: There are many more settings in the DTB relating to boost frequencies on various input conditions i.e. screen touches, keyboard clicks, mouse clicks etc. Most of these are set to peak at 1144MHz which seems quite reasonable so I have not sought to specifically identify and edit these.
Edit: So here are the input boost frequencies: (address, name, function, freqs)
I assume the first addresses in each block are for BIGS and the 2nd lot are for SMALLS. It seems to work well to set all the BIG freqs to 936 and all the SMALLS to 839 since there is an abundance of upward boosting from other sources such as the Governor and Exynos specific drivers.
50B1 key1 IKEY 1144
5181 key2 ITOUCHKEY 1144
5255 5259 525D 5285 5289 528D key3 ITOUCH 1144 1144 936 839 839 839
5369 536D 5391 5395key4 IMULTITOUCH 1144 936 839 839
545D 5461 5485 5489 key5 IKEYBOARD 1144 936 839 839
554D 5551 5575 5579 key6 IMOUSE 1144 936 839 839
5641 5669 key7 IMOUSE WHEEL 1144 839
5735 5739 575D 5761 key8 IPEN HOVER 1144 936 839 839
5821 5825 5849 584D key9 IPEN 1560 936 839 839
58E5 key10 IKEY_TWO 1872
Recommendations:
Min Freqs:
Set GPU to 343MHz, small CPUs to 343MHz and big CPUs to 312MHz. This is the maximum power saving you will get and offer minimal lag as the frequencies scale up to meet demand.
Set the GPU max freq to 845MHz while you are establishing what is stable for the CPUs.
Set GPU boost to 545 or 676MHz (depending on your compromise between battery and performance)
Set GPU boost load trigger level from the stock 75% down to 50~60%. Again depending on your compromise between battery and performance. Lowering this setting has a significant impact on reducing perceived lag so the stock setting was probably far to high.
Set big CPU max freq down to 2080MHz. This solves most crashing that is due to the cpu being overclocked too far.
Set small CPU max freq to 1794MHz unless your SoC proves to be unstable at this.
Set the CPU boost freqs to something quite low (around 700~900MHz). There are other boosts that override this basic CPU boost freq so you will almost never see it.
Note: If you want maximum battery savings, setting the max freqs lower seems like a logical thing to do but it is not! If you halve the cpu freqs, you double the amount of time they must remain on but you do not halve the power consumption so you end up consuming more power....
Make the changes and save the DTB.img file and flash it in recovery to DTB partition and reboot.
Install hKtweaks_v2.2.2 or your favorite kernel tweaker that can deal with Exynos SoCs (not many can)
Take a look at the cpu and gpu settings to confirm that your edited DTB file is producing the expected results i.e. min and max freqs agree with what you set.
You are done!
Err..... only kidding there is more to do.
Now back to the issue of the GPU max freq. In hKtweaks you can override the settings inherited from the DTB (within the limits set by the DTB). The max GPU freq is also associated with a core voltage. Lowering the voltages will make the GPU run cooler (use less power) but also it will not overclock as far as if the voltage is higher. Here is the dangerous bit - you can increase the voltage to make it overclock higher but cause it to overheat quicker which will make it throttle back to a lower freq. There is also an error in the DTB: Look at the settings for throttling the frequency back at certain temps. Set GPU LEVEL 3 Throttling Freq to 343MHz to fix the error.
Have a play with the GPU settings in hKtweaks without setting Apply on boot so if you set something that crashes the phone, it will revert to normal on a reboot. When you are positive you have the best GPU settings. then set Apply on boot.
Now you are done!
Err..... not quite, there is more.
O.K, assuming you have your custom DTB set up exactly how you want it, it is time to look at some important settings available through hKTweaks.
Firstly we will look at the CPU Governor selection. Interactive is the stock setting and if you watch what the CPU cores are doing with no background activities (kill all unnecessary apps), you will see the frequencies will be dancing around without settling down to the minimum freqs. This is partly due to a dodgy implementation of this governor by Samsung and also the excessive amount of invisible running services that allow Samsung and Google to plunder your personal data in realtime.
Touch the screen, scoll the screen etc. and you will see the various CPU boost features adding to the overall freqs.
The Eureka kernel has extra CPU Governors added - not all function correctly... be warned. Some Governors apply to all CPUs (big and small) and can't be configured separately. Some Governors can have separate configurations for big and smalls.
The way this works is whatever is set for cpu0 is applied to all smalls (cpu0~5) and whatever is set for cpu6 is set for all bigs (cpu6~7).
In a root filemanager, take a look at /sys/devices/system/cpu/cpufreq If you see a folder with the Governor's name, the Governor is applied to all cpus big and small with the same settings. If the Governor does not have a folder here, look in policy0 and policy6 folders. If the Governor has folders in there, the Governor can have separate settings for big and smalls. This is determined by however the Governor was set up at the kernel level.
I can't tell you what Governor is best for your usage patterns - I have already warned you that some are borked so all you can do is try them all while watching their behavior. until you find one that works for you.
Let's use Smartmax as an example. It is not aware of bigs and smalls so any settings are applied to all cpus. If you set this Governor for both big and small cpus, changing the settings in big will change the settings in small as well. The default settings will automatically pick up on the settings you made in your DTB. The remaining settings are not bad as they are but can be improved on.
Try it out, set Smatmax as the governor both both big and small and observe the cpu freqs on idle and when touching / wiggling the screen. You should see it scale up rapidly and scale down to min freqs much better than Interactive was doing. Have a play with other settings if you want - I tend to speed up the ramp down rate and increase the ramp down step to make the cpus return to min freq quicker (for battery saving). Once you have experimented with Smartmax, have a play with the remaining Governors to see if there is anything you like. Something I learnt from a previous phone with a MTK octa core SoC is that there is no power penalty for readily scaling the cpus up to a (sensible) maximum freq. This gives the phone a fast, lag free feel that everyone wants and the cpu will complete its tasks faster so it can return to idle faster. A foolish overclock freq will burn more power - usually when the core voltage is cranked up stupidly high to get the overclock - bad for phone, bad for battery! A bad Governor setup will chew battery if it doesn't pull the frequencies back to idle at low loads but view this in light of the amount of background services you are running. MyAndroidTools is an excellent app to view and take control of pesky services.
The GPU also has a choice of Governors but I recommend sticking with the default Interactive. You get to choose the GPU Highspeed freq and load and both of these settings can be embedded in your DTB. Play with the freq / voltage tables at your own risk!
More to come....
Latest additions:
HMP Settings:
689C 0000020C up threshold
68AC 000000D6 down threshold
68BC 000000FE semiboost_up_threshold
68CC 000000A3 semiboost_down_threshold
68DC 02625A00 bootboost-duration us
68EC 0000001E down_compensation_timeout mS
68FC 0016E360 down_compensation_high_freq uS
690C 000F4240 down_compensation_mid_freq uS
691C 000C3500 down_compensation_low_freq uS
A final note:
If you want to know which CPU, GPU governors are best and what the difference is between them, there is loads of information already gathered on this topic. Most of it is quite dated but still relevant. Here is a good starting point:
[REF][GUIDE]Saber's guide on CPU governors, I/O schedulers and more!
Collective guide of CPU governors, I/O schedulers and other kernel variables I present to you a wonderful collection of descriptions, comparisons and graphs of common kernel variables. Before continuing on the wonderful journey of Linux kernel...
forum.xda-developers.com
There is a lot of misunderstanding on Eureka Kernel and ROM forums around the issue of memory management - LMK, Virtual Memory etc. Many users want something for nothing like running every known Samsung, Google and Social Media app in the background on a A12.1 or 13 ROM on a phone with 3GB RAM.
The basics of virtual memory have not changed - set ZRAM to no more than 50% of the available memory and set ZSWAP Memory pool to no more than 30%. Swappiness is best at 100% and vfs_cache_pressure set to 50. These settings are the favorite targets for abuse in tweaks offered by people of little knowledge.
Once you have your virtual memory sorted and have made smart decisions on what services/apps you are going to allow to self start on boot and hide in the background, it is a simple case of looking at the free memory to figure out how many more apps can run before killing occurs. It should surprise no-one when it occurs..... blame yourself, not the kernel, not the ROM, but your decisions on what you run and how you configure the phone.......