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!!!).
I have a ROOTED chinese brand phone with the MTk6575 CPU (1 GHZ) with android 2.3.6 installed on it, and am trying to improve the phone's battery life by scaling down the CPU frequency. But out of all the apps I have tried (SetCPU, No-Frills, Android Overclock) none of them is able to read the CPU Governor or current CPU frequency. My question is could we change this frequency directly by editing any of the files inside the /system folder or is there any other security setting that prevents these apps from reading or changing the CPU frequencies?
CPU frequency scaling, governor changing, I/O scheduler changing and under/over-volting all require kernel support. In all probability your stock kernel does not have that support, and you can't change kernel unless someone develops one for your phone.
Sent from my Desire HD using xda premium
Introduction
This is a kernel for XT1572/XT1575 built from stock sources (marshmallow-6.0.0-release branch) with cherry picks from other kernels and some ports/mods done by me. It started as a personal build tailored to my preferences but just thought I'd share in case somebody might find it useful. My main goal is building the smoothest kernel I can get so performance is top priority.
This kernel is for stock ROM MPH24.49-18*
Disclaimer
Although I have experience with Linux kernels on desktops and servers this is my first Android kernel. I've been running this kernel on my XT1572 for a few days and seems pretty stable but that doesn't mean it's risk free. In fact I wouldn't dare to install it if you don't have a proper backup and some basic skills to deal with unexpected situations.
Features
Aroma Installer
CPU profile scripts (see this)
Color control (KCAL)
Frandom
Updated to kernel version 3.10.101
Overclocking (a53: 1536MHz a57:2016MHz)
Underclocking (302MHz)
Additional CPU governors (ElementalX, Intelliactive, Lionheart, BioShock, BluActive, Wheatley, InteractiveX/Interactive, Impulse, Zzmoove)
Additional I/O schedulers (SIO, FIOPS, Zen, BFQ, SIOPLUS)
Bricked Hotplug
Updated ZRAM driver
Updated Lowmemorykill driver
Basic init.d support
KSM and UKSM
Voltage readings
Fsync on/off
Touchboost on/off
Vibration control
KEXEC Hardboot (MultiROM support)
Patched cdrom code (DriveDroid support)
DoubleTap2Wake/Sweep2Wake/Sweep2Sleep (EXPERIMENTAL)
Power efficient workqueues
Support for additional FS: NTFS, NFS, CIFS
Additional Xpad drivers (read this)
Device as USB trackpad/keyboard driver (read this)
WiFi module optimizations
Many minor optimizations
Optimization flags
UBER Toolchain 4.9
Installation instructions
Download ZIP and flash from TWRP/Flashify. Read the following notes carefully before flashing.
Important notes:
This kernel is still experimental, make a proper backup first
You need to be rooted
DO NOT play with DT2W/S2W before reading the release notes and the update
In case you want to tune some parameters (ie: CPU frecuencies) I recommend you install EX Kernel Manager, Kernel Adiutor or Kernel Adiutor-Mod.
If you're using Kernel Adiutor to control vibration or TCP congestion read this.
Questions? Read the FAQ before posting.
Download
Latest version is v0.14 (see release notes)
https://www.androidfilehost.com/?w=files&flid=49225
Donations
Although quite a deal of the important work has been done by the developers mentioned in the Credits section I spend many hours working on this. If you feel like helping me out I'd appreciate some tiny donations to cover some minor expenses.
Thanks to all of you who have donated, it's very much appreciated.
Profiles
One of the FAQ in most kernel related threads is "What are the best settings for .....?". This is the 10 million question since the usage pattern can be very different for each user. However, I understand less experienced users will appreciate some hints in this department, so that's why I'm posting some basic settings you can use as a starting point.
It's your job to further tune them to suit your needs. You should be able to modify these settings with whatever Kernel Control App you like the best, although not all settings are available in every app, in such a case tune those you can. The list is not complete (just the most importante settings) and is loosely based on Kernel Adiutor arrangement.
Please, keep in mind these are subjective values (based of personal preferences or popularity) and some people might like other settings for whatever reasons.
Performance Profile: Very smooth and responsive but average battery life
CPU
LITTLE Cluster
CPU Governor: bluactive
CPU Max Frequency: 1536MHz
CPU Min Frequency: 302MHzBIG Cluster
CPU Governor: bluactive
CPU Max Frequency: 2016MHz
CPU Min Frequency: 302MHz
NOTE: If you get N/A or weird values when trying to change settings on BIG cores it means both have been hotunplugged. To work around this select "performance" governor, make your desired changes and then select you previous governor.CPU Boost
Input Boost Frequency Core 1: 960MHz
Hotplug
MSM MPDecision
Minimum CPU online: 2
Maximum CPU online: 6
Max Cores Screen Off: 2
Idle Frequency: 384MHz
Thermal
Core Control: Off
VDD Restriction: Off
Temperature Throttle: On
GPU
Max Frequency: 600MHz
Min Frequency: 180MHz
Govenor: cpufreq
I/O
Scheduler: noop
Read-ahead: 1024KB
Balanced Profile: Above average battery life with good performance on most situations
CPU
LITTLE Cluster
CPU Governor: interactive
CPU Max Frequency: 1440MHz
CPU Min Frequency: 302MHzBIG Cluster
CPU Governor: interactive
CPU Max Frequency: 1632MHz
CPU Min Frequency: 302MHz
NOTE: If you get N/A or weird values when trying to change settings on BIG cores it means both have been hotunplugged. To work around this select "performance" governor, make your desired changes and then select you previous governor.CPU Boost
Input Boost Frequency Core 1: 960MHz
Hotplug
MSM MPDecision
Minimum CPU online: 2
Maximum CPU online: 5
Max Cores Screen Off: 2
Idle Frequency: 768MHz
Thermal
Core Control: Off
VDD Restriction: Off
Temperature Throttle: On
GPU
Max Frequency: 600MHz
Min Frequency: 180MHz
Govenor: msm-adreno-tz
I/O
Scheduler: noop
Read-ahead: 1024KB
Battery Profile: Good battery life at the expense of somewhat limited performance
CPU
LITTLE Cluster
CPU Governor: ondemand
CPU Max Frequency: 1440MHz
CPU Min Frequency: 302MHzBIG Cluster
CPU Governor: ondemand
CPU Max Frequency: 1632MHz
CPU Min Frequency: 302MHz
NOTE: If you get N/A or weird values when trying to change settings on BIG cores it means both have been hotunplugged. To work around this select "performance" governor, make your desired changes and then select you previous governor.CPU Boost
Input Boost Frequency Core 1: 960MHz
Hotplug
MSM MPDecision
Minimum CPU online: 1
Maximum CPU online: 3
Max Cores Screen Off: 2
Idle Frequency: 960MHz
Thermal
Core Control: Off
VDD Restriction: Off
Temperature Throttle: On
GPU
Max Frequency: 450MHz
Min Frequency: 180MHz
Govenor: simple_ondemand
I/O
Scheduler: noop
Read-ahead: 1024KB
Thanks To/Credits
vadimtk
flar2
franciscofranco
nimrodsv
anarkia1976
savoca
myfluxi
AudioGod
osm0sis
nychitman1
jollaman999
imoseyon
showp1984
HashBang173
neobuddy89
rehpyc
Alcolawl
soniCron
Spasticdroid
XDA:DevDB Information
Frankenclark, Kernel for the Moto X Style (Pure)
Contributors
dirtyhank
Source Code: https://github.com/dirty-hank/frankenclark/
Kernel Special Features:
Version Information
Status: Beta
Current Beta Version: 0.14
Created 2016-01-10
Last Updated 2016-10-11
Changelog
v0.14 (2016-08-29)
Proper KCAL control (thanks to @Spasticdroid)
Updated xpad driver for compatibility with gamepads/controllers (thanks to @Spasticdroid)
Driver to use device as USB trackpad and keyboard (thanks to @Spasticdroid)
Misc minor updates (see github)
100Hz version uses stock compiler flags
v0.13 (2016-06-21)
Update to Linux Kernel 3.10.102
Misc minor updates (see github)
New start-up CPU governor profiles: bluactive, maddog and silverfish
v0.12 (2016-05-15)
Disable DT2W/S2W while phone call is in progress
New CPU governors: impulse, zzmoove
New and updated CPU profile scripts
Runtime CPU profile switcher script (see release notes)
Minor changes to Aroma installer
v0.11.1 (2016-05-01)
Aroma Installer update (see release notes)
v0.11 (2016-04-27)
Aroma Installer
Better camera focus
Less CPU usage from DT2W/S2W
Minor updates and bugfixes
v0.10 (2016-04-03)
Updated lowmemorykiller driver
BFQ and SIOPLUS I/O schedulers
Updated ZRAM driver (on by default)
User togglable WLAN wakelocks
Basic init.d support (see release notes)
Misc minor updates
v0.9 (2016-03-20)
Update to Linux Kernel 3.10.101
Bug fixes
Changes from Google update to N5X and N6P (see release notes)
v0.8 (2016-03-06)
Update to Linux Kernel 3.10.99
Power efficient workqueues
NTFS support
NFS and CIFS support (you'll probably need additional user space binaries)
v0.7.1 (2016-02-28)
Workaround for the dimmed screen upon unlock bug when DT2W/S2W is enabled
v0.7 (2016-02-21)
Hotplug thresholds tuned to keep BIG cores offline more often
KEXEC Hardboot (MultiROM support)
Patched cdrom code (full DriveDroid support)
DoubleTap2Wake/Sweep2Wake/Sweep2Sleep (HIGHLY EXPERIMENTAL, Read this)
v0.6 (2016-02-07)
Vibration control (non-haptic)
Relaxed CPU macros for better power usage
File hosting now on AndroidFileHost
v0.5.2 (2016-02-03)
Fixed USB and WiFi Tethering
Minor tweaks
v0.5.1 (2016-02-01)
Changes to installer
v0.5 (2016-01-31)
Update to Linux Kernel 3.10.95
InteractiveX governor (as patches to the interactive gov)
Bricked Hotplug
KSM and UKSM (disabled by default, use Kernel Adiutor to enable)
Many minor optimizations
WiFi module optimizations
Modules recompilation
Disabled core_ctl (due to broken module after some internal changes to kernel)
Voltage readings (any attempt to modify values is silently ignored)
v0.4.1 (2016-01-24)
Prevent msm_performance from messing with the user selected min/max CPU frequencies
v0.4 (2016-01-23)
New CPU governors (ElementalX, Intelliactive, Lionheart, BioShock, BluActive, Wheatley)
New I/O scheduler (Zen)
Default I/O scheduler set to noop with a read ahead of 1024kb
Fixed bug CVE-2016-0728
Minor optimizations
Introduce ZIP installer (Anykernel2)
v0.3 (2016-01-18)
Color control (KCAL)
frandom support
New optimization flags
ZRAM disabled by default
v0.2 (2016-01-14)
Updated to Linux kernel 3.10.94
Underclocking (302MHz)
v0.1 (2016-01-10)
First public version
FAQ
I get random reboots, what is happening?
This kernel overclocks both clusters by default (a53: 1536MHz a57:2016MHz) and although this is very safe for most devices some CPUs are in the lowest spot of the binning spectrum and can't handle O/C very well. In such a case use a kernel control app (see the OP for references) to limit the maximum CPU frequencies, play with them until you find stable values for your device.
What are the best settings for battery life/performance/whatever?
That's hard to tell as every user is different. You can find some basic profiles in the OP you can use as a starting point. Notice the differences between then and build you own.
Why do some BIG cluster settings display N/A?
Why can't I change some settings on the BIG cluster?
If you get N/A or weird values when trying to change settings on BIG cores it means both are offline ("hotunplugged"). To work around this select "performance" governor, make your desired changes and then select you previous governor. You can also disable hotplug, make the changes, and enable hotplug again.
DoubleTap2Wake doesn't work sometimes. How can I get it to work all the time?
When device goes into suspend mode first tap is often missed (I suspect this is caused by Moto Sensor Hub). If you tap three times and get the timing right you'll probably make it work most of the time. As an alternative, Sweep2Wake works almost all the time
DT2W/S2W is acting weird or disabling itself
Make sure Moto Display is disabled. Open the Moto app, click on the stars in the top right corner, select Display and set to Off
Can I use this kernel in ROM X/Y/Z?
This is for stock ROM MPH24.49-18 only. It'll probably work on any stock based ROM but not guaranteed.
I use stock ROM but WiFi is not working
Due to some internal changes all modules had to be recompiled (WiFi included). In order to expose the new modules without modifying the system partition I had to implement a hack that requires root. Make sure you're properly rooted.
What's the deal with ZRAM?
ZRAM is a technique to increase memory available to the apps at the expense of CPU time. Memory space from apps not being used is compressed into a memory swap area and uncompressed on the fly whenever needed. As you can imagine this compress/uncompress process burns CPU cycles, potentially leading to worse battery life, lag and higher temperatures. Since this device comes with 3GB I can only think of one scenario where ZRAM can be beneficial: heavy multitaskers who care more about apps not reloading than battery life. For the rest of users enabling ZRAM doesn't make much sense in my opinion, and that's why it's disabled by default.
UPDATE: v0.10 includes an updated ZRAM driver that improves performance significantly. So much so that the benefits seem to outweigh the costs and it's been enabled by default.
What's the deal with KSM/UKSM?
Since many apps use the same libraries/resources it's very likely that at any given time there are multiple copies of the same data on different memory locations. KSM/UKSM tries to take advantage of that fact by scanning memory pages periodically and consolidating that multiple copies into a single shared copy. Much as like ZRAM it can have a good effect on heavy multitasking performance but at the expense of CPU cycles, and thus it's only recommended in the same scenario as ZRAM. Disabled by default
Ok, so do I enable ZRAM/KSM/both/neither?
I honestly think most users will be better off not using neither. If you feel like you need extra RAM I'd try KSM first, then ZRAM. Using both at the same time is overkill unless you are an ultra multitasker, in which case you should probably get a 4GB device anyway
How do I get WiFi on 6.0.1?
It's a modem version mismatch issue, you need to downgrade the modem. See this post.
Love to see more options! Thanks for sharing!!
Yeah this will be very good
Only One think that would be awesome try to implement the double tap to wake
Awesome! More custom kernels are always welcome are there many governors to choose from?
krohme said:
Awesome! More custom kernels are always welcome are there many governors to choose from?
Click to expand...
Click to collapse
Right now only the stock governors are available but I plan on adding a few
Can't we install it through twrp???
guraki said:
Can't we install it through twrp???
Click to expand...
Click to collapse
Yes, TWRP supports boot image flashing
I lost root after the kernel install....
---------- Post added at 03:22 PM ---------- Previous post was at 02:39 PM ----------
Seems to work fine!!! Any battery life expectations?
guraki said:
I lost root after the kernel install....
---------- Post added at 03:22 PM ---------- Previous post was at 02:39 PM ----------
Seems to work fine!!! Any battery life expectations?
Click to expand...
Click to collapse
As I said on the OP my main goal is performance/smoothness, so I haven't specifically sought better battery life. That being said I'm getting about the same battery life as stock with better performance, that works for me.
Nevertheless, I'm very interested on how it works for other configurations and usage patterns.
@dirtyhank could you please add hotplugging to the kernel? Preferably one that allows you to select how many cores to run as well as which ones, as in run the two A57s and turn off the four A53s. Currently I'm running two A53s at 1.2Ghz and the remaining four cores are always off.
The screenshot is from Lolipop, and it is the only reason why I havent upgraded to MM. Turning off cores definitely makes a difference on battery life.
Also, if possible, adding a lower speed to the min speed. Will gladly test anything you thow my way. Thanks in advance.
Is there any chance for a CM13 version and a DT2W fork from elementalx?
sir-harlekin said:
Is there any chance for a CM13 version and a DT2W fork from elementalx?
Click to expand...
Click to collapse
DT2W maybe, CM13 unlikely.
very nice thank you! slowly slowly we getting more and more things. Just making sure this is only for stock based rom/s Thanks!!
cerobles1 said:
@dirtyhank could you please add hotplugging to the kernel? Preferably one that allows you to select how many cores to run as well as which ones, as in run the two A57s and turn off the four A53s. Currently I'm running two A53s at 1.2Ghz and the remaining four cores are always off.
The screenshot is from Lolipop, and it is the only reason why I havent upgraded to MM. Turning off cores definitely makes a difference on battery life.
Also, if possible, adding a lower speed to the min speed. Will gladly test anything you thow my way. Thanks in advance.
Click to expand...
Click to collapse
What kernel are you using on LP?
patt2k said:
very nice thank you! slowly slowly we getting more and more things. Just making sure this is only for stock based rom/s Thanks!!
Click to expand...
Click to collapse
Yep, stock ROM, I'll edit the OP
dirtyhank said:
Yep, stock ROM, I'll edit the OP
Click to expand...
Click to collapse
Awesome gonna flash this soon
I hope a port for CM based roms might be possible in the future! Thanks for sharing your work and replying so quickly!
dirtyhank said:
Yep, stock ROM, I'll edit the OP
Click to expand...
Click to collapse
Getting bootloop on TruePure rom 2.4. Anything I can try to avoid bootloops?
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.......