[DEV][KERNEL] Tegra3 power management notes and tricks - HTC One X

This thread contains findings on how to view and set kernel parameters related to power management. Although there is no kernel source for One X, some information can be obtained from Transformer Prime kernel sources (also a Tegra 3 device), and from the device itself via sysfs interface.
sysfs files related to CPU power management:
/sys/kernel/debug/tegra_hotplug/max_cpus - maximum CPUs to use. User-configurable, default 4. This is not touched by the Android OS, and will remain in whatever state we set until reboot.
Set this to "1" to make the phone a lot less power-hungry and overheating.
At the cost of performance, of course.
*NOTE: second core will activate sometimes if this is set to "1", but 3rd and 4th cores are disabled for sure.
/sys/kernel/debug/tegra_hotplug/min_cpus - minimum number of CPUs to use.
This _is_ touched by the OS, and can not be set reliably.
/sys/kernel/debug/tegra_hotplug/stats - time each core spent active. Including 5-th "low-power" core.
e.g.:
Code:
cpu: G0 G1 G2 G3 LP
transitions: 26 12 0 0 25
time plugged: 3110 1222 0 0 95122
time-stamp: 4296183486
/sys/kernel/debug/cpuidle/lp2 - another stats interface.
/sys/module/cpu_tegra/parameters/cpu_user_cap - Max frequency cap for all cores. Default 1500000 (1.5GHz), can be set to any lower value to underclock.
But it is often set by the OS different values (most frequently, back to it's maximum). Maybe, changing this string in libhtc-opt2.so via hex editor can prevent system from changing it?
/sys/kernel/cluster/active - currently active CPU cluster. "LP" for low-power core, "G" for generic (normal) cores.
Can be changed manually, but is also modified by the system at will.
All above values can be changed from root shell via "echo 'value' > /sys/path/to/file"
Maybe, this will come handy to some ROM or CPU-monitoring app developers.
References:
Asus Transformer kernel source
[DEV] Enable 2D GPU rendering in HTC One X & about build.prop tweaks
some findings by phirenz

is there any way to request more use of the companion core?

In case anyone's wondering, I just found out that /sys/kernel/cluster/active must be opened as root even for reading; opening the file as any other user will not succeed.
The other files seem to allow reading as a standard user, however.

It woulod be great is someone created an app for setting number of CPUs. It is useful sometimes to set it to 1 when you are traveling and want to get max possible battery.
It would be even better if it was possible to disable all 4 cores and force system to use LP core only. It would be brilliant max power saving mode.

I've modified OS Monitor to support Tegra 3's stuff (temperature, number of cores and determining whether it is low power/general CPU in use) and my experience is that there's no or very little battery gains to be had because the other 3 cores are off most of the time anyway (when idle)
I'm using stock 1.28. The low power core doesn't seem to like being activated for more than a few seconds at a time, too.

I've modified OS Monitor to support Tegra 3's stuff
Click to expand...
Click to collapse
Can u share the apk here...xD???

thanks to the OP.....I don't have a One X but this info helped me to force all 4 cores of my Asus TF300T go online and offline as i wish.

schriss said:
It woulod be great is someone created an app for setting number of CPUs. It is useful sometimes to set it to 1 when you are traveling and want to get max possible battery.
It would be even better if it was possible to disable all 4 cores and force system to use LP core only. It would be brilliant max power saving mode.
Click to expand...
Click to collapse
use core control or francos kernel updater works for every custom kernel also stock kernel and you can choose how many cores...but battery life is not better with deactivated cores and soemetimes even worser -.-

I used to be able to do this, but now I'm using n3o kernel and I can't find the tegra_hotplug folder inside sys/kernel/debug. Help?

joeystar said:
I used to be able to do this, but now I'm using n3o kernel and I can't find the tegra_hotplug folder inside sys/kernel/debug. Help?
Click to expand...
Click to collapse
Man ask this in kernel thread not here....-.-
Sent from my HTC One X using xda app-developers app

Related

[KERNEL][AOSP4.4/5.1/6.0/7.1] dkp - d2att - 2/4/18

Welcome to decimalman's kernel playground!​
As the name suggests, dkp is a hodgepodge of features and tweaks that I wanted to play with. It should get excellent battery life without feeling sluggish. It doesn't come with its own tuner app, so pick your favorite. Personally, I like Trickster MOD and Kernel Adiutor, so I go out of my way to make things work in them. Most other apps should work, too.
Features:
Overclocking up to 2.1 GHz, but you'll need to increase your voltages to get there (if you can get there at all)
Underclocking down to 54 MHz, with stability improvements
Undervolting compatible with most apps
Fast charge without unplugging first
Glorious animations for the notification and softkey LEDs
Well-integrated erandom means you don't need CrossBreeder or Seeder (recent AOSP builds use ISAAC instead)
freelunch and tierservative governors for optimal battery life without sacrificing responsiveness
Automatic mpdecision and auto-hotplug are only enabled when needed
Adjustable minimum voltage for stability on finicky processors
Optimized UKSM to free up some extra memory
Code optimizations for size and speed
Compiler optimizations (-O3, LTO, and more) because faster is better
Donors: Thanks, everyone! Your generosity is much appreciated. :good:
drpenguino, 0xScott, vmancini3 (twice! :good, Ch4m3l30n, rompnit, Mystique, ryandubbz, techdog, ElwOOd_CbGp, ScOULaris, ZipAddict
Remember:
Nandroid!
last_kmsg and/or logcat or it didn't happen.
Other kernels have their own threads or forums. Discuss them there.
Image dumps (settings, battery life, whatever) belong inside [HIDE][/HIDE] (that's HIDE, if you're on the mobile app) tags.
Be silly. We're here to have fun.
Installation:
Reboot to recovery. I recommend that one recovery...you know, the one that flashes zips? I forget what it's called.
Flash dkp. Optionally, rename and flash dkp-vmin-XXX.zip (see below).
Reboot.
Undervolting:
Undervolting on dkp is more complex than other kernels. Some processors get unstable at lower voltages, so (like the stock kernel) dkp keeps the processor voltage above 1150 mV by default. I refer to this limit as the minimum voltage. In order to undervolt, you'll need to lower the minimum voltage: if you use Trickster MOD or Kernel Adiutor, just disable "Override Minimum Voltage", otherwise rename dkp-vmin-XXX.zip to e.g. dkp-vmin-600.zip (which would apply a 600 mV minimum voltage) and flash it. If this causes instability (crashes, audio/video glitches, etc.), try using dkp-vmin-XXX.zip to apply a higher minimum voltage (somewhere between 950 and 1050 mV seems to work well for most people).
Downloads:
MediaFire:
All Downloads
dkp-vmin-XXX.zip
Solidfiles (Make sure you have an adblocker!):
All Downloads
dkp-vmin-XXX.zip
Source: I'm always happy to see my code used, so cherry-pick away. I'll even put together feature patches if you ask nicely.
Bugs:
Let me know.
Stable changelog:
3/3/13: Initial release for d2spr. Didn't get around to making threads for other carriers.
4/8/13 (3.0):
FauxSound support
Strip more useless stuff
A few bonus optimizations
4/8/13 (3.4):
Port everything except erandom from 3.0
Enhance cpufreq for easier configuration
4/24/13 (3.4):
Bugfixes: better support for tuner apps, fixed potential SOD bugs, automatic mpdecision fixups, etc.
Lots of CM/CAF/Linux updates
Working AssWax governor
Trinity colors support
sio, zen I/O schedulers
erandom is back!
Built with a super-fancy Linaro GCC 4.8.1-dev compiler toolchain for maximum -O3 goodness
Probably lots more, but there's hundreds of commits to sort through...
5/29/13 (3.4):
Bugfixes: better overclocking support, better hwrng support, etc.
Updates: new CM updates, Linux 3.4.47, updated FauxSound driver, added invisiblek's new panel colors interface
Automatic auto-hotplug
New optimizations, including link-time optimization and an updated GNU+Linaro GCC 4.8.1-dev toolchain
6/14/13 (3.4):
Bugfixes: fix several critical bugs in the 5/29 release.
9/7/13 (3.4):
Fixes for OC, UV, auto-hotplug.
A few new optimizations.
Synced up with CM.
9/20/13 (TW):
Ported everything from AOSP to TW.
9/20/13 (4.3):
Merged 4.3 from CM into the existing 4.2 code.
Current experimental branches:
Nothing interesting at the moment.
Goodies:
dkp doesn't come with its own splash screen. However, the dkp installer (i.e. the install zip) is smarter than you think, and can apply a custom splash screen for you. Here's how:
Create a folder on your internal storage named "dkp"
Copy a PNG image into the directory, and rename it "splash.png". Alternatively, copy an RLE image (i.e. from a flashable custom splash screen zip) and rename it "splash.rle". Ideally, the image should be roughly 1280x720 to begin with, since it won't be resized.
The image will be used as your splash screen whenever you flash dkp. Reflash to apply initially.
mikedavis120 has put together a how-to video that covers tweaking dkp for optimal battery life. If you're new to dkp, take a look! He also put together a zipped collection of apps that will come in handy while tuning dkp. It also includes a flashable zip, "dkp-debug_v1.zip". After flashing it, running
Code:
su
dkp
from a terminal emulator will collect lots of useful debug information that will make it much easier for me to track down the issue you're having. :good: mikedavis120 recommends installing SuperSU (included in the zip) instead of what's included in you ROM.
sysfs:
It's possible to adjust all the settings available in dkp without using apps. Because they show up as files, settings can be adjusted with file managers, terminal emulators, adb and initscripts. Here's the most interesting files inside sysfs:
/sys/devices/platform/mipi_samsung_oled.513/lcd/panel/panel_colors (not available on newer AOSP builds): display tint (0 = very red, 2 = default, 4 = trinity colors)
/sys/class/misc/gammacontrol (only available on newer AOSP builds): various color controls. See this post for details on enabling Trinity colors on builds that use these controls.
/sys/devices/system/cpu/cpu<N>/cpufreq/UV_mV_table: voltage table
/sys/devices/system/cpu/cpu<N>/cpufreq/scaling_...: scaling_governor is the governor, scaling_min_freq and scaling_max_freq are the minimum and maximum frequencies, scaling_available_governors and scaling_available_frequencies show the available governors and frequencies
/sys/kernel/dkp/force_fast_charge: fast charge
/sys/kernel/dkp/link_core_settings: when linked (the default), frequency settings and some governors are automatically copied to the other core
/sys/kernel/dkp/vmin: minimum processor voltage in mV
/sys/kernel/mm/uksm/run: activate UKSM
auto-hotplug tuners:
These show up in the governor settings for any governor that doesn't do its own hotplugging. They only take effect when using auto-hotplug, so you'll probably need to disable mpdecision in Trickster.
hotplug_intpulse: when set to 1, automatically turns core 2 on whenever the screen/buttons/whatever is pressed. Default is 0.
hotplug_sampling_periods: number of samples to use for average number of running tasks. Default is 15.
hotplug_sampling_rate: number of 'jiffies' (currently 1 jiffy = 10 ms) between each sample of running tasks. Default is 20 (0.2 sec).
hotplug_enable_one_threshold: the average number of running tasks required to turn core 2 on, multiplied by 100. Default is 125 (1.25 tasks on average).
hotplug_disable_one_threshold: the average number of running tasks required to keep core 2 on, multiplied by 100. Default is 250 (2.5 tasks on average).
freelunch/nanolunch tuners:
freelunch and nanolunch aren't materially based on other governors, so their configuration is quite different than other governors. There's lots of tuners, since I haven't really decided on an ideal tuning. I encourage experimentation! I'll explain a bit of how these governors work before actually listing the tuners.
Generally speaking, there are two modes: in "normal" mode, sampling is done occasionally and frequency is generally increased slowly; in "interactive" mode, sampling is done much more quickly, and frequency increases much more quickly. "Interactive" mode ends after several samples of very low usage. The idea of a "hispeed" frequency is used in lots of governors, and it refers to the frequency that the CPU will jump to when more CPU usage is needed; generally, it's a generous estimate of how much CPU will be needed. Here, the hispeed frequency is adjusted on-the-fly, increasing when more CPU is needed and gradually decreasing when the CPU is idle. In "interactive" mode, the hispeed frequency is kept fairly high so that everything will feel snappy.
Hotplugging is taken care of in the least complicated (and in my opinion, most reasonable) way possible: if core 1 is using lots of CPU, and there are several tasks running (in other words, if it's likely that core 2 will have something to do), core 2 is turned on; if either core isn't doing much except using power, core 2 is turned off.
sampling_rate: the usual
hotplug_up_cycles: number of consecutive heavily-loaded samples before core 2 is turned on
hotplug_down_cycles: number of consecutive lightly-loaded samples before core 2 is turned off
hotplug_up_load: number of running tasks required to bring core 2 online
hotplug_up_usage: number of used CPU cycles (in thousands per second) required to bring core 2 online
hotplug_down_usage: number of used CPU cycles (in thousands per second) required on both cores to keep core 2 online
overestimate_khz: number of CPU cycles to overshoot usage by in "normal" mode
hispeed_thresh: if CPU usage is within this many cycles (in thousands per second) of the maximum frequency, frequency will be increased to the hispeed frequency. Generally, hispeed is pretty low in "normal" mode, and fairly high in "interactive" mode.
hispeed_decrease: when the CPU is sitting idle, the hispeed frequency is decreased by this amount each sample (this isn't ideal, but it works)
interaction_hispeed: the initial hispeed frequency when switching to "interactive" mode
interaction_return_cycles: number of consecutive lightly-loaded samples before returning to "normal" mode
interaction_return_usage: number of used CPU cycles (in thousands per second) required to stay in "interactive" mode
interaction_panic (nanolunch only): when set to 1, allows aggressively jumping past the current hispeed frequency under some circumstances
interaction_sampling_rate/overestimate_khz: equivalent to the "normal" versions of the tuners, these take effect in "interactive" mode
Just loaded it on pa 3.15
Sent from my SAMSUNG-SGH-I747 using xda premium
It doesn't say that it has morfic colors, but looks like it does. Gonna give it a whirl
Sent from my SGH-I747 using xda app-developers app
rmead01 said:
It doesn't say that it has morfic colors, but looks like it does. Gonna give it a whirl
Sent from my SGH-I747 using xda app-developers app
Click to expand...
Click to collapse
It doesn't, but I'll merge it and put out a test build.
decimalman said:
It doesn't, but I'll merge it and put out a test build.
Click to expand...
Click to collapse
Is it possible they are left over from a previous kernel? Because I can def tell the difference usually and seems like it does.
Either way, advise when its updated. This governor seems solid so far.
Sent from my SGH-I747 using xda app-developers app
rmead01 said:
Is it possible they are left over from a previous kernel? Because I can def tell the difference usually and seems like it does.
Either way, advise when its updated. This governor seems solid so far.
Sent from my SGH-I747 using xda app-developers app
Click to expand...
Click to collapse
dkp is based off clean CM source, so it shouldn't have been merged already.
I've got test builds compiling now, and the 3.4 builds will be up shortly. Flashing the trinity-colors test build and this zip will enable trinity colors. You can toggle it with
Code:
su
echo X >/sys/class/mdnie/mdnie/trinity_colors
where X is 0 to disable or 1 to enable.
Edit: and sorry for taking so long to respond.
Edit 2: 3.4 builds are up. http://d-h.st/7Ae
Thnx for this kernel
decimalman said:
dkp is based off clean CM source, so it shouldn't have been merged already.
I've got test builds compiling now, and the 3.4 builds will be up shortly. Flashing the trinity-colors test build and this zip will enable trinity colors. You can toggle it with
Code:
su
echo X >/sys/class/mdnie/mdnie/trinity_colors
where X is 0 to disable or 1 to enable.
Edit: and sorry for taking so long to respond.
Edit 2: 3.4 builds are up. http://d-h.st/7Ae
Click to expand...
Click to collapse
Maybe I was just seeing things, had just watched jurassic park in 3d.
New "test" build flashed as well as the file to enable it. Thanks for the addition. It's very hard to go back to normal once you've been smurfed depending on your display.
Only issue i'm having ATM is the ability to change the voltage table. My phone doesn't handle undervolting as well and i run a minimum of 950 baseline, if not 975. One of my normal apps wasn't able to set the voltage at all. I'm trying to use performance control which I don't like. It crashes trying to set the voltage on boot but at least I can go in and manually set the values on boot and they stick.
One last question, since this is your kernel, what scheduler do you recommend pairs well to freelunch? What would you use for performance and what would you use for batt?
rmead01 said:
One last question, since this is your kernel, what scheduler do you recommend pairs well to freelunch? What would you use for performance and what would you use for batt?
Click to expand...
Click to collapse
+1 on these questions
Sent from my AT&T Samsung Galaxy S III
rmead01 said:
Only issue i'm having ATM is the ability to change the voltage table. My phone doesn't handle undervolting as well and i run a minimum of 950 baseline, if not 975. One of my normal apps wasn't able to set the voltage at all. I'm trying to use performance control which I don't like. It crashes trying to set the voltage on boot but at least I can go in and manually set the values on boot and they stick.
Click to expand...
Click to collapse
Answered my own problem. I installed trickster as mentioned in OP and all voltage settings stick no problem with no issues.
rmead01 said:
New "test" build flashed as well as the file to enable it. Thanks for the addition. It's very hard to go back to normal once you've been smurfed depending on your display.
Only issue i'm having ATM is the ability to change the voltage table. My phone doesn't handle undervolting as well and i run a minimum of 950 baseline, if not 975. One of my normal apps wasn't able to set the voltage at all. I'm trying to use performance control which I don't like. It crashes trying to set the voltage on boot but at least I can go in and manually set the values on boot and they stick.
One last question, since this is your kernel, what scheduler do you recommend pairs well to freelunch? What would you use for performance and what would you use for batt?
Click to expand...
Click to collapse
Personally, I don't like trinity colors, but I definitely understand the appeal. I merged this into 3.0 and 3.4, so it'll be standard from here on. I'll add a link to the enabler zip in the OP as well.
What app would you normally use? I'll try to support it, since I already provide several voltage interfaces. I didn't realize performance control was crashing (I'm not a fan either, so I only lightly tested). I recently installed Trickster and liked it, so I've been going out of my way to support it. It's also really easy to write support for, so that's a bonus for me.
As for schedulers, I'm not fussy. I've never exhaustively tested performance and battery life, so I don't have a preference and usually run noop or deadline. However, I've had nothing but bad results with ROW (phone never deep sleeps, and I haven't looked into why).
decimalman said:
Personally, I don't like trinity colors, but I definitely understand the appeal. I merged this in, so it'll be standard from here on. I'll add a link to the enabler zip in the OP as well.
What app would you normally use? I'll try to support it, since I already provide several voltage interfaces. I didn't realize performance control was crashing (I'm not a fan either, so I only lightly tested). I recently installed Trickster and liked it, so I've been going out of my way to support it. It's also really easy to write support for, so that's a bonus for me.
As for schedulers, I'm not fussy. I've never exhaustively tested performance and battery life, so I don't have a preference and usually run noop or deadline. However, I've had nothing but bad results with ROW (phone never deep sleeps, and I haven't looked into why).
Click to expand...
Click to collapse
good to know. Trickster mod works fine and you mention it in the OP and it's at no cost in the play store. I wouldn't worry.
I was using an app called kernel tuner because some others would only set 1 core to the governor and not both. I checked that trickster does indeed set both cores to freelunch so once that figured out I removed kernel tuner. Kernel Tuner also has the options for profiles which can be toggled in tasker for varies states. freelunch so far hasn't needed any changing so not worried about it at this point. just as an example, some governors would be better for screen on/off and tasker could switch these to edge out battery life.
The voltage app i was using is simply called voltage control. Kernel tuner doesn't do a nice job of voltage changes. But since trickster does both governor and voltage adjustments well. i'm using that with no problems now.
Thanks for the morfic, having a way to toggle it works well for people. it's as simple as a script so there's that.
rmead01 said:
good to know. Trickster mod works fine and you mention it in the OP and it's at no cost in the play store. I wouldn't worry.
I was using an app called kernel tuner because some others would only set 1 core to the governor and not both. I checked that trickster does indeed set both cores to freelunch so once that was made it was no problem. Kernel Tuner also has the options for profiles which can be toggled in tasker for varies states. freelunch so far hasn't needed any changing so not worried about it at this point.
The voltage app i was using is simply called voltage control. Kernel tuner doesn't do a nice job of voltage changes. But since trickster does both well, i'm using that with no problems now.
Thanks for the morfic, having a way to toggle it works well for people. it's as simple as a script so there's that.
Click to expand...
Click to collapse
I meant to test Voltage Control but Google wasn't letting me download anything. It's a common app, so I'll try to get it working regardless. Kernel Tuner doesn't currently work well with freelunch, and tends to hang when it's trying to read settings in the CPU screen. Otherwise, it's a nice app. I didn't realize it had Tasker support (I use Llama).
I've added a few extra bits to the cpufreq core, so governors that need to be set on both cores (like freelunch) will automatically apply to both cores regardless of what app is used. cpufreq will even enable and disable mpdecision depending on whether a hotplugging governor is running (though Trickster won't show that it's disabled).
I owe ktoonsez for the toggleable trinity colors. I slightly rewrote his patch, but it's still largely his code. It's my policy that anything that not all users will want should be optional and easily configurable.
Edit: I think I've got Voltage Control fixed. I should be able to get Kernel Tuner working without too much work. I haven't even looked into Performance Control yet.
decimalman said:
I meant to test Voltage Control but Google wasn't letting me download anything. It's a common app, so I'll try to get it working regardless. Kernel Tuner doesn't currently work well with freelunch, and tends to hang when it's trying to read settings in the CPU screen. Otherwise, it's a nice app. I didn't realize it had Tasker support (I use Llama).
I've added a few extra bits to the cpufreq core, so governors that need to be set on both cores (like freelunch) will automatically apply to both cores regardless of what app is used. cpufreq will even enable and disable mpdecision depending on whether a hotplugging governor is running (though Trickster won't show that it's disabled).
I owe ktoonsez for the toggleable trinity colors. I slightly rewrote his patch, but it's still largely his code. It's my policy that anything that not all users will want should be optional and easily configurable.
Click to expand...
Click to collapse
well good job so far. batt life has been top notch. minimal drain in use and my over night idle drain was only a few %. I have things setup to disable wifi when sleep and also turn off mobile data when wifi is connected. A bit over the top but every bit helps.
:good::highfive:
I know I've been grilling you today but...
Kind of curious what the new tunables do. I haven't touched anything since it's working so well but there is always that part of me that wonders what adjust parameters will do. Is there any kind of reference for this governor that could indicate that type of info?
Does your kernel support faux sound app?
stevehkim said:
Does your kernel support faux sound app?
Click to expand...
Click to collapse
Yes. 3.0 and 3.4 both have support.
As for tuneables, I've been meaning to post a writeup but haven't gotten around to it. You're not the first to ask about it.
Sent from my SPH-L710 using xda app-developers app
This is a fantastic Kernel! The battery life has been outstanding so far. Thank you for your amazing work!

[KERNEL][AOSP4.4/5.1/6.0/7.1] dkp - d2tmo - 2/4/18

Welcome to decimalman's kernel playground!​
As the name suggests, dkp is a hodgepodge of features and tweaks that I wanted to play with. It should get excellent battery life without feeling sluggish. It doesn't come with its own tuner app, so pick your favorite. Personally, I like Trickster MOD and Kernel Adiutor, so I go out of my way to make things work in them. Most other apps should work, too.
Features:
Overclocking up to 2.1 GHz, but you'll need to increase your voltages to get there (if you can get there at all)
Underclocking down to 54 MHz, with stability improvements
Undervolting compatible with most apps
Fast charge without unplugging first
Glorious animations for the notification and softkey LEDs
Well-integrated erandom means you don't need CrossBreeder or Seeder (recent AOSP builds use ISAAC instead)
freelunch and tierservative governors for optimal battery life without sacrificing responsiveness
Automatic mpdecision and auto-hotplug are only enabled when needed
Adjustable minimum voltage for stability on finicky processors
Optimized UKSM to free up some extra memory
Code optimizations for size and speed
Compiler optimizations (-O3, LTO, and more) because faster is better
Donors: Thanks, everyone! Your generosity is much appreciated. :good:
drpenguino, 0xScott, vmancini3 (twice! :good, Ch4m3l30n, rompnit, Mystique, ryandubbz, techdog, ElwOOd_CbGp, ScOULaris, ZipAddict
Remember:
Nandroid!
last_kmsg and/or logcat or it didn't happen.
Other kernels have their own threads or forums. Discuss them there.
Image dumps (settings, battery life, whatever) belong inside [HIDE][/HIDE] (that's HIDE, if you're on the mobile app) tags.
Be silly. We're here to have fun.
Installation:
Reboot to recovery. I recommend that one recovery...you know, the one that flashes zips? I forget what it's called.
Flash dkp. Optionally, rename and flash dkp-vmin-XXX.zip (see below).
Reboot.
Undervolting:
Undervolting on dkp is more complex than other kernels. Some processors get unstable at lower voltages, so (like the stock kernel) dkp keeps the processor voltage above 1150 mV by default. I refer to this limit as the minimum voltage. In order to undervolt, you'll need to lower the minimum voltage: if you use Trickster MOD or Kernel Adiutor, just disable "Override Minimum Voltage", otherwise rename dkp-vmin-XXX.zip to e.g. dkp-vmin-600.zip (which would apply a 600 mV minimum voltage) and flash it. If this causes instability (crashes, audio/video glitches, etc.), try using dkp-vmin-XXX.zip to apply a higher minimum voltage (somewhere between 950 and 1050 mV seems to work well for most people).
Downloads:
MediaFire:
All Downloads
dkp-vmin-XXX.zip
Solidfiles (Make sure you have an adblocker!):
All Downloads
dkp-vmin-XXX.zip
Source: I'm always happy to see my code used, so cherry-pick away. I'll even put together feature patches if you ask nicely.
Bugs:
Let me know.
Stable changelog:
3/3/13: Initial release for d2spr. Didn't get around to making threads for other carriers.
4/8/13 (3.0):
FauxSound support
Strip more useless stuff
A few bonus optimizations
4/8/13 (3.4):
Port everything except erandom from 3.0
Enhance cpufreq for easier configuration
4/24/13 (3.4):
Bugfixes: better support for tuner apps, fixed potential SOD bugs, automatic mpdecision fixups, etc.
Lots of CM/CAF/Linux updates
Working AssWax governor
Trinity colors support
sio, zen I/O schedulers
erandom is back!
Built with a super-fancy Linaro GCC 4.8.1-dev compiler toolchain for maximum -O3 goodness
Probably lots more, but there's hundreds of commits to sort through...
5/29/13 (3.4):
Bugfixes: better overclocking support, better hwrng support, etc.
Updates: new CM updates, Linux 3.4.47, updated FauxSound driver, added invisiblek's new panel colors interface
Automatic auto-hotplug
New optimizations, including link-time optimization and an updated GNU+Linaro GCC 4.8.1-dev toolchain
6/14/13 (3.4):
Bugfixes: fix several critical bugs in the 5/29 release.
9/7/13 (3.4):
Fixes for OC, UV, auto-hotplug.
A few new optimizations.
Synced up with CM.
9/20/13 (TW):
Ported everything from AOSP to TW.
9/20/13 (4.3):
Merged 4.3 from CM into the existing 4.2 code.
Current experimental branches:
Nothing interesting at the moment.
Goodies:
dkp doesn't come with its own splash screen. However, the dkp installer (i.e. the install zip) is smarter than you think, and can apply a custom splash screen for you. Here's how:
Create a folder on your internal storage named "dkp"
Copy a PNG image into the directory, and rename it "splash.png". Alternatively, copy an RLE image (i.e. from a flashable custom splash screen zip) and rename it "splash.rle". Ideally, the image should be roughly 1280x720 to begin with, since it won't be resized.
The image will be used as your splash screen whenever you flash dkp. Reflash to apply initially.
mikedavis120 has put together a how-to video that covers tweaking dkp for optimal battery life. If you're new to dkp, take a look! He also put together a zipped collection of apps that will come in handy while tuning dkp. It also includes a flashable zip, "dkp-debug_v1.zip". After flashing it, running
Code:
su
dkp
from a terminal emulator will collect lots of useful debug information that will make it much easier for me to track down the issue you're having. :good: mikedavis120 recommends installing SuperSU (included in the zip) instead of what's included in you ROM.
sysfs:
It's possible to adjust all the settings available in dkp without using apps. Because they show up as files, settings can be adjusted with file managers, terminal emulators, adb and initscripts. Here's the most interesting files inside sysfs:
/sys/devices/platform/mipi_samsung_oled.513/lcd/panel/panel_colors (not available on newer AOSP builds): display tint (0 = very red, 2 = default, 4 = trinity colors)
/sys/class/misc/gammacontrol (only available on newer AOSP builds): various color controls. See this post for details on enabling Trinity colors on builds that use these controls.
/sys/devices/system/cpu/cpu<N>/cpufreq/UV_mV_table: voltage table
/sys/devices/system/cpu/cpu<N>/cpufreq/scaling_...: scaling_governor is the governor, scaling_min_freq and scaling_max_freq are the minimum and maximum frequencies, scaling_available_governors and scaling_available_frequencies show the available governors and frequencies
/sys/kernel/dkp/force_fast_charge: fast charge
/sys/kernel/dkp/link_core_settings: when linked (the default), frequency settings and some governors are automatically copied to the other core
/sys/kernel/dkp/vmin: minimum processor voltage in mV
/sys/kernel/mm/uksm/run: activate UKSM
auto-hotplug tuners:
These show up in the governor settings for any governor that doesn't do its own hotplugging. They only take effect when using auto-hotplug, so you'll probably need to disable mpdecision in Trickster.
hotplug_intpulse: when set to 1, automatically turns core 2 on whenever the screen/buttons/whatever is pressed. Default is 0.
hotplug_sampling_periods: number of samples to use for average number of running tasks. Default is 15.
hotplug_sampling_rate: number of 'jiffies' (currently 1 jiffy = 10 ms) between each sample of running tasks. Default is 20 (0.2 sec).
hotplug_enable_one_threshold: the average number of running tasks required to turn core 2 on, multiplied by 100. Default is 125 (1.25 tasks on average).
hotplug_disable_one_threshold: the average number of running tasks required to keep core 2 on, multiplied by 100. Default is 250 (2.5 tasks on average).
freelunch/nanolunch tuners:
freelunch and nanolunch aren't materially based on other governors, so their configuration is quite different than other governors. There's lots of tuners, since I haven't really decided on an ideal tuning. I encourage experimentation! I'll explain a bit of how these governors work before actually listing the tuners.
Generally speaking, there are two modes: in "normal" mode, sampling is done occasionally and frequency is generally increased slowly; in "interactive" mode, sampling is done much more quickly, and frequency increases much more quickly. "Interactive" mode ends after several samples of very low usage. The idea of a "hispeed" frequency is used in lots of governors, and it refers to the frequency that the CPU will jump to when more CPU usage is needed; generally, it's a generous estimate of how much CPU will be needed. Here, the hispeed frequency is adjusted on-the-fly, increasing when more CPU is needed and gradually decreasing when the CPU is idle. In "interactive" mode, the hispeed frequency is kept fairly high so that everything will feel snappy.
Hotplugging is taken care of in the least complicated (and in my opinion, most reasonable) way possible: if core 1 is using lots of CPU, and there are several tasks running (in other words, if it's likely that core 2 will have something to do), core 2 is turned on; if either core isn't doing much except using power, core 2 is turned off.
sampling_rate: the usual
hotplug_up_cycles: number of consecutive heavily-loaded samples before core 2 is turned on
hotplug_down_cycles: number of consecutive lightly-loaded samples before core 2 is turned off
hotplug_up_load: number of running tasks required to bring core 2 online
hotplug_up_usage: number of used CPU cycles (in thousands per second) required to bring core 2 online
hotplug_down_usage: number of used CPU cycles (in thousands per second) required on both cores to keep core 2 online
overestimate_khz: number of CPU cycles to overshoot usage by in "normal" mode
hispeed_thresh: if CPU usage is within this many cycles (in thousands per second) of the maximum frequency, frequency will be increased to the hispeed frequency. Generally, hispeed is pretty low in "normal" mode, and fairly high in "interactive" mode.
hispeed_decrease: when the CPU is sitting idle, the hispeed frequency is decreased by this amount each sample (this isn't ideal, but it works)
interaction_hispeed: the initial hispeed frequency when switching to "interactive" mode
interaction_return_cycles: number of consecutive lightly-loaded samples before returning to "normal" mode
interaction_return_usage: number of used CPU cycles (in thousands per second) required to stay in "interactive" mode
interaction_panic (nanolunch only): when set to 1, allows aggressively jumping past the current hispeed frequency under some circumstances
interaction_sampling_rate/overestimate_khz: equivalent to the "normal" versions of the tuners, these take effect in "interactive" mode
Look promising
kruse1944 said:
Look promising
Click to expand...
Click to collapse
Wow you're quick!
Let me know how it works for you. Happy flashing!
Thanks for your work:good:
Is it just me or is the voltage table backwards, higher voltages for lower cpu speeds?
Sent from my SGH-T999 using xda app-developers app
Am I missing something? Where do I dl d2tmo?
Sent from my Wicked fast SGS3!
akapaul26 said:
Am I missing something? Where do I dl d2tmo?
Sent from my Wicked fast SGS3!
Click to expand...
Click to collapse
You download the att one. Works for tmo.
Sent from my SGH-T999 using Tapatalk 2
robertd0619 said:
You download the att one. Works for tmo.
Sent from my SGH-T999 using Tapatalk 2
Click to expand...
Click to collapse
Thanks for helping out. :good: I'll change the file name to be more obvious shortly.
darjama said:
Is it just me or is the voltage table backwards, higher voltages for lower cpu speeds?
Sent from my SGH-T999 using xda app-developers app
Click to expand...
Click to collapse
Bizarre. The tables are all correct and should display correctly, but your app is probably expecting a slightly different format. What app are you using? I'll try to figure out what's going on.
This kernel works great thanks I'm on pac rom. Thanks
aaaaaaaaahhhhhhhhhhhhhhh help me
decimalman said:
Thanks for helping out. :good: I'll change the file name to be more obvious shortly.
Bizarre. The tables are all correct and should display correctly, but your app is probably expecting a slightly different format. What app are you using? I'll try to figure out what's going on.
Click to expand...
Click to collapse
just took a look at your acpuclock tables, the first table uv to 1400000 but others don't match. nomal and fast should match up with one another from my experience. The multipliers seem good tho
ayysir said:
just took a look at your acpuclock tables, the first table uv to 1400000 but others don't match. nomal and fast should match up with one another from my experience. The multipliers seem good tho
Click to expand...
Click to collapse
The tables I'm using are the stock tables from CM & Samsung (obviously with extra frequencies added as well). I've deliberately kept the standard voltage setup (minimum voltage, different voltage tables for each PVS bin, etc.), although by default I disable the minimum voltage during boot.
On the other hand, at 2106 MHz, the PVS bin probably doesn't matter, and all three bins probably need the full 1.4 V. My processor undervolts nicely, so I don't have a good sense for what voltage is required when overclocking. If anyone provides me tables that work for them, I'll update the higher voltages.
LOL the multipliers should be fine except the ridiculous 2.5 GHz typo that should never have been committed.
decimalman said:
The tables I'm using are the stock tables from CM & Samsung (obviously with extra frequencies added as well). I've deliberately kept the standard voltage setup (minimum voltage, different voltage tables for each PVS bin, etc.), although by default I disable the minimum voltage during boot.
On the other hand, at 2106 MHz, the PVS bin probably doesn't matter, and all three bins probably need the full 1.4 V. My processor undervolts nicely, so I don't have a good sense for what voltage is required when overclocking. If anyone provides me tables that work for them, I'll update the higher voltages.
LOL the multipliers should be fine except the ridiculous 2.5 GHz typo that should never have been committed.
Click to expand...
Click to collapse
hmm your correct just took a quick gander at cm's tables. I say try increase the voltages accordingly and see if it makes a difference in readings
decimalman said:
Bizarre. The tables are all correct and should display correctly, but your app is probably expecting a slightly different format. What app are you using? I'll try to figure out what's going on.
Click to expand...
Click to collapse
I'm using set cpu. Thanks for looking into it.
Sent from my SGH-T999 using xda app-developers app
darjama said:
I'm using set cpu. Thanks for looking into it.
Sent from my SGH-T999 using xda app-developers app
Click to expand...
Click to collapse
I'm guessing this was an oversight on my part. I don't actually have the app, but I'm testing a bunch of fixes for a handful of different apps now. I'll push a test build (hopefully) later today that should get Voltage Control, Kernel Tuner, and maybe even SetCPU all working properly.
darjama said:
I'm using set cpu. Thanks for looking into it.
Sent from my SGH-T999 using xda app-developers app
Click to expand...
Click to collapse
New test build should get SetCPU working properly. If you get a chance, will you try flashing this test build and letting me know if it works for you?
decimalman said:
New test build should get SetCPU working properly. If you get a chance, will you try flashing this test build and letting me know if it works for you?
Click to expand...
Click to collapse
That seemed to fix it, thanks!
Sent from my SGH-T999 using xda app-developers app
darjama said:
That seemed to fix it, thanks!
Sent from my SGH-T999 using xda app-developers app
Click to expand...
Click to collapse
Great! If I don't run into any problems with the changes I made, I'll merge everything and it'll be in the next release.
robertd0619 said:
You download the att one. Works for tmo.
Sent from my SGH-T999 using Tapatalk 2
Click to expand...
Click to collapse
I figured as much. But was not 100% thanks
Sent from my Wicked fast SGS3!

[GUIDE] [STARTER] (Custom) Kernel Features Explained! - NEW FEATURES [06/30/2013]

This is a simple STARTER GUIDE to kernel features/parameters and everything you need to know about custom kernel goodies before you consider flashing them. I’d be glad if you could help me complete this guide. Thanks to @Shan89 for his fantastic guide which inspired me to collect this.
First of all I’d like to thank all kernel guys who put countless hours into this to bring us the features which I am going to explain soon. Especially: XMister, n3ocort3x, Kozmikkick, Maxwen, Showp1984, faux123, TripNRaVeR, Alex-V.
Overview:
Post 1:
A.: What you want to know about the CPU/GPU of your device
B.: Custom Kernel Features
Post 2:
C.: Built in kernel features with no user control
D.: FAQs (Frequently Asked Questions)
More coming Soon!!!
Post 3:
E. Repacking
F. Useful Tools and Guides out there
More coming Soon!!!
A: What you may want to know about the CPU/GPU of your device:
HOX is powered by nVidia Tegra 3 which is a Quad Core CPU and it is said that have a Core Frequency of 1.5GHz. Also nVidia Tegra 3 comes with ULP Geforce GPU which is at 520MHz in all custom kernels available. You may want to know that your HOX can go up to 1.5GHz of single core and 1.4GHz of 4cores active with Stock kernel (The kernel that comes with your device out of the box). However custom kernels can perform 1.5GHz for all 4 cores.
nVidia Tegra 3 is in fact a 5 core chipset. The Advertising hype was about its 4+1 cores. So what is that one extra core? That core is called LP (Low Power) core. When the phone is in idle (sleep) this core is used. It is a weak core with 475MHz of processing power. It is there to save battery life as when we are in idle we do not need a whole 1.5GHz core to be active.
B.1: CPU/GPU/IO Features which come with Custom Kernels:
•NOTE: Enabling/Disabling these features are explained in the kernel forums. Here is a very simple example to get you up and running so that you don’t feel lost.
In the kernel forum it is said:
To enable S2W:
echo ‘1’ > /sys/android_touch/sweep2wake
So what on the earth does that mean?! It means install a terminal emulator program on your device (Here’s one). And then run it. First type “su” without the quotation marks and hit enter. It will ask for Superuser privileges. Grant it. Now type in the line above echo blah blah blah and hit enter. And bam! There you go, S2W is enabled. Always be advised that ‘1’ means enable and ‘0’ means disable.
Click to expand...
Click to collapse
OC/UC (As for OverClock/UnderClock):
As you may know, CPU or any other processing unit features a clock frequency. Over/Under Clock simply means raising/decreasing the clock frequency of CPU.
Reason: Why would one need to overclock? Because one needs more processing power. For example if you want to experience smoother graphic when playing high-graphic games.
Why would we need underclock? Higher processing power demands more battery. So underclocking helps us, reserve more battery. As for HOX, searching internet and texting don’t need much of processing power. So we can limit the processing power and save battery during low use of our device.
•Note1: OC/UC is not limited to CPU. GPU is also capable of OC/UC. And the interface for that is also available in the custom kernels of HOX.
•Note2: Gamers may not use GPU UC. Limiting GPU processing power impact significantly on your gaming experience.
UV (As for Undervolt):
Every frequency of a processing unit, demands a certain amount of power to be supplied. Undervolting to put it simple means decreasing the voltage of a certain frequency (or all of them).
Reason: The more voltage CPU/GPU gets, more heat will be generated. So mainly we UV to decrease the generated heat of CPU/GPU.
•Note1: One Frequency needs a certain minimum amount of voltage to perform correctly and the system be stable. Undervolting more than a certain amount of voltage will cause system instability.
•Note2: HOX is known for getting hot soon. So UV is a great workaround for your device to be cooler.
•Note3: UV does not impact battery life (or it is not noticeable).
•Note4: For ULTIMATE guide about Undervolting and safe values visit Shan89’s great guide here.
Separate X/Y OC interface:
This probably means that the kernel has separate OC interface (interface to control OC) for operation X and operation Y. To be more exact it means you can OC different values for X and Y.
Audio Min. Freq.:
This specify the minimum frequency of the CPU when Audio is being processed. Default min in custom kernels is normally 51MHz. But Audio needs some more processing power. Anyhow, with this you can change that value.
LP Core OC:
The name explains everything. OC for LP core of T3 chipset.
Reason: LP core uses very little battery. So as long as the phone stays at LP core, more battery will be saved. If LP is OCed, it means it can handle more complex processing tasks and can hold more before letting the device to wake main cores. So battery will be preserved!
•Note: These are work in progress features and mostly in beta releases of Kernels. So using may cause system instability and other issues. So use them if you know what you are doing.
Hotplug Control - NEW:
Hotplugging dynamically activates second CPU core ON on load conditions and turns second core OFF on low load conditions. (From here).
Click to expand...
Click to collapse
- first_level: The number here specifies the amount of load on the cpu for it to turn on all the available cores (4 cores online).
- cores_on_touch: This number specifies the number of cores to come online when you touch the screen. (2 is efficient, 4 for extra smoothness on touch, and so more battery drain.)
- suspend_frequency: When screen is off, you don't expect your device to be smooth (!!!) and snappy! Because mainly nothing important is happening when screen is off. The number here specifies the maximum frequency of the CPU when the screen is off. Screen Off Max CPU can be really a very low number.
CPU Governors:
Frequency scaling is the means by which the Linux kernel dynamically adjusts the CPU frequency based on usage of the device. Governors refer to schemes which dictate to the kernel how it should do these adjustments. (From rootzwiki)
To put it simple, Governors are the way that CPU frequency is adjusted according to the demand of operating system.
Selecting a proper governor for your CPU is crucial to the performance and battery preserving of your device. For example if you are low using your device you may use a more battery friendly governor and if you want to play games you may use a more power consuming performance governor.
•Note: See Shan89’s Great Guide about Governors to be familiar with each one of them and the ones that you should use in different situations here.
I/O Schedulers (As for Input/Output):
Input/output (I/O) scheduling is the method that computer operating systems use to decide which order block I/O operations will be submitted to storage volumes. I/O Scheduling is sometimes called 'disk scheduling'. (From Wikipedia)
To put it simple, Schedulers are the way reading and writing to the SD card is managed.
The same things that is said in the Governors part is applied here, too.
•Note: See Shan89’s Great Guide about Schedulers here.
ReadAhead buffer size:
In terms of reading data from SD card, there is a cache which is used as a buffer. The size of that cache is readAhead buffer size. The size has a direct impact on your reading speed of your SD. So giving it a right amount is crucial.
•Note: Kernel guys believe that 128 is the right amount for that and it is the default in most of the kernels.
File System “X” R/W (As for Read/Write):
Android by default doesn’t support all the File Systems (What are file systems?! See here). So some kernels may add certain file system R/W. The most popular unsupported file system is NTFS.
B.2 Features of Custom Kernels (AKA Goodies!!!):
S2W (Sweep2Wake):
With S2W enabled you can wake/lock your device by sweeping your finger from left to right (or right to left) on the hardware keys of your device (Pretty Cool, hah?).
Reason: Some people just don’t like the hardware power button! Or after some time it will become less responsive. And some will use S2W because it is cool!!!???
•Note1: S2W doesn’t affect battery life that much. It almost does not use even a little bit. But be aware this stands corrected as long as you don’t touch your device. Touching the device would cause in waking the device from deep sleep.
DT2W (Double Tap 2 Wake):
It is something like S2W to wake the device. Double tap on the screen to wake the device.
•Note: The note for S2W applies here, too.
BLN (BackLight button Notification):
With BLN enabled your hardware buttons will blink when you have notifications. It is an/a alternative/support for led notification.
FastCharge:
This feature makes it possible for the phone to ask for more current from USB host. So your device would be charged faster connecting to a USB host (Or USB Battery) Be aware that enabling FastCharge would block the USB access to your Phone Storage.
UMS (USB Mass Storage):
After ICS, google only allows MTP connection to the PC. Back at ICS there was a UMS which make available your Phone Storage as a Mass Storage device in PC. The Mass Storage advantage is that you can manipulate data on it but it cannot be done using MTP. UMS feature returns that feature to your device. A system interface is also needed which is available in ViperX ROM or Lyapota’s mod.
•Note: MTP vs UMS (From here):
MTP:
1. Can copy files over (like APKs) and then access on them on the device without mounting/unmounting.
2. File transfer is available immediately when plugged in without having to mount.
Mass storage:
1. Better security since you have to get past the lock screen to mount.
2. Is actually a real drive in Windows, so you can do all operations normally.
MHL (Mobile HighDefenition Link):
It provides the feature for the miniUSB to HDMI cables to work. To output the device screen using HDMI.
SmartDimmer:
SmartDimmer can intelligently vary the backlight brightness of your device screen to help maximize battery life.
•Note: Haven’t really tried this. You may try it yourself and see how it is.
MultiCore PowerSaving:
This feature try to group up tasks in the least cores possible. To put it simple, it will focus in using least cores for your tasks to be done. This means less cores are active and so more battery life. Also this will decrease performance.
•Note: To enable use TricksterMod app. 0 for disable and 2 for the most aggressive.
Core Control/Max Active CPU Cores:
As the name suggests, this feature allows the user to set the maximum active cores of the CPU. In other words, you can completely shut down some cores. The default value is 4 as we have 4 max active cores. you can reduce this to 3, 2 or 1. But 1 is not really recommended.
Note: Core Control is the feature of ViperX ROM.
B.3 Other Features:
Pocket Protection - NEW:
Using features like S2W and/or D2TW when the phone is in your pocket (with no specific cover) occasionally causes the screen to turn on. (as a result of being close to your skin and almost touching it). This feature is there to prevent such wake ups. It uses proximity sensor to determine if the phone is in a closed position to something. If that is true, the screen won't turn on. :victory:
Swap:
Swap is a space which provides help to RAM in situation of low memory. When you are low in RAM some data will be stored in Swap space (Mostly cache). Swap is a space on Internal (and/or External Memory) so swap is not fast in comparison to RAM, but it helps multitasking, because you could cache more app data to your memory. So the results are less Force closes because of low RAM and faster switching between apps.
Swap is not really used by default, or it is used with very low space. You can boost your Swap, and also know more about this. there's a very nice MOD called Turbo Boost which allows you to add more Swap using your unused space. See this.
zRAM:
In zRAM unnecessary storage resources are compressed and then moved to a reserved area in the fixed RAM (zRAM). So in other words, zRAM is a kind of swap in memory (see swap above). As the data is compressed not much memory needs to be preserved as zRAM. However, the CPU has to work more because compressed data has to be unpacked again when it is needed). The advantage clearly lies in the speed. Since the swap partition in RAM is much faster than this is a swap partition on a hard drive.
In itself a great thing. But Android does not have a swap partition, and therefore brings Android ZRAM under no performance gain as would be the case with a normal PC. (From here with some editing.)
Click to expand...
Click to collapse
What we need to know essentially lies here:
zRAM off = Low use data will be stored the way they are in the memory. This will cause no extra load on CPU, yet need more RAM.
zRAM on = Low use data will be stored compressed in the memory. This will cause extra load in CPU as to store or restore data, yet preserve more Free RAM.
The main use of zRAM is when you are using a heavy ROM that eats up all your RAM. This will allow multitasking to be more functional. On light ROMs, or for those who don't multitask much, this is not necessary.
Init.d Support:
There are some scripts that run every time your device boot up which are located in /etc/init.d Those are called init.d scripts. One of the most popular init.d scirpts that is available for Note 10.1 is this.
DriveDroid Support:
Gives the phone the ability to use DriveDroid.
DriveDroid allows you to boot your PC from ISO/IMG files stored on your phone. This is ideal for trying Linux distributions or always having a rescue-system on the go... without the need to burn different CDs or USB pendrives.
Click to expand...
Click to collapse
Take a look here for more information.
TCP Congestion Control:
The choices in this section, address how the operating system kernel manages flows of information in and out of the kernel, which is at some level the "switchboard operator" of your handset. More info here.
Better to leave this options as is. Cubic as the default of your kernel.
Dynamic FSync:
fsync is a system call in Unix/Linux. "man fsync" says:
fsync() transfers ("flushes") all modified in-core data of (i.e., modified buffer cache pages for) the file referred to by the file descriptor fd to the disk device (or other permanent storage device) so that all changed information can be retrieved even after the system crashed or was rebooted. This includes writing through or flushing a disk cache if present. The call blocks until the device reports that the transfer has completed. It also flushes metadata information associated with the file (see stat(2)).
Click to expand...
Click to collapse
So it's something embedded in programs after a related set of write operations to ensure that all data has been written to the storage device. The bolded part is what makes it interesting for some to disable it - "The call blocks" means the calling program waits until it's finished, and this may create lag. The downside is that if the system crashes, the data on the storage devices may be inconsistent, and you may lose data. (From here).
Dynamic FSync, makes it possible for fsync operation to be asynchronous when the screen is on, and synchronous when the screen is off. And what does asynchronous mean? Means OS issues fsync call, but not necessarily immediately at commit time for each transaction. It delays the FSync call for a certain amount of time. In case of a crash, the transactions not yet sync'ed in the last delay time before the crash may be rolled back, but the state of the data is always consistent. (From here).
Work in progress, will add more info soon.
C. Some built in features with no user control:
Tegra 4 Drivers - NEW:
First you may want to know what a driver is:
A driver is a small piece of software that tells the operating system and other software how to communicate with a piece of hardware.
For example, all printers come accompanied with drivers to install that tell the operating system exactly how to print information on the page. (From here).
Click to expand...
Click to collapse
So kernel guys (Trip to be exact) made it possibe to use some Tegra 4 drivers on Tegra 3 Chip of HOX so that we can enjoy the advantages of new drivers.
MPDecision:
Mpdecision decides when the second core shall be active and sets the idle and screen off freq while the governor decides when the freq should be increased / lowered.
More info at this thread.
CPU Quiet:
It's a dynamic CPU core management. More info here.
D. FAQs (Frequently Asked Questions)
MUST KNOW FACTS:​
The modifications and changing values of kernel parameters will stick until the next reboot. They will be set to default when you reboot your device. So if you want them to stick, you have to do one of the following:
1. Init.d Scripts: Here is a complete guide, how to make one. Also you can use 'CS' app. Which is explained in Useful tools part of this guide (Post 3).
2. Set on Boot: The programs like Trickster Mod, have an option named 'Set on Boot'. If you want the settings you have in Trickster to stick, you have to check that option.
---------------
And a quote from the elite developer that everyone know:
However, if you put any trust in Quadrant scores you could use them to prove that dancing naked for 5 minutes in your garden affects device performance. - Chainfire
Click to expand...
Click to collapse
Q. I'm on Stock. How can I flash a custom kernel?
A. See this complete Tutorial, here.
Q. Is it dangerous to flash a custom kernel?
A. As long as you follow the instructions step by step there shouldn't be any problems. However flashing is always at your own risk.
Q. Why would I need to flash a custom kernel?
A. Because of the goodies I described in post 1.
Q. Which Kernel is more suited for me?
A. That really depends on you. You have to try the kernels and see which one is more suited for you. In Post 3 A little description about the kernels will be provided.
Q. AOSP or Sense???!!!
A. Sense Roms can be identified by their description. Just visit the page of your desired ROM and see what is its base. If it has 'stock' as the base it's sense ROM. If it has AOSP, AOKP, CM or other things then it is an AOSP rom. So identify your base before flashing kernel.
Q. I don't like this fastboot stuff. Why HOX can't flash boot via recovery?
A. That is because something called S-ON (Security-On) by HTC which prevent flashing boot.img via recovery.
Q. Repack?! What on earth is that?
A. Repack will be elaborated in detail in Post 3.
Q. Is repack needed for Kernel X and ROM Y?
A. See Repacking in post 3.
Q. Is there a kernel with OC interface up to 1.6 or 1.7?
A. Yes. Search!
Q. I just want S2W or UMS with Stock kernel, nothing more. Is there a kernel to provide that?
A. Yes, Alex-V Kernel v.0.3 is there for you. See Post 3 when it's ready for more info.
Q. After installing custom kernel I am experiencing battery drain issues. Why is that?
A. The current custom kernels do not have drain issues. Install Better Battery Stats and/or GSam Battery Monitor to figure out what is causing the battery drains.
More Info will be added soon.
E. Repacking:
All Android roms require a boot image to work (normally named boot.img). These files contain the ramdisk necessary to run the rom, as well as the kernel. Occasionally you may want to replace the kernel to add new features or fix bugs, but you must tweak the image to be compatible with your rom (And also as the ramdisk may contain some tweaks, to preserve those tweaks and add them to the kernel of your choice). (From Here).
Click to expand...
Click to collapse
The very main question "Is it really needed?"
Well, you don't really need to repack kernels for Sense/AOSP Roms anymore (Those days are gone!) as they already contain the tweaks and ramdisk to get almost all the ROMs up and running. But sometimes you may encounter some problems like Weak signal/Wifi or such issues. In that case, it is advised to repack your kernel.
How to Repack?
Before you start repacking you need these 2:
1. Ramdisk (boot.img) of the ROM you are using (Or you wish to use). It is usually in the zip file of The ROM which you flashed (or going to flash) via recovery. Just open the zip file and extract boot.img. Some ROMs put the boot.img in their OP (First posts of the respective thread). So if the ramdisk wasn't in the zip file of the ROM, take look at the thread of the ROM.
For preventing the confusion rename the boot.img to the ROM name + ROM version for example Renovate_F4.img
2. Kernel image (boot.img) of the Kernel you wish to use. Some kernels put it for download in their thread. Sometimes modules and image is both in one archive. In that case open the zip file if the kernel and extract boot.img. Make sure you don't replace the other boot.img from step 1. For preventing the confusion rename the boot.img to the kernel name + kernel version + the kernel base(Sense/AOSP) for example XM_305_Sense.img
Click to expand...
Click to collapse
a. Using online repacker:
1. Visit this site: http://nibble.cc/repack/index.php
2. In source kernel image, choose the ramdisk of the ROM. (ex. Renovate_F4.img)
3. In New kernel image, choose the kernel image. (ex. XM_305_Sense.img)
4. Hit 'upload and repack'.
5. Download the repacked kernel.
b. Using One Click Tool:
1. Copy the ramdisk and the kernel image to "kernels" folder which is in the folder of the tool.
2. Connect your device and run the tool.
3. Select "Kernel repack".
4. Select the kernel image in "kernel" section.
5. Select the ramdisk in the "ramdisk" section.
6. Hit "perform action".
7. The repacked kernel is in the "repacked" folder which is the folder of the tool. It's name is a combination of The kernel name and the ramdisk name so that it can be identified easily.
Note: You can also choose to flash the kernel. Just check "Flash repacked kernel". The tool automatically reboots into fastboot and flashes the kernel.
Note: You can choose to repack via PC in the tool. It is much more faster. And also you can repack without connecting your phone if you choose repack via PC (This feature works from version 2.1 or 2.0 I think. Check the thread for more info).
F. Useful Tools and Guides out there:
F.1. Tools:
Trickster Mod:
A little yet powerful program. It is almost the best tool that you can have on your HOX to change certain kernel parameters like UC/OC/Voltage Control of both CPU and GPU. Schedulers, ReadAhead BufferSize, Advanced Governor control. You can change features like S2W and SmartDimmer, too. Also you can set this changes to take effect on boot. Which automatically sets the parameters on device startup (preventing the defaults values to be set, again).
Trickster Mod - Google Play
CS - Custom Settings:
This app is exclusively made for HOX, so it supports most of the features of custom kernels. This app manages to set the values you desire by generating init.d scripts. So there is no set on boot operation by the app but by the scripts.
Custom Settings - XDA
One Click Tool:
This tool is created for One X, and you use it to repack and flash kernels. And by flashing I mean no CMD and other scripting stuff. This tool automates flashing (Though the flashing process via fastboot is not that much of a hard work!).
One Click Tool - XDA
F.2. Guides:
- Battery Life and Gaming Guide + UV/UC and everything explained! by Shan89
- Boosting gaming experience and maximizing performance for gaming by hamdir
More info will be added soon.
Reserved for later reading
Sent from my HTC One X using XDA Premium App
Desaf said:
Reserved for later reading
Sent from my HTC One X using XDA Premium App
Click to expand...
Click to collapse
Yeah, sure!
Sent from my HTC One X using Tapatalk 2
Added recently to the guide:
Post 1:
- ReadAhead buffer size
- Init.d
- TCP CC
Post 2:
- FAQs.
realy helpful
thanks mate for the information.
mandrive said:
thanks mate for the information.
Click to expand...
Click to collapse
Glad to be of help!
Sent from my HTC One X using Tapatalk 2
Recent added to the OP:
- Swap (In appearance of the nice Mod TurboBoost)
- Dynamic FSync (Tricky feature)
Will be added soon:
- Repacking
Nice tut
Sent from my HTC One X using xda app-developers app
Alex-V said:
Nice tut
Sent from my HTC One X using xda app-developers app
Click to expand...
Click to collapse
Thanks, man.
Sent from my GT-N8000 using Tapatalk HD
csec said:
Thanks, man.
Sent from my GT-N8000 using Tapatalk HD
Click to expand...
Click to collapse
Added with credits to my kernel thread..thx again
Sent from my HTC One X using xda app-developers app
Recently added:
Post 2:
- TEGRA 4
Post 3:
- Repacking
Will be added soon:
- Kernels reviews
Huuuuge guide
matt95 said:
Huuuuge guide
Click to expand...
Click to collapse
Just wanted to be a complete guide. Explaining everything.
Sent from my GT-N8000 using Tapatalk HD
csec said:
Just wanted to be a complete guide. Explaining everything.
Sent from my GT-N8000 using Tapatalk HD
Click to expand...
Click to collapse
You succeeded in it
matt95 said:
You succeeded in it
Click to expand...
Click to collapse
Thanks. Glad I could contribute to the community. :good:
Sent from my GT-N8000 using Tapatalk HD
csec said:
Audio Min. Freq.:
This specify the minimum frequency of the CPU when Audio is being processed. Default min in custom kernels is normally 51MHz. But Audio needs some more processing power. Anyhow, with this you can change that value.
Click to expand...
Click to collapse
Thanks for the guide.
I'm using CyanogenMod right now and I'm having problems with Audio over Bluetooth with the low power core of my endeavoru. I think increasing this frequency might help.
How is this called in kernel-land a.k.a. how do I find instructions regarding this? Asking Master Google was of no help, as I only found custom variants of the CyanogenMod kernel.
lordtillt said:
Thanks for the guide.
I'm using CyanogenMod right now and I'm having problems with Audio over Bluetooth with the low power core of my endeavoru. I think increasing this frequency might help.
How is this called in kernel-land a.k.a. how do I find instructions regarding this? Asking Master Google was of no help, as I only found custom variants of the CyanogenMod kernel.
Click to expand...
Click to collapse
What is your kernel and version?
What governor, what frequency?
What kind of problem are you having with your audio?
csec said:
What is your kernel and version?
What governor, what frequency?
What kind of problem are you having with your audio?
Click to expand...
Click to collapse
I'm running CyanogenMod 10.1 RC2 with the default kernel, which is the 3.1.10-cyanogenmod+inky-ghost kernel, according to About Phone.
Governor is ondemand, and the frequency is untouched - meaning, CyanogenMods defaults (51<f<1500).
The audio sometimes stutters, when I'm using my bluetooth headphones and the screen is locked - I assume, that's due to the low power kernel of the tegra chipset.
Can you help finding that setting, or recommend a good replacement kernel?

what's is smart cpu efficiency explain in details please?

recently miui add a new feature called smart cpu efficiency but I wanna know more about this feature and how it's works and after are the pro and cons in full details please and is it really a good feature please answer as soon as possible....
Guys behind MiUI aren't exactly the "brightest" one's so it's just a fancy name, all do it whose not been to hard to do a better tuning than they did on "8". The CPU is regulated trough three part's; governor, HPM scheduler and hotplug. I won't discuss it there is plenty documentation provided, you just need to search for it and make comparation between vendors (OEM's)...
its just the fancy name
Zola III said:
Guys behind MiUI aren't exactly the "brightest" one's so it's just a fancy name, all do it whose not been to hard to do a better tuning than they did on "8". The CPU is regulated trough three part's; governor, HPM scheduler and hotplug. I won't discuss it there is plenty documentation provided, you just need to search for it and make comparation between vendors (OEM's)...
Click to expand...
Click to collapse
I get your point that it's just a fancy name but I wanna know how actually work and how it effect on cpu and how good it is or bad because as I seen this feature active by security app by miui and it just turn down A-72 1.80ghz core to A-1.40ghz and and doesn't even let the device use this and force the device to use A-53 1.40ghz core which is killing my device and it's performance and multitasking help me out with this is true or wrong
https://ibb.co/dAYP9Q
BG. said:
I get your point that it's just a fancy name but I wanna know how actually work and how it effect on cpu and how good it is or bad because as I seen this feature active by security app by miui and it just turn down A-72 1.80ghz core to A-1.40ghz and and doesn't even let the device use this and force the device to use A-53 1.40ghz core which is killing my device and it's performance and multitasking help me out with this is true or wrong
https://ibb.co/dAYP9Q
Click to expand...
Click to collapse
Basically it's a corectl hotplug which is one of the three parts (the last one in hierarchy) that are used for CPU control others are HPM sched which is highest priority & rather complicated & CPU governor. Hire is a catch HPM sched whose broken in the kernel code we got from Xiaomi & after lots of work it's now patched to work properly (as much as possible). I don't know the state of the code in MiUI nor could I but I am pretty much certain that they didn't do a homework. Nor do I know the parameters they used to configure all tree parts. The 1.4 GHz is biggest long time sustainable frequency for the A72's on S65x SoC's & even that much if only up to two active. That isn't the problem, which leads me to believe that problem is a hotplug configuration as it's lagging behind in activating big cores and naturally HMP sched places the task on the first ready core that meets the demand the best of those available. Actually hotplug needs around 150~200 microseconds to wake up the core so it's ready to be used while HPM sched and governor make a decision in one circle or less which is 20~40 ms usually while migration from one to another core takes between 50 to 90 ms. So you see hotplug can't keep up with them nor it will ever can. That's why you need at all times to have at least one active core per each & every cluster (preferable & optimal by my findings is two & every second one starting with first so that the L2 cache is always active fully [this brings down transition times to 50 Ms]). If you have root feel free to play with it as you will find it im QC power init & you can read about settings hire at XDA (Mi Max) on power performance optimisations thread.
Best regards.
So after all it turns out to be dumb & by all means far north from efficient. Typical MiUI.
Zola III said:
Basically it's a corectl hotplug which is one of the three parts (the last one in hierarchy) that are used for CPU control others are HPM sched which is highest priority & rather complicated & CPU governor. Hire is a catch HPM sched whose broken in the kernel code we got from Xiaomi & after lots of work it's now patched to work properly (as much as possible). I don't know the state of the code in MiUI nor could I but I am pretty much certain that they didn't do a homework. Nor do I know the parameters they used to configure all tree parts. The 1.4 GHz is biggest long time sustainable frequency for the A72's on S65x SoC's & even that much if only up to two active. That isn't the problem, which leads me to believe that problem is a hotplug configuration as it's lagging behind in activating big cores and naturally HMP sched places the task on the first ready core that meets the demand the best of those available. Actually hotplug needs around 150~200 microseconds to wake up the core so it's ready to be used while HPM sched and governor make a decision in one circle or less which is 20~40 ms usually while migration from one to another core takes between 50 to 90 ms. So you see hotplug can't keep up with them nor it will ever can. That's why you need at all times to have at least one active core per each & every cluster (preferable & optimal by my findings is two & every second one starting with first so that the L2 cache is always active fully [this brings down transition times to 50 Ms]). If you have root feel free to play with it as you will find it im QC power init & you can read about settings hire at XDA (Mi Max) on power performance optimisations thread.
Best regards.
Click to expand...
Click to collapse
thanks for helping out
Well I hope you are satisfied with explanation.
See you later alligator.
Zola III said:
So after all it turns out to be dumb & by all means far north from efficient. Typical MiUI.
Click to expand...
Click to collapse
could you please give me few simple examples regarding this issue so I can post and point out on the form
BG. said:
could you please give me few simple examples regarding this issue so I can post and point out on the form
Click to expand...
Click to collapse
Their is no simpler explanation.
The numbers I presented are extrapolated from numerous analysis published as scientific works all available floating around the net.
A) hot plug is relatively slow (not because of it self but) as awakening from deep retention states on all ARM CPU's up to date takes time (to init & test/flush queues and RAM subsystem integrity)
B) HPM scheduler is designed to place the work on first available ready CPU core that best meets the demand (dependant on given idle/packing parameters assigned to HPM)
C) hotplug will never be able to awake any core in deep retention state on time for a HPM decision timing
D) all transitions from one to another core (no matter which one) is costly.
So in short what could & needs to be done;
A) Ensure that at least one CPU is always active per cluster
B) Ensure that HPM is properly configured & running as intended (migration load, packing & idle conditions)
C) Minimise transition times (by providing optimal setup) and minimise their number.
How to achieve this?
Well;
A) properly configure hotplug disabling it to power down control core's that are needed to stay online all the time (this excludes the device sleep), example (of a 2+2 always on configuration on a octa core dual cluster SoC [S652]);
write /sys/devices/system/cpu/cpu0/core_ctl/not_preferred "1 0 1 0"
write /sys/devices/system/cpu/cpu4/core_ctl/not_preferred "1 0 1 0"
write /sys/devices/system/cpu/cpu4/core_ctl/is_big_cluster 1
B) there are two approaches with HPM super packing (Sony) & absolute idle load (Xiaomi on MiUI 8) both tied to min CPU's active and all CPU's active how ever the both approaches are wrong, high enough init with limited packaging & giving idling cores advantage is really the best way to go along with providing ideal conditions of available core's (which is 2+2)
C) this two already implied hire together make the ideal possible setup for a task placement & minimising the up/down migration times plus if set as shown (when possible) ensures the usage of all L2 cache available along with exclusive access, it also provides faster awakening of other core's when they are needed from deep retention state. The power drive cost is the same as the performance gain (5~6%) so for given job the power consumption is exactly the same while other positive effects remain. Additionally it's good to prevent up migration of the tasks that are lower priority & flagged as background tasks.
Notes:
1. If enabling the described hotplug configuration on the A53 cluster make sure that it's enabled only on the V2 revision of the core's & that the tool chain (compiler) is set to the strict ID-ing of the core revision along with no A53 erratums forced.
2. The given 2+2 configuration covers all possible scenarios of the thread migrations including SMP one's & it's considered as optimal one by me.
3. In order for this to work properly (& anything else for that matter) the general scheduler patching is required which is available in nijel8 Github kernel repository (mainline port fixes and mostly from Petr).
4. Alternative setup is all four A53 cores active with one A72 core's active all the time, it provides some power saving (in idle and low load states mostly) compared to 2+2 (with A72 core's which falls close to none with A73 core's) but it doesn't cover SMP up migration case along with minor performance degradation. The rest part remains the same.
Feel free to quote me.
As I believe in good old healthy logic which this is I don't find it particularly "smart" one either.
Best regards.
@Zola III
Another worthy input from you regarding performance/power saving... :good:
I will quote you in the performance thread so this not get lost here along with a question... See you there.
nijel8 said:
@Zola III
Another worthy input from you regarding performance/power saving... :good:
I will quote you in the performance thread so this not get lost here along with a question... See you there.
Click to expand...
Click to collapse
Well it's pretty much not anything new nor something we didn't try already together & most of the stuff you already implemented.
Cheers!
thank you guy thank a lot for all your help

Red Magic 5G MOD Kernel GPUOC 900/940mhz +battery 1.4 STABLE!

{
"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"
}
*** NOTE THAT 3.16 NA OR 4.13 Red Magic 5G SPECIFIC ROMS SHOULD BE USED WITH THIS KERNEL! THE COMBINED ROM (WITH RM5S) HAS UPDATED KERNEL CODE THAT IS NOT FULLY COMPATIBLE AND NUBIA HAS NOT UPDATED THEIR SOURCE CODE ***
*** Please click Thanks (Thumbs up icon) on my post here if you like my kernel and rate the thread 5 stars, then just use it and enjoy - if you want to send me a beer or two feel free - you don't have to use PayPal - Revolut and Amazon.com (USA) gift cards avoid fees. I like to hear from happy users I hope you are glad that you have the fastest phone in the world currently. The active cooling in this device is utilized to the extreme with MOD kernel, meanwhile your battery usage will be much improved at the same time. How? Well, that's all in the source code, free for all to fork it on GitHub and modify to your liking. Just don't forget to credit me and the many great devs that made the improvements possible... without them, there would be no MOD kernel. This is just a hobby of mine and I like to produce a nice product that all can enjoy. I'm also quite friendly and although I may tell you no I won't add that feature (such as network hacking tools), I won't hold anything against you for asking. I have not been compensated other than by some generous folks on my Telegram channel, so this whole project is basically self funded. Red Magic will not support it, unfortunately, but you can if you feel the improvements are worth it. I believe they are, but I come from a biased point of view as the sole developer for RM5G ***
********************************************************************************************************************************************************************************************************************************
NOTICE: YOU ASSUME FULL LIABILITY FOR ANYTHING THAT MAY HAPPEN TO YOUR PHONE USING THIS KERNEL. ALTHOUGH IT WORKS 100% ON MY PHONE, IT MAY NOT WORK THE SAME ON YOURS. THE PROCESS OF ROOTING A PHONE AND INSTALLING A CUSTOM KERNEL ALWAYS HAS RISKS, SO IF YOU ARE NOT COMFORTABLE ASSUMING THOSE RISKS, DON'T INSTALL THE KERNEL! THIS IS A TYPICAL DISCLAIMER FOR CUSTOM KERNELS I HAVE FOUND NO BUGS WITH IT AT ALL. USERS ON CN, GLOBAL, AND NA ALSO HAVE NOT FOUND ANY PERFORMANCE ISSUES OR BUGS (DO NOT USE V7.14 or V8.11) IF YOU DON'T KNOW WHAT YOU ARE DOING, IT'S BEST TO REMAIN STOCK. OR JOIN THE TELEGRAM GROUP, AND GET SOME REAL HELP.
********************************************************************************************************************************************************************************************************************************
Easy root method: https://forum.xda-developers.com/nu...nner-tutorial-unlock-bootloader-t4131585/amp/ although I suggest still using Magisk 20.4 for root.
Note: if you've already rooted and want to upgrade, people have had success saving the kernel as boot.img and TWRP as recovery.img in SmartPack, vbmeta skip as vbmeta.img and placing into the ROM update.zip using MT Manager (a root browser) and saving the updated file. Then do a Settings / System Update / click the 3 dots / local update and select your modified file. In fact I upgraded from 3.13 to 3.16 NA ROM without losing anything this way. Now for normal installation:
Custom kernels require root and Magisk to be installed. This is due to the signature not being signed by Red Magic (the company) itself. Following the above method you will still pass SafetyNet and most apps will work without trouble. If you have a specific app that detects root, well, Magisk Hide the app from Magisk Manager and see if that fixes it. You should also Hide Magisk Manager from various forms of detection (under Settings). Last case is to move the installation of Magisk under a random directory (which I have not had to do and all my banking apps still work), only if the root detection methods used by your app providers are more picky.
MOD KERNEL 1.4 STABLE:
RELEASE NOTES:
Block mode I/O has been changed to Multi-Queue from Single-Queue so your default scheduler is now MQ-deadline (credits to PappaSmurf, excellent kernel dev). You can choose between mq-deadline, kyber, and none in a kernel manager under I/O scheduler. From my benching with Androbench, it doesn't make much difference which one you use. Some have parameters you can tweak. None literally means no scheduler which is fine on an SSD, and has no overhead if you want to select it in a kernel manager. I always recommend SmartPack. To get settings to stick you Toggle "Apply on Boot" and it will go to what you've selected after 5-10 seconds on the next boot.
All debugging has been turned off completely on BBRv2 - thanks to PappaSmurf (I missed a few spots), and debug can't be turned back on from the userspace now. BBRv2 is selected as the default TCP algorithm which users have explained as a "no-lag" algorithm while gaming. It's just generally a fast algorithm all around. For me it works great, but you can still choose from many different algorithms in a kernel manager if you want to.
In SmartPack / Misc / TCP Congestion Algorithm, you have many choices: reno / bbr / bbr2 / bic / cdg / cubic / dctcp / westwood / highspeed / hybla / htcp / vegas / veno / scalable / lp / yeah / illinois. A SmartPack script is included below you can add in SmartPack to show the true TCP algorithm as it will always show Reno (a bug also shared by FK kernel manager). Below it's called Check_TCP.sh just go to SmartPack / Script Manager / Import / Check_TCP.sh. Afterwards, click Execute to see the active algorithm. If you set it on boot, this is the algorithm that will run, despite what the field says in Misc.
Battery is running very well on normal usage I'm getting around 7.5% active screen on drain over 7 hours and <0.7% screen off drain over 13 hours at 90hz screen setting. This is with actively using the phone for multiple "normal" purposes, reading emails, browsing websites with Chrome, reading news, streaming videos, etc. various shopping (Amazon/eBay) and tracking, Reddit feeds and live video, and other random "daily" tasks, up to 10 apps open at a time. Gaming of course will drain more, as will 144hz. I also have dark mode enabled in Settings. To get idle drain down I disabled 3 additional wakelocks that were causing high screen off drain, and so far I haven't seen an issue with blocking them. I also removed wakelocks that no longer exist since the Boeffla WL Blocker default list was created (it was quite old) so it now should be relevant for this device, with no interaction on the users part to disable anything via a kernel manager. Still, in SmartPack you will see a Wakelocks menu in case you install an app that causes idle drain to rise, this can be used to find and block wakelocks causing the problems. It can sort by wakeups and also by time. As it states though, you should be very careful what you disable. There can be unintended consequences and most wakelocks are not well documented as to what they actually control.
Dynamic Stune Boost is entirely removed from the kernel code now, as I didn't see any benefit from using it with this kernel.
Don't forget Dynamic Fsync is hidden under Misc in SmartPack which if you turn on will speed up your SQLite speeds. AnTuTu will penalize you for this, ignore it, your phone will be faster - but I leave it off by default. Androbench will show the true memory benefit. It is significant if an app does a lot of operations on databases. Journaling for the database is held in memory until the screen is off, then it is written. Although there is a chance of a data loss or corruption with this on if the device were to crash, it is safer than just turning off fsync. If you have any unstable apps, just leave it off - better to be safe. On a solid system though, you may notice better performance.
Also remember under SmartPack / GPU there is AdrenoBoost - it is set to low. You can alter to medium or high to get faster transfer between GPU frequencies, although it has worked great for me the way I use the phone. For you another setting may suit you better. Recall RedMagic OS only allows several frequencies which I spaced out as well as possible at 305mhz, 400mhz, 525mhz, 670mhz, 800mhz, and either 900 or 940mhz depending on the version you installed.
Overall I'm very satisfied with this kernel build and don't plan on adding or subtracting anything from it for the time being. It does what it should do, gives solid performance, and good battery life. My last score on AnTuTu setup with defaults 12GB/256GB was 682K which currently is still the top performing phone out there - running at 940mhz GPU. Not all phones can handle 940mhz so use 900mhz if yours cannot. If there are enough requests for an intermediate build (say 925mhz) I can add one later off the same code base. Also note in releases there are "gaming" builds that don't keep track of CPU times at each frequency, which was a request by users to remove any potential lag while gaming. I run the non gaming version, useful if you want to tweak battery usage, but nonetheless, both versions are there for you to use.
I'm on Telegram t.me/NubiaRedMagic5G_Mods as long as I have the phone. Which will be quite a while if Red Magic / Nubia decides to fix N41 5G in the USA.
Also note that all the features of this kernel (besides ones specifically added by me) are the creation of other developers whose contributions are all notated in the kernel source code. Some of the developers that have contributions here or helped me in some fashion: Resurrect88, DD3Boh, PappaSmurf, kdrag0n, Ayrton990, Flar2, Lord Boeffla, plus many more across the globe. Without them, I wouldn't be making any kernels! And I'm sure there are many other devs I've forgotten to mention, I thank all you guys for your help and support.
MOD 1.4 Download Link:
https://github.com/mrslezak/NX659J_Q_kernel/releases/tag/1.4
PRIOR RELEASES BELOW:
8th Release:
MOD KERNEL 1.35-BBRv2 STABLE:
RELEASE NOTES:
This is an intermediate release - I realized that the prior release was draining far more battery than it should, and I found the source was debug related code in BBRv2 from Google. So this is the updated kernel that gives you battery life like before this TCP algorithm was added.
CONFIG_CPU_FREQ_TIMES=y has also been added so you can see in a kernel manager how much time is spent in each mhz block for each set of processors. This can be useful if you set in a kernel manager (like SmartPack) a minimum CPU mhz to see how much time is actually spent at each level.
The code base also has Dynamic Stune Boost, but I haven't had time to optimize it for the device, so it's just on default settings. So there are 2 versions of this 1.35-bbr2 release. At some point it will be enabled as part of a regular release (some 17 commits squashed together into 1, Stune Assist was causing issues so I turned it off). The main idea of that set of code additions is to run the device at lower frequencies, saving battery, while still achieving the same performance level to the user of the phone. If you want to try different options for it in SmartPack or FK Kernel Manager you can.
Downloads:
https://github.com/mrslezak/NX659J_Q_kernel/releases/tag/1.35-bbr2
7th Release:
MOD KERNEL 1.3-BBRv2 STABLE:
RELEASE NOTES:
Added the 31+ commits for BBRv2 from Google. Squashed the commits down to 6 by author from Google (for easy code maintenance). It's said to be the best TCP (internet congestion) algorithm so this sets it by default. You can still select from the others added in 1.3, as mentioned only EX Kernel manager properly shows them. But SmartPack if you choose the one you want under Misc, then click Apply on Boot, it actually will load the TCP algo you selected. It's just a visual defect. I also made a script for SmartPack uploaded to show you the TCP algo that's selected in my repo you can install so you can verify for yourself. Give it 10 seconds (default on boot setting) before you check.
Downloads:
https://github.com/mrslezak/NX659J_Q_kernel/releases/tag/1.3-bbr2
6th Release:
MOD KERNEL 1.3 STABLE
RELEASE NOTES:
All this release adds is TCP congestion algorithms. The only kernel manager which correctly shows the algo set correctly is EX Kernel Manager. Using SmartPack or FK Kernel Manager will tell you that you're always on Reno, when in fact, you aren't. I'm not quite sure if this is bug related to 865 kernels as a fellow dev had the same experience (on an Op8 Pro). Now the default is set to BBR. Why? No reason specifically, although it is one of the better algorithms for internet usage. You can easily change in any kernel manager and set on boot which one you'd like to use (see above RELEASE NOTES if using SmartPack). But this gives you plenty of options:
BBR, BIC, CDG, CUBIC, DCTCP, WESTWOOD, HSTCP, HYBLA, HTCP, VEGAS, RENO, VENO, SCALABLE, LP, YEAH, ILLINOIS
You can Google the benefits of each and pick what you like. Or just leave it alone. The prime idea of MOD kernel is that you don't need to adjust anything it just works optimally without any intervention. Read the release notes for prior features that have been added. There are many just not summarized in a single place at the moment. All the optimization has been done for Red Magic OS.
Downloads:
https://github.com/mrslezak/NX659J_Q_kernel/releases/tag/1.3
5th Release:
MOD KERNEL 1.25BETA
RELEASE NOTES:
This release is mostly about battery savings. I'm averaging around 6.5% active drain on normal tasks with this version (90hz setting), and around 0.5% screen off drain. A big improvement over the stock kernel. So I ended up with about 13 hours SOT + 24 hours screen off on 1 charge! See the picture, I stopped at 11% left. Now I didn't say anything about gaming. If you want to game and have power saving benefits, don't enable any of the built in boosting modes in the game launcher - the Red Magic OS will override everything. Let the kernel do the work for you. And if you're seeing any graphics lag, go into SmartPack kernel manager (free) and go under GPU, Adreno Boost is enabled on low, you can set it to medium or high. That will increase the speed at which the GPU throttles up and down.
1) Switch to the Energy Model for CPUs: Several subsystems (thermal and/or the task scheduler for example) can leverage information about the energy consumed by CPUs to make smarter decisions. This config option enables the framework from which subsystems can access the energy models.
2) Added CPUMASKS for the Little, Big, and Prime cores from Sultan Alsawaf Sultan: SultanXDA, prime added by Danny Lin: kdrag0n.
3) Added kernel control of the minimum frequencies for the little and big clusters by Danny Lin kdrag0n. They are set to run at their minimum running frequencies when idle 691mhz (little) and 710mhz (big) which results in nice power savings when web browsing or just under low load in general. Prime cluster min is not set as it makes the CPU scheduler function poorly.
4) Added AdrenoBoost by Aaron Segaert: Flar2, with all its changes squashed into 1 commit. Defaults to low setting. As mentioned before, you can change in SmartPack, and set on boot if you need a higher value than low: https://github.com/SmartPack/SmartPack-Kernel-Manager/releases
5) Uploaded the various GPU OC files to the repo, It still will just build off the default one, but they are here to be complete. 940mhz version again is posted, Building direct from the repo will give you 900mhz max GPU.
Downloads:
https://github.com/mrslezak/NX659J_Q_kernel/releases/tag/1.25BETA
4th Release:
MOD KERNEL 1.2 BETA
RELEASE NOTES: (Note a 940mhz GPU clock edition is available, if you want to try it, a few of us have had good results on it. Likely the max an 865 GPU can run. You'll sacrifice the power savings, however):
1) Enable Power-efficient workqueues by default, add a toggle that can turn this off via a kernel manager (under CPU in SmartPack). Enabling this makes the per-cpu workqueues which were observed to contribute significantly to power consumption unbound, leading to measurably lower power usage at the cost of small performance overhead. Have also added many other power saving features to the defconfig. The phone is a beast, power savings is a good thing to implement.
2) Update the LZ4 decompressor algorithm with a much faster variant for the ZRAM swap, now version 1.8.3-9 credits Gao Xiang [email protected] and many others (check commits). Speed improvement below (should help on 8GB devices):
Compressor name Compress. Decompress. Compr. size Ratio Filename
lz4hc 1.7.3 -9 12 MB/s 653 MB/s 42203253 42.20 enwik8
lz4hc 1.8.3 -9 11 MB/s 965 MB/s 42203094 42.20 enwik8
3) Default scheduler is set to SQ deadline. Should see minimal improvements in speed until I get a MQ variant working. On the task list ahead.
Download Link:
1.2BETA: https://github.com/mrslezak/NX659J_Q_kernel/releases/download/1.2BETA/MOD-RM5G-GPUOC-Beta1.2.zip
940mhz GPU release here, it's still 1.2BETA, just with the max clock a few of us have been able to use. That doesn't mean your device can for sure handle it, but give it a try if you'd like! Note the power savings will likely not be there vs the other release at 900mhz:
https://github.com/mrslezak/NX659J_...oad/1.2BETA/MOD-RM5G-GPUOC-940mhz-Beta1.2.zip
3rd Release:
1.15BETA: https://github.com/mrslezak/NX659J_Q_kernel/releases/tag/1.15BETA
This is a HEAVILY updated release of the MOD kernel 1.10BETA - I realized the phone's software will allow 6 frequency clocks, although 1 did not have a regulator defined (now patched). NOW I VERY HIGHLY suggest installing SmartPack Kernel manager. It will give you insights into the kernel and how it's performing and it's free. It also will let you adjust added options now in the kernel. Just root your phone and flash from TWRP. If you haven't already installed Magisk, then install that too. There's a guide I posted on XDA about that. Use the experimental method there is no reason to unlock your bootloader. https://forum.xda-developers.com/nu...how-to-unlock-bootloader-redmagic-5g-t4081743
RELEASE NOTES:
1) Bugfix: there was 1 missing 800mhz GPU frequency regulator clock on the prior version. This has been set to TURBO, 1 level under the 900mhz regulator of TURBO_L1.
2) Boeffla WakeLock blocker (v1.10 + tweaks) has been added to reduce battery drain when the phone is not being used, using the latest version and all patches. A default block list is included. You can access in SmartPack Kernel Manager under the new menu that will appear "Wakelocks" - especially investigate if your phone has high idle drain, you can experiment with blocking other wakelocks (which don't allow your phone to sleep). Or you can leave as is. I get just under 1% drain (screen off) and the phone sleeps quite often with this version. Take a look at the screen shot! That's just normal phone usage, not gaming.
3) All debug entries (except those required) have been stripped completely out of the kernel. This results in less wasteful debug information being generated.
4) The default algorithm for ZRAM has been changed from LZO (high compression, but slow) to LZ4 (slightly less compression, but fast). LZ4 algo was added. It still defaults to 4GB.
5) Dynamic Fsync has been added to the kernel as well. This patch allows journal entries to be written only when the screen is off. I.e. they are cached and written afterwards. This increases database performance. It is disabled by default so in SmartPack Kernel manager, if you'd like to turn it on, go under Misc, select Dynamic Fysnc, and select apply on boot. There is always a risk of data loss when delaying writes, although I've personally never have had issues - it only happens if the phone crashes, and mine has never crashed on this kernel. This won't normally increase your benchmark scores (except AndroBench), it increases SQLite database access speed. Up to you to use or not, works fine on my device.
6) Here are the updated frequencies (note there is 1 more). Will have to wait for AOSP before I can add back more. Note the 670MHz is likely the 865+ max frequency per the release notes today on the device (which I assumed by the source code anyhow pre-announcement): 900MHz / 800MHz / 670MHz / 525MHz / 400MHz / 305MHz
AS ALWAYS, USE AT YOUR OWN RISK!!!
Github Source:
https://github.com/mrslezak/NX659J_Q_kernel
Initial Release:
https://github.com/mrslezak/NX659J_Q_kernel/releases/tag/1.0.BETA
Second release - gets over the "reset to 490mhz" bug caused by the system software, at the expense of reducing frequencies to 6 total:
https://github.com/mrslezak/NX659J_Q_kernel/releases/tag/1.10BETA
Newest release -> will be posted on the top from now on.
Telegram:
https://t.me/NubiaRedMagic5G_Mods
And note the AnTuTu benchmark is just a first run after installing. 670K is likely a record on any 865 phone. The last bench turning off 4GB ZRAM (12gb/256gb device) I got 673K. AnTuTu doesn't equal performance, but if you've benched you'll see this is an insane improvement over the stock kernel. Only when the demand is there will it scale up to 900mhz. I've been using for a while now and notice no difference in battery life. The Adreno driver is very good at handling extra clock frequencies efficiently without modification (despite an "Adreno Boost" that is often added to kernels). The gamers using the kernel are making statements that they couldn't imagine the game play any better than it already was, but now it's even smoother.
Unfortunately the way the Nubia software behaves, it auto-resets to power level 5 (which was 490mhz) on the 1.0BETA on boot and also after boosting the frequencies up. I tried every possible way to bypass this but eventually just gave in and removed frequencies. So the BETA1.10 and above have less frequencies but will always revert to 305mhz, the base minimum frequency of the device. Hopefully once we have AOSP ready I can add more.
MattoftheDead
I.e. M.O.D. Kernel Developer
The first Red Magic 5G OC kernel.
Xiaomi Mi9 / Mi9T Pro Pie V2 and Q V1.5 Kernel Dev
Nice work. Do you notice any benefits to OCing the GPU like that? I don't think there are many games that would benefit atm.
This is amazing !!! :laugh:
Is this going to work on all roms like CN, NA or EU Roms? Im currently running NA 3.11 flash from CN rom with root and twrp
We have people using it on CN Global and NA versions no problem at all. Works fine on every model.
Kernel is fully functional no issues at all.
CN Rom to NA Rom v3.11
305mhz min to 900mhz max confirmed and using smart pack to control the frequency
Thank you for this hopefully there is more development i really appreciate ur effort
Kernel building is just a hobby of mine, I was posting a minimal kernel to get some more kernel developers on board to hopefully add more features. I usually add Boeffla Wakelock Blocker and Dynamic Fsync and call it a basic kernel. The last super kernel I made took way too long, and I don't have that kind of time anymore - boost functions and underclocking to balance out the battery life and such. Development work doesn't pay anything, I didn't get the phone free, all my donations go to other developers. And I have a full time job and family. But if anyone wants to port over my MOD Kernel Q 1.5 Mi9 features, well that would be a super kernel. It's just really, really time consuming, time I don't have at the moment. And the merging of source has to be EXACT or you end up with a really slow phone rather one that balances underclocking, boost, and overclocking.
MishaalRahman said:
Nice work. Do you notice any benefits to OCing the GPU like that? I don't think there are many games that would benefit atm.
Click to expand...
Click to collapse
All the gamers using the kernel are reporting that the games run smoother than before, which no one thought was possible. It is already a flagship device. But the GPU OC with the Adreno driver scales when needed up to the frequencies that it has in the table and has no issue on 670, 800, and 900mhz reported so far. There are gamers on NA, Global, and CN ROMs, with no bugs reported. No issues and everything works properly. I have tested myself and although I'm not a gamer, all the functions work as they should. It still connects via Bluetooth, it still takes photos and videos, etc. There is no lag whatsoever. Overall I think the frequencies are ideal for this device with it's advanced active cooling system. Other devices however, with passive cooling, are unlikely to handle the increased GPU clocks.
I found an unusual bug where the GPU Minimum Frequency will reset on its own to 490mhz even if i set the minimum frequency to 305mhz im using smart pack kernel manager that you provided and cool tool btw to monitor the gpu frequency.
I also set the battery optimization to off on smart pack so it wont turn off itself.
This also happens when i played games that actually boost to 800 to 900mhz then after i close the game it sets back the minimum frequency to 490mhz so i have to set it again to 305mhz on the kernel manager to save more battery and lower the temps.
I also notice it sets back to 490mhz minimum frequency by just watching youtube videos so i have to set it back to 305mhz again. I tried different kernel manager too like Franco Kernel Manager and Kernel Audiator and still doesnt fix the issue
I think this was a minor bug for sure
I never touch the GPU governor btw
Performance was super nice thou i scored 645k on antutu on my first run but for now im going back to stock and gonna wait for your next update
What to do to root the phone without breaking the fingerprint please. I read the article publish nothing understood someone can explain to me step by step. I am an amateur I never root a phone. I have cn 2.55 16gb.
I don't have the same issue - I just tried to recreate it by watching a YouTube video and I went back to SmartPack and it still shows 305MHz GPU frequency. Although I'm using the debloated / optimized ROM I created Black Magic 5G which has everything setup properly, Nubia apps frozen, everything moved to 3rd party apps. NETFLIX patched to 4K HDR10, YouTube Vanced, a ton of root utilities, AdAway ad blocker, etc. You can find it on the Telegram channel (I'm using the NA/Global version of Black Magic 5G). Then I watched Netflix, still at 305mhz. As I have no idea how you've setup your phone, I just can't recreate it.
shaifabra5 said:
I found an unusual bug where the GPU Minimum Frequency will reset on its own to 490mhz even if i set the minimum frequency to 305mhz im using smart pack kernel manager that you provided and cool tool btw to monitor the gpu frequency.
I also set the battery optimization to off on smart pack so it wont turn off itself.
This also happens when i played games that actually boost to 800 to 900mhz then after i close the game it sets back the minimum frequency to 490mhz so i have to set it again to 305mhz on the kernel manager to save more battery and lower the temps.
I also notice it sets back to 490mhz minimum frequency by just watching youtube videos so i have to set it back to 305mhz again. I tried different kernel manager too like Franco Kernel Manager and Kernel Audiator and still doesnt fix the issue
I think this was a minor bug for sure
I never touch the GPU governor btw
Performance was super nice thou i scored 645k on antutu on my first run but for now im going back to stock and gonna wait for your next update
Click to expand...
Click to collapse
Yeah maybe because you modified the rom.
Im currently running Flash Global V3.11 when i tested your kernel no modification made im just rooted with TWRP Installed and i posted this kernel on red magic 5g group on facebook and 3 of us having the same issues as well.
Im gonna try it again on V3.13
UPDATE:
still returning to 490mhz as minimum frequency after gaming and after watching one youtube clip
kinda sad hopefully you can fix this bug on the global rom that nubia provided if you have the time, great kernel for gaming because of the 900mhz boost and the phone can sustain this boost because of the active fan
Why don't I have a roughly similar score?
Is it possible to overclock the CPU as well? They officially release the specs sheet of ROG Phone 3 it has overclocked CPU (3.091ghz) and an overclocked GPU. I know this phone can keep up with those clocks because of the cooling system but the problem is the battery life. But still, its worth it.
Blink003 said:
Is it possible to overclock the CPU as well? They officially release the specs sheet of ROG Phone 3 it has overclocked CPU (3.091ghz) and an overclocked GPU. I know this phone can keep up with those clocks because of the cooling system but the problem is the battery life. But still, its worth it.
Click to expand...
Click to collapse
I believe Qualcomm blocked overclocking of CPUs quite a while ago from SD845. Only GPUs can be overclocked.
Though I don't know if devs have gotten tools to get around it.
The 490 bug looks like it's related to the gaming mode APK resetting the min frequency. I can't decompile or recompile APKs so I don't have a way to get around the system reverting to 490 without removing 3 other frequencies. It seems hard-coded in the app that it only expects to see 5 frequencies so to have all working properly, 3 need to be removed. This is in contrast to what my buddy dev on the Op8 Pro can do, but this device is designed differently in how it boots and custom apps that increase frequency clocks. If any devs are good with APKs it's a very simple function call that sets the minimum GPU frequency. The only odd thing I see is that the minimum power level stays at 8 (minimum) which corresponds to the lowest clock speed. That number doesn't change in a kernel manager when the min GPU clock reverts to 490.
I'm off on vacation not near a PC but will try to come up with a stock # of clock frequencies that still scrolls smoothly between them and the Adreno GPU driver. May take a few tries but it's quite easy to modify. I already think 180mhz is too low from using it, it's more of a sleep frequency some suggested going this low but I think the phone design is for 300+. I prefer to use more clocks for better throttling but have to work with what we are given and do the best inside those boundaries.
No you can't raise CPU clocks on 865 devices that ROG device is supposedly using the 865+ or whatever the mid device is named between the 865 and 875. They have blocked CPU OC hardware wise for some time now.
mslezak said:
No you can't raise CPU clocks on 865 devices that ROG device is supposedly using the 865+ or whatever the mid device is named between the 865 and 875. They have blocked CPU OC hardware wise for some time now.
Click to expand...
Click to collapse
Qualcomm's Meizu’s CMO Wan Zhiqiang recently commented on Weibo saying that there won’t be a Snapdragon 865 Plus this year.
We will see!
No 865+ this year..
Trust me whatever they call it it's already defined in the source code as a second GPU bin clock for another device ID. So maybe it won't be called an 865+ but there is some device between the 865 and 875 coming out. I have OEM confirmation as well this device exists the name isn't important. I can tell you the top GPU frequency is 670mhz that's it, vs. the 587mhz default on the 865. Still the 865 handles 900mhz GPU no problem the only benefit would be higher CPU clocks. And an extra GPU clock. Which I'll attempt to spoof next time I get near a PC.
mslezak said:
Trust me whatever they call it it's already defined in the source code as a second GPU bin clock for another device ID. So maybe it won't be called an 865+ but there is some device between the 865 and 875 coming out. I have OEM confirmation as well this device exists the name isn't important. I can tell you the top GPU frequency is 670mhz that's it, vs. the 587mhz default on the 865. Still the 865 handles 900mhz GPU no problem the only benefit would be higher CPU clocks. And an extra GPU clock. Which I'll attempt to spoof next time I get near a PC.
Click to expand...
Click to collapse
Is it possible to overclock the memory clock too? I assumed that 900mhz is the core clock.
mslezak said:
Trust me whatever they call it it's already defined in the source code as a second GPU bin clock for another device ID. So maybe it won't be called an 865+ but there is some device between the 865 and 875 coming out. I have OEM confirmation as well this device exists the name isn't important. I can tell you the top GPU frequency is 670mhz that's it, vs. the 587mhz default on the 865. Still the 865 handles 900mhz GPU no problem the only benefit would be higher CPU clocks. And an extra GPU clock. Which I'll attempt to spoof next time I get near a PC.
Click to expand...
Click to collapse
You're right, that makes sense.
I'm glad they are making a refreshed chip.
On another note, do you think we will see an overclocking tool in the future?
Possibly with a custom ROM?

Categories

Resources