Related
Hi Folks,
For those who are interested, I have modified the 90screenstate_scaling script used in Zach's (and now Glitch's) kernel for use with other CM7 compatible kernels. The aim is to create a very simple script that can easily be read, modified and improved upon by non-coders, such as myself.
I have retained only the code that will read the screen state, set the governor appropriately and set the scaling threshold, giving users complete control over the scheduling behavior of their CM compatible kernel.
I am not a coder and all credit goes to FloHimself and zacharius.maladroit for the original content. all I have done is (hopefully) simplify the script and make it easy for non-specialists to read.
If you would like to try it out, copy the script in to /system/etc/init.d and modify the values to your liking. If you are already on Zach's kernel there is nothing new here, as you already have this script.
The script currently includes kernel defaults from Glitch for the smartass governor, from Zach for the conservative and ondemand governors, a few experimental settings, and of course, the ability to modify them yourself.
If you add anything or make any modifications (particularly in relation to your specific usage pattern) you would like to share, please post them and I will update this thread. If you make modifications, comment them appropriately and explain your usage pattern for which the settings work best so that people know if it would work for them.
The experimental conservative settings that I have made (that are currently in use on Glitch kernel) for the screen off state are designed to aggressively keep the frequency very low, almost like a 100mhz frequency cap, while still allowing them to scale up under considerable load. They are (hopefully) ideal for background screen off behaviour such as listening to music, exercise applications or aggressive sync and push/pull email behavior (like in an office).
The experimental smartass settings are designed to test the hypothesis that quick downscaling may cause as many lags as as slow scaling up behavior. The goal is to create a more linearly scaling version of smartass which is slower to upscale or downscale (only a matter of milliseconds difference). These are still under testing.
With one of the main reasons for using smartass as a single governor, the min/max frequencies for the screen on/off state no longer applicable with the governor changing in relation to the screen state, I have moved to ondemand settings, which may have battery implication while the screen is on, but they are VERY smooth.
*subscribes*
we could probably make conservative governor more aggressive
with the settings that laststufo used on his kernel but I'm not sure if it would scaled up fast enough if you used e.g. some DSP settings on sound while the screen is off
worth as shot
if I don't forget it - I'll post the settings later
Subscribes too
I like the idea and the simplicity of this. And with Zach's help, also known as "F*ckin scripts master" (almost a private joke ), it can only be great.
I'm a big fan of simple, though as a user of Arch Linux on the desktop I have no choice (BSD style init scripts a boot - beautiful simplicity)!
It's great you lads are watching this! Hopefully the thread will grow in to something, even if it is just an sandbox for users to experiment with the settings they prefer. If nothing else, hopefully you guys get some useful info!
I just added a bit of an experimental version that moves away from the default smartass values.
I am hypothesizing that the very accasional lags in the smartass governor might be related to the governor scaling down too fast, rather than it not scaling up fast enough.
I changed the default down threshold from 40 to 35 and the default up threshold from 60 to 65. Hopefully this will scale up and down a little more linearly and this will make the GUI even smoother. I am still testing this theory at the moment, but thought I might post it (on the first post) if anyone wanted to have a go.
well.heeled.man,
you need to test your conservative settings while the screen is on
they're way too aggressive (at least the up threshold, down threshold may be ok)
also the freq_step at 10% should be at least at 15%
if we compare it with laststufo's kernel (he almost had 100 MHz steps everywhere: 100, 200, 400, 600, 800, 900, 1000 MHz)
so that needs to be compensated to get smoother & similar behavior
I'll take a look & see how the new smartass settings work out
my new conservative settings are:
echo "76" > /sys/devices/system/cpu/cpufreq/conservative/up_threshold # 50 # 76 # 76
echo "30" > /sys/devices/system/cpu/cpufreq/conservative/down_threshold # 35 # 12 # 30 (higher will lead to noticable lags) # 35
echo "15" > /sys/devices/system/cpu/cpufreq/conservative/freq_step # more aggressive ramping up (50)
this currently keeps the cpu between 100-200 MHz while playing MP3s for me (screen off) - mostly 200 afaik right now
but I'll try your conservative settings, too, when I find time - let's see how they are in terms of "smoothness" (I'm sure they're not too usable with the GUI but could be great for background tasks while the screen is off)
Hi Zach, indeed, I would say that the conservative settings are completely unusable with the screen on. I would not recommend these with the screen on.
However, with music (DSP manager too) GPS and Cardio Trainer all running (my cycle home), it seems to work fine (screen off). Every km, Cardio trainer speaks the time taken over the music (two audio streams). With many kernels this becomes slow, or slurred, but sounds perfect with these settings.
well.heeled.man said:
Hi Zach, indeed, I would say that the conservative settings are completely unusable with the screen on. I would not recommend these with the screen on.
However, with music (DSP manager too) GPS and Cardio Trainer all running (my cycle home), it seems to work fine (screen off). Every km, Cardio trainer speaks the time taken over the music (two audio streams). With many kernels this becomes slow, or slurred, but sounds perfect with these settings.
Click to expand...
Click to collapse
awesome !
so it still raises the frequency when needed ?
100 -> 200 (or more)
you checked via e.g. CPU Spy ?
thanks !
Yes, it still goes up when needed (confirmed via CPU Spy), but it needs to be really pushed. It seems like good behaviour in the screen off state.
EDIT: something in the region of a 66%/33% 100/200mhz split at these settings.
I am struggling to confirm that my settings are being applied as I would like in the screen off state. I can read off the values in /sys/devices/system/cpu(/cpu0)/cpufreq/conservative if I manually set conservative in Pimp My CPU with the screen on, but the behaviour seems at odds with the values i.e. not as laggy as one would suspect.
As (a variation of) this script are now used in Glitch's too, I have changed the comments to allow people to very easily see which settings are from kernel devs (which should probably be left alone should you wish to return to their defaults) and experimental settings (which I would suggest you change, if you change any). If you want to use parts of it in Zach's, I would suggest cutting and pasting the experimental part into the appropriate part of Zach's script as overwriting any part of it would remove much of his additional functionality.
This is great guys - thanks for this
With one of the main reasons for using smartass as a single governor, the min/max frequencies for the screen on/off state, no longer applicable with the governor changing in relation to the screen state, I have moved to ondemand settings by default. This may have battery implication while the screen is on, but they are VERY smooth.
wrong spot
screenstate_scaling_V49.zip
that's the current version of my screenstate_scaling script that I offer as an option with Neo 17 r7
most of the stuff moved into the S98system_tweak script that now is shipped with the kernel
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. Now that there are a few custom kernels out there for our device, you may want to know about these.
I’d be glad if you could help me complete this guide.
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.
Overview:
Post 1:
A.: What you want to know about the CPU/GPU of your device
B.: Custom Kernel Features
Post 2:
Coming Soon!!!
A: What you may want to know about the CPU/GPU of your device:
Galaxy Note 10.1 features a 1.4GHz Quad Core CPU (Exynos 4412) and a 400MHz GPU (Mali-400).
More Data will be added soon.
B.1: CPU/GPU/IO Features which comes with Custom Kernels:
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 gameplay 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 NOT available in the current custom kernels of Note 10.1.
•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: UV improves battery life by using less power. See this.
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 Droidphile’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 Droidphile’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.
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!!!):
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.
CIFS:
In order to manage your cifs/nfs network shares on your Android device you need the proper and working modules. And so you can mount/unmount your network accessible file resources and access your data.
B.3 Other Features:
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.
Eco Mode - NEW:
Eco Mode is an optimized dual core solution for quad-core SOC (System on Chip) like the Qualcomm S4-pro. This should allow for Maximum battery life without sacrificing performance. - Paul Reioux
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 or Westwood as the default of your kernel.
Dynamic FSync - NEW:
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).
zRAM:
In order to explain zRAM more precisely first we need other terms defined clearly:
Swap can be compared with the swap file on Windows. If the memory (RAM) is almost complete, the data which is not used actively (ex. background applications) will be stored on hard drive so as to re-evacuate RAM free. If required, this data is then read back from there easily. This will preserve performance with no lose at multitasking (the main reason we use swap).
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. 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.
Note: Also there are methods to use a part of internal memory as Swap space. This is not as fast as zRAM. But no RAM will be used at all and CPU load is less. Though I am not sure that this has been brought to our device yet. Will add more data soon on this part.
Work in progress, will add more info soon.
Reserved for OP
csec said:
•Note2: UV does not impact battery life (or it is not noticeable).
Click to expand...
Click to collapse
First of all, I would like to praise this guide for its information and depth, secondly I would like to help improve it;
emprize said:
the only different for me is temperature, for battery saving, always not noticeable for me, placebo effect most likely
Click to expand...
Click to collapse
AndreiLux said:
This is a nonsensical argument, temperature aka heat, is power. If you are getting a less heated phone, then your battery life is improving. If this wouldn't be the case then you are holding the solution to the world's energy problems in your hands.
Click to expand...
Click to collapse
just thought i would share some thoughts of a well respected and knowledgeable developer.
http://forum.xda-developers.com/showthread.php?p=36723175#post36723175
Regards
Jack
JSale said:
First of all, I would like to praise this guide for its information and depth, secondly I would like to help improve it;
just thought i would share some thoughts of a well respected and knowledgeable developer.
http://forum.xda-developers.com/showthread.php?p=36723175#post36723175
Regards
Jack
Click to expand...
Click to collapse
Wow, that was hell of an argument. Seems to be theoretically true. What I referred to in above is real life experience with my phone and according to kernel guys down at HOX forums.
However the information was really interesting. I will add it to the OP.
Thanks.
Sent from my GT-N8000 using Tapatalk HD
Recently Added to the OP:
- Eco Mode
- Dynamic FSync
zRAM added to the guide.
These tips are based in my study and experience of using different programs and techniques to get solid and stable performance from custom kernels. It's a long read, but a good read if you really want to minimize heat and maximize performance. This information works on any custom kernel that can be used with Synapse. This guide is aimed at beginner and intermediate users who are interested in custom kernel settings but don't know where to start. These are the most commonly optimized settings on Android.
***DVFS Rule #2 is exclusive to Samsung devices (so if you don't have a Samsung device don't use it!)***
Rule 1: What works for some won't work for others - This has always been the most important rule of custom kernels. One person using Barry Allen governor, overclocked to 3.07 GHz, and not using intelliplug will never hit 70C while your phone using those same settings might immediately cause the phone to reboot. All synapse changes made to a device must be tested by you to ensure compatibility for your hardware. Some of you may be curious, if this is the case, why Google would have everyone use the interactive governor by default? I would respond to you that they originally assigned everyone to OnDemand while they worked to make a better and more compatible Interactive governor. But as you know there are a LOT of governors out there and knowing what is best for your device is to read and to test it. The good news is that once you find something that works well you can stick with it as long as you own the device.
Rule 2: DVFS (Dynamic Voltage and Frequency Scaling) Disabler - This is mentioned in a few threads, but requires a repeat. Samsung uses DVFS to contol your CPU frequencies and voltage levels. This isn't an issue when you're running a stock kernel because it works in conjunction with MP-Decision to decide on the proper frequency level. When you're running emotion kernel you don't want DVFS to control anything. You want it to let Faux's Intellithermal work together with the kernel routines to shut down cores it doesn't need.
R2 Part 1: If your phone is running hot: Install Xposed, download Wanam Xposed (enable the module), Open Wanam, click "Advanced" menu, Uncheck "Enable TouchWiz DVFS" and reboot.
R2 Part 2: Following the reboot open Synapse, scroll over to CPU Drivers scroll down and put a checkbox in "Enable Intelli-hotplug", leave the rest alone, and click the check mark at the top of the screen to save changes. Scroll over one more screen to "Thermal" and put a check in the box, "Enable or Disable Intelli Thermal Control" and leave the settings below as they are unless you know what you are doing.
Note: The phone will be still be warm for awhile, but if you give the phone a break and allow the heat to dissipate it should run cooler and more consistently with the added bonus of shutting down 3 out of the 4 cores unlike MP-Decision which always leaves 2 cores live. After doing this if you are noticing performance loss or stuttering it's time to find a new governor that makes the most of these settings. Which leads me to Rule 3....
Rule 3: Choosing a new governor - This part is going to require some reading on your part, but I can assure you that it is worth your time. This guide http://forum.xda-developers.com/general/general/ref-to-date-guide-cpu-governors-o-t3048957 by @gsstudios is OUTSTANDING (please thank him while you are there) and carries a LOT of information about the governors and other performance informations. So find something you like from the guide descriptions to try out and leave it in place for 24 hours or more as long as you aren't experiencing excessive lag or reboots. If it performs well under normal usage the next step is to watch battery life. There won't be a single governor that does everything perfectly, but finding something that fits your needs is key. And it's OKAY if you decide to stick with Interactive, it is a very well made governor and many are based off of that design, but I equate it to finding a good pair of shoes. Lots of things will protect your feet from the ground, but shoes that you enjoy and work well make all the difference in the world.
NOTE: You can use Antutu for stability testing but do not pick a new governor and then run benchmarks and expect top score unless you chose the performance governor. Antutu specifically maxes out your device voltage and frequency to see what the device can handle which is not what intelliplug is for. If you are following this guide benchmarks are the least of your concerns.
Rule 4: Don't forget your Scheduler - Believe it or not, everything runs off of your phone storage. So using an optimized scheduler for you device could make great strides in battery and performance improvements. Unlike choosing a governor, you can absolutely benchmark your flash memory to find out which scheduler works best for you. I only use one and I am going to shamelessly plug it here: I use Android Tuner to benchmark my flash speed with different schedulers and it works great for me. How it works:
Note:To help with choosing where to start with schedulers you can use the guide I linked to above which will give you an idea of what to use. That guide has an exceptional amount of information about how these types of schedulers work and what you should use for getting what you want from your phone. What follows is my advice for testing benchmark write performance and those steps are completely optional, but it never hurts to see how your device does with your chosen scheduler.
R4 Part 1: Launch Android Tuner, from the main menu accept root, acknowledge that root is powerful, scroll all the way to the far left screen, choose "SD Card Read Speed", click "Benchmark in the center, and then notice at the top you have /storage/emulated/0 which is your faster internal memory (which you should optimize first) and then /storage/ExtSdCard which you can benchmark second.
R4 Part 2: When you are ready to benchmark choose your "I/O Scheduler" from the drop down menu and click "Run". Your results will be listed with the fastest read-ahead size on the left and the speed at which it read on the right. Higher = Better -- Then you would choose the other test size (10MB in my case) and you see which readahead value is the fastest for those files. If you manage to get a readahead that the 100MB and 10MB test highest values are the same, then you've won the lottery. Since that is almost impossible try to remember what your top 5 fastest are and choose the one that performs well in both tests. If you want to keep testing and check other schedulers for raw read speed just switch them at the top and re-run both tests.
After you've found which scheduler gives you the performance you want, go back to Synapse, scroll to "I/O" tab, and adjust pick your scheduler and readahead value, and finally click the check mark to apply it.
Rule 5: Undervolting (IMO) does more harm than good - I'll let you Google it but it follows the rule of diminishing returns. You might be running Synapse and are able to undervolt 75mV and still cruise through menus and apps like it's no problem. But I promise you at some point the CPU is going to call for that voltage you starved it of and it will reboot. It's not a matter of if it will happen, but when it will happen. This comes down to your personal silicon and I do not recommend undervolting at all. Other more advanced users may disagree with me, but for the average user there are better ways to save battery and negate heat than starving your CPU and GPU at a kernel level. Especially with DVFS disabled.
And that's all I have for you. These tips work for any custom kernel that uses Synapse to manage their settings. I've personally test my setup with Emotion and the kernel we are not to speak of on XDA. If you like the idea of getting the most out of your device then a custom kernel might be for you, but it requires a lot of patience. If you just need something that works I definitely recommend the stock kernel because they really did a good job with the Lollipop release of our kernel.
I hope this helps some of you and I hope that everyone can take something away from this guide. Feel free to let me know if this helped you in some way or if you need some guidance on the topic. I'll do my best to backup my claims with proper research and documentation.
Thanks
Google - For research help and a great phone OS
Linux - The foundation of this OS
gsstudios - For his outstanding guide and work on researching this information (Definitely hit 'Thanks' on his post)
Note 4 ROM and Kernel Devs - we are very lucky to have a lot of great devs for our device; their work is appreciated and gives me something to write about
XDA and their members - where I've learned most everything about one of my favorite operating systems
Kernel Tweaks Intended for balanced performance/battery life on actual usage.
Please provide feedback.
Changelog/FAQs
Attention! It assumes that you've already optimized your phone (background apps, idle drain, wakelocks...), which is up to you, and NOT covered on this post.
All sources and credits at the end.
Great thanks to @Dreamstar for the awesome Vegito Kernel!
NOT recommended for gaming, image processing or heavy loads.
Tweaks:
CPU
I/O scheduler
GPU
HMP scheduler (big.Little related)
Virtual Memory
perfd, sched_boost and sched_load disabled to use LITTLE as the main cluster in order to save power
Minimal overheat
Any ROM/Kernel:
http://www6.zippyshare.com/v/PGToHEyx/file.html
does NOT affect hotplug at all, may seem sluggish with incorrect profiles (due to lack of optimization)
does not apply Input Boost
disables Touch Boost (if present)
Kernels with Core Control (core_ctl) hotplug enabled (Lineage OS, AOKP, RR):
Option 1:
http://www103.zippyshare.com/v/WQlpK3en/file.html
Great SoT/Battery Life
May feel sluggish
May contain micro lag/stuttering
2 Little cores always online
big cluster offline most of the time
may have problems with audio crackling during music playback
Option 2:
http://www103.zippyshare.com/v/tz4IiM4n/file.html
Biased towards performance (in case the previous one was behaving bad)
Slightly less battery life
Smooth enough
Little cluster always online
big cluster offline most of the time
Vegito Kernel (RECOMMENDED):
http://www76.zippyshare.com/v/lSXeYI9b/file.html
New*: http://www19.zippyshare.com/v/n9CsRYYk/file.html
*if unstable (e.g. force close), set swappiness to a value between 10~60
Best balance between performance/battery
Snappy
Smooth
Above-average SoT
Thunderplug support
big.LITTLE always online (lower latency and no waste of CPU cycles)
Input boost set at 998Mhz on Little cluster, with duration of 1980ms. (not very battery friendly, try lower values)
Useful links:
The truth about kernels and battery life
Your battery gauge is lying to you (and it's not such a bad thing)
Diving into Doze Mode
Battery Calibration (myth)
Battery Drain Benchmarks
Sources/Credits:
Original GlassFish settings for interactive by @soniCron
Interactive governor battery save scripts by @Sickaxis79
Xiaomi Mi Max Kernel Guide by white778899
LSpeed by @Paget96
[AKT] Advanced Kernel Tweaks by @Asiier, @patalao, @Mostafa Wael and @Senthil360
Changelog 03/31:
Code:
Cleanup:
- Fixed useless loops and condition checks
- Added credits (developers of Project Zhana/Advanced Kernel Tweaks)
- Typos
Vegito only (unstable):
CPU:
- Timer slack cut in half (from 480000) on big Cluster
- Increased 'go_hispeed_load' (91 -> 400 on big, 91 -> 155 on LITTLE)
- Input Boost duration reduced to 120ms (from 1920ms); (drastically improves battery)
- Input Boost frequency increased to 1113MHz (from 998MHz); should not affect battery much, since it stays on the same voltage
GPU
- Revert 'underclock' (465MHz -> 550MHz) to minimize UI lags, trust Adreno Idler to reduce power consumption.
HMP Scheduler:
- Lower 'sched_upmigrate' (90 -> 85)
- 'sched_freq_dec_notify' decreased (410000 -> 400000)
Virtual Memory:
- Increased ZRam to 256MB (from 128MB)
Changelog 03/30:
Code:
HMP Scheduler:
- don't schedule background tasks on big cluster
Virtual Memory - reduce usage of CPU cycles:
- new values from Project X.A.N.A (high dirty_ratio and dirty_background_ratio, min_free at 4M and default vfs_cache_pressure)
IO Scheduler:
- New logic to apply I/O scheduler (from Project X.A.N.A)
- Try ZEN
- if zen is not available use noop (on Lineage OS), otherwise use BFQ.
- increased read-ahead to 512Kb (core_ctl scripts still use 128Kb)
- apply to internal and external memory (SDCard) if present
- changed zen tunables (thanks to [URL=https://forum.xda-developers.com/oneplus-3/how-to/advanced-interactive-governor-tweaks-t3476589][AKT] Advanced Kernel Tweaks[/URL] by [user=6187429]@Asiier[/user] - Project X.A.N.A
Cleanup:
- moved verbose descriptions (now at the end of this post)
- Mhz -> MHz
core_ctl only:
CPU:
- target load set to 499Mhz until 75% (from 70%)
Virtual Memory:
- 20 swappiness and 70 vfs_cache_pressure
- page-cluster set to 0 (read only 1 page from swap each attempt)
- Laptop Mode set to 1
Vegito only (unstable):
HMP Scheduler:
- try to use big cluster more, easing the load of the the LITTLE cluster (from [URL=https://forum.xda-developers.com/showpost.php?p=69417941&postcount=724]Project X.A.N.A[/URL]) (*trying different freq_notify values atm)
- big.LITTLE should not overload a single core or cluster.
CPU:
- align_windows set to 0 (both clusters)
- increased min_sample_time (from 0)
- revert 'fix erratic jump to 998Mhz while idle'
Virtual Memory:
- swap only to avoid out of memory conditions ( vm.swappiness = 0 ) # if unstable (e.g. force close), set to a value between 10~60
- lower ZRam (200MB -> 128MB)
- Laptop Mode disabled
Changelog 03/29:
Code:
Cleanup:
- add simple function to change permissions and apply settings
- typos
Vegito only:
CPU
- fix erratic jump to 998Mhz while idle
--------------------------
FAQs
How to apply (need root):
Apply every boot.
Using Terminal (RECOMMENDED):
Code:
su -c 'sh /script directory/script.sh'
or
su
cd 'script directory/'
sh script.sh
Can be found at Developer Options or you can download one from the Play Store: https://play.google.com/store/apps/details?id=com.termux
Using Kernel Adiutor:
Copy file to /etc/init.d/
Give permissions rwxr-xr-x (0755)
Go to init.d tab on Kernel Adiutor
Execute script.sh
Why do you leave all cores online??11 (vegito)
CertifiedBlyndGuy said:
Thought I would add more to this and make it useful for a few users.
The reason behind why Mpdecision is disabled by default is due to the fact that it is highly inefficient in the sense that hotplugging on Linux, put simply, sucks. Why? The hotplug acts as a front-end to the scheduler to provide a means of plugging and unplugging cores in exchange for a high amount of latency. This means that even though a core may be plugged, there is a delay of several milliseconds before this is actually processed causing microstutters that are hard to notice, but do disrupt performance. The same can be said for the thermal driver and how it Aries frequencies.
Click to expand...
Click to collapse
franciscofranco said:
Leaving all cores online is fine, they'll hit retention and power collapse pretty quickly if nothing is running on them. There's a lot of work when offlining and onlining cores.
Click to expand...
Click to collapse
franciscofranco said:
Hotplug is the action of onlining a core (after it has been unplugged) in a live system, which is present in any Kernel of any device with more than 1 core. You can offline it through sysfs. What you are asking is: if there's any automatic mechanism that onlines & offlines cpu cores based on some special heuristic. The answer is no.
They are online at all times unless there's the need for some thermal throttle. They'll follow the standard Linux resume->suspend mechanism just like any other "normal" phone when the OEM doesn't **** with the natural cycle. This is exactly how the Nexus 6P (same chip) works. I explain it in the changelog & in the feature list. Cores will go to idle in a "jiffy" if they don't have any runnable threads running.
Click to expand...
Click to collapse
From: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.den0024a/index.html
Code:
15.1.3. Retention
The core state, including the debug settings, is preserved in low-power structures,
enabling the core to be at least partially turned off. Changing from low-power
retention to running operation does not require a reset of the core. The saved
core state is restored on changing from low-power retention state to running
operation. From an operating system point of view, there is no difference between
a retention state and standby state, other than method of entry, latency and use-related constraints.
Check if you Kernel supports the Core Control (core_ctl) hotplug driver:
These folders must be present:
Code:
/sys/devices/system/cpu/cpu0/core_ctl/
/sys/devices/system/cpu/cpu4/core_ctl/
Extreme Kernel (cluster-plug based -> version 12/30 and above)
Try GlassFishCP or FairyTale from https://forum.xda-developers.com/moto-x-play/general/interactive-governor-battery-save-t3443201
Disable Alucard hotplug (to prevent conflicts with cluster-plug)
Disable Simple GPU Algorithm and enable Adreno Idler (Why)
My battery's still crap:
Check if settings were applied correctly.
Try lower input_boost_ms value (at cost of snappiness, can introduce stutter while scrolling)
Check for wakelocks using BetterBatteryStats
Disable Keep Awake/Wi-Fi scan for Google Play Services (unknown side effects):
Settings -> Privacy -> Privacy Guard -> Advanced (dropdown) -> Google Play Services -> Keep Awake/Wi-Fi-Scan
Disable Keep Awake for apps that refuse to sleep, like Facebook and other battery hoggers.
Greenify
General Battery Tips
Disable location when not using
Remove extra widgets from the desktop
Disable live wallpapers
Settings -> Wi-Fi -> Configure -> Keep Wi-Fi on during sleep - Only when plugged in
Settings -> Wi-Fi -> Configure -> uncheck - "Network notification"
Disable unnecessary sync
Disable automatic updates and notifications for updates on Google Play.
Disable push and notification of social networks.
Do not use Task-killers
Do not use programs and widgets to monitor daily usage of the smartphone.
If the quality of the LTE network connection is poor, switch the "Network Type" to 3G or 2G
Source: https://4pda.ru/forum/index.php?showtopic=707426
Obvious:
Use lower brightness (try to keep it below 30%)
Prefer Wi-Fi networks and disable data connections when not using.
Settings explained:
Code:
Android Documentation
https://android.googlesource.com/kernel/common/+/android-4.4-n-release/Documentation/
Kernel - Virtual Memory
https://www.kernel.org/doc/Documentation/sysctl/vm.txt
Performance Testing with SSDs Pt. 2 by Toby Chappell Systems
https://devs.mailchimp.com/blog/performance-testing-with-ssds-pt-2/
How is Heterogeneous Multi-Processing (HMP) scheduling implemented in Linux Kernel (Samsung Exynos5422)?
http://stackoverflow.com/questions/25498215/how-is-heterogeneous-multi-processing-hmp-scheduling-implemented-in-linux-kern
Scheduler Documentation (from DTS Eagle Integration into [Code Aurora Forum] Android (kernel))
https://github.com/dtsinc/DTS-Eagle-Integration_CAF-Android-kernel/blob/master/Documentation/scheduler/sched-hmp.txt
# Read-ahead cache
# Typically, larger values increase sequential read speed and slightly reduce the random read speed. The larger the cache, the less growth
and the more compromises.
# Setting rq_affinity to 2 tells the kernel that the specific CPU core that requested the I/O must be the one that completes it.
# add_random with a setting of 0 avoids the overheard of I/O events contributing to the entropy pool in /dev/random.
# Standard I/O elevator operations include attempts to merge contiguous I/Os. For known random I/O loads these attempts will always fail
and result in extra cycles being spent in the kernel. This allows one to turn off this behavior on one of two ways: When set to 1,
complex merge checks are disabled, but the simple one-shot merges with the previous I/O request are enabled. When set to 2, all merge
tries are disabled. The default value is 0 - which enables all types of merge tries.
# https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-block
# Laptop mode is used to minimize the time that the hard disk needs to be spun up,
# to conserve battery power. It has been reported to cause significant power savings.
# When the knob is set, any physical disk I/O (that might
# have caused the hard disk to spin up) causes Linux to flush all dirty blocks. The
# result of this is that after a disk has spun down, it will not be spun up
# anymore to write dirty blocks, because those blocks had already been written
# immediately after the most recent read operation. The value of the laptop_mode
# knob determines the time between the occurrence of disk I/O and when the flush
# is triggered.
# A task whose nice value is greater than this tunable value will never be considered as a "big" task (it will not be allowed to run
on a high-performance CPU).
# android background processes are set to nice 10. Never schedule these on the big cluster.
# echo 9 > /proc/sys/kernel/sched_upmigrate_min_nice # 15 default, 9 to never schedule background tasks on big Cluster, and 7
on Project Zhana
Known bugs:
Kernel Adiutor seems to change minimum number of big cores to 2 on Core Control. Avoid checking 'Hotplug' tab when using scripts with core_ctl support (try Kernel Adiutor-Mod if problem persists).
Thanks for credits
What auto run booting???
cenelyanto said:
What auto run booting???
Click to expand...
Click to collapse
Copy file to /etc/init.d and set the right permissions (see FAQ).
Keep in mind these scripts are deprecated.
booting noot run otomatic step by step for on ...otomatis run booting
Another "kernel optimizer"?
No. Well, yes. However, a "kernel optimizer" is a poor way to put it. KTweak performs kernel adjustments based on facts and evidence, unlike other optimizers with poorly written or heavily obfuscated code. For example:
LSpeed is almost 4000 lines long; completely unnecessary.
NFS Injector uses compiled binaries that are closed source... yuck. Not to mention the typos in the README. This one is hard to look at.
LKT sets random nonsensical build.props that likely don't even exist.
MAGNETAR uses (you guessed it) compiled binaries that install themselves to your /system/etc/ directory (???). Great idea, install an external closed source, compiled binary to the system partition.
Need I go on?
What's different about KTweak?
Unlike other "kernel optimizers", KTweak is:
Concice, at around 200 lines long,
Entirely open source with no compiled components,
Backed by logic and evidence,
Designed by an experienced kernel developer,
Non-intrusive, being completely systemless.
Benchmarks
The following benchmarks were performed on a OnePlus 7 Pro running the stock kernel provided by the OEM on Android 10.
hackbench -pTl 4000 (lower is better)
Without KTweak: ~20-50 seconds on average
With KTweak: ~4-6 seconds on average
perf bench mem memcpy (lower is better) (average of 50 iters)
Without KTweak: 14.01 ms
With KTweak: 10.40 ms
synthmark (voicemark) (higher is better)
Without KTweak: 374.94
With KTweak: 383.556
synthmark (latencymark little) (lower is better)
Without KTweak: 10
With KTweak: 10
synthmark (latencymark big) (lower is better)
Without KTweak: 12
With KTweak: 10
The Tweaks
In order to remain genuine, I have commited to explaining each and every kernel tweak that KTweak applies. Grab your coffee, this could take a while.
kernel.perf_cpu_time_max_percent: 25 --> 5
This is the maximum CPU time long perf event processing can take as a percentage. If this percentage is exceeded (meaning perf event processing used too much CPU time), the polling rate is throttled. This is reduced from 25% to 5%. We can afford inaccuracies with perf events in exchange for more time that a foreground task can use.
kernel.sched_autogroup_enabled: 0 --> 1
The Linux Kernel scheduler (CFS) distributes timeslices to each active task. For example, if the scheduling period is 10ms, and there are 5 tasks running, CFS will give each task 2ms of runtime for that scheduling cycle. However, this means that a SCHED_OTHER task may compete with a SCHED_FIFO task. Autogrouping groups task groups together during scheduling. For example, if the scheduling period is 10ms, and there are 6 SCHED_OTHER tasks running and 4 SCHED_FIFO tasks running, the SCHED_OTHER tasks will get 50% of the runtime and the SCHED_FIFO tasks will get the other 50%. For each task group, the timeslices are once again divided. The SCHED_FIFO tasks will get 12.5% runtime and the SCHED_OTHER tasks will get ~8.3% runtime. This usually offers better interactivity on multithreaded platforms. See scheduling priority documentation: https://man7.org/linux/man-pages/man7/sched.7.html See autogrouping off: https://www.youtube.com/watch?v=uk70SeGA7pg See autogrouping on: https://www.youtube.com/watch?v=prxInRdaNfc
kernel.sched_enable_thread_grouping: 0 --> 1
To my knowledge using the limited documentation of this tunable, this is basically autogrouping for thread groups.
kernel.sched_child_runs_first: 0 --> 1
When forking a child process from the parent, execute the child process before the parent process. This usually shaves down some latency on task initializations, since most of the time the child process is doing some form of heavy lifting.
kernel.sched_downmigrate: 20 20
Do not allow tasks to migrate back down to a lower-power CPU until the estimated CPU utilization would go below 20% on said CPU. This means tasks will stay on higher-performance CPUs for longer than usual.
kernel.sched_upmigrate: 80 80
Similar to the previous tunable, do not allow CPUs to migrate to the higher-performance CPUs unless the utilization goes above 80%.
kernel.sched_group_downmigrate: 20
The same as kernel.sched_downmigrate, except for whole task groups.
kernel.sched_group_upmigrate: 80
The same as kernel.sched_upmigrate, except for whole task groups.
kernel.sched_tunable_scaling: 0
This is more of a precaution than anything. Since the next few tunables will be scheduler timing related, we don't want the scheduler to scale our values for multiple CPUs, as we will be providing CPU-agnostic values.
kernel.sched_latency_ns: 10000000 (10ms)
Set the default scheduling period to 10ms. If this value is set too low, the scheduler will switch contexts too often, spending more time internally than executing the waiting tasks.
kernel.sched_min_granularity_ns: 1000000 (1ms)
Set the minimum task scheduling period to 1ms. With kernel.sched_latency_ns set to 1ms, this means that 10 tasks may execute within the 10ms scheduling period before we exceed it.
kernel.sched_migration_cost_ns: 500000 (0.5ms) --> 1000000 (1ms)
Increase the time that a task is considered to be cache hot. According to RedHat, increasing this tunable reduces the number of task migrations. This should reduce time spent balancing tasks and increase per-task performance. See RedHat: https://www.redhat.com/files/summit...tuning-of-Red-Hat-Enterprise-Linux-Part-1.pdf
kernel.sched_min_task_util_for_boost: 25
This value effects if tasks should be migrated to a higher performant CPU if it's utilization is above this amount. Allow tasks to be migrated upwards if the user is triggering a touch boost and the task is above 25% utilization.
kernel.sched_min_task_util_for_colocation: 50
This value is the same as the former, except it occurs when the user is not touching the screen. We shouldn't upmigrate tasks if the user isn't actively interacting with them (i.e. video streaming).
kernel.sched_nr_migrate: 32 --> 64
When migrating tasks between CPUs, allow the scheduler to migrate twice as many as usual. This should increase scheduling latency marginally, but increase the performance of SCHED_OTHER tasks.
kernel.sched_schedstats: 1 --> 0
Disable scheduler statistics accounting. This is just for debugging, but it adds overhead.
kernel.sched_wakeup_granularity_ns: 1000000 (1ms) --> 5000000 (5ms)
Require the current task to be surpassing the new task in vmruntime by 5ms instead of 1ms before preemption occurs. This should reduce jitter due to less frequent task interruptions.
kernel.timer_migration: 1 --> 0
Disable the migration of timers among CPUs. Usually, when a timer is created on one CPU, it would be able to be migrated to another CPU. However, this increases realtime latencies and scheduling interrupts. It can be turned off.
net.ipv4.tcp_ecn: 2 --> 1
Enable Explicit Congestion Notification for incoming and outgoing negotiations. This reduces packet losses.
net.ipv4.tcp_fastopen: 3
Enable data transmission during the SACK exchange point in TCP negotiation. This reduces packet latencies. Enable it for senders and receivers.
net.ipv4.tcp_syncookies: 1 --> 0
This tunable, when enabled, prevents denial of service attacks by allowing connection ACKs to be tracked. However, this is more-or-less unnecessary for a mobile device. It is more applicable for servers. Disable it.
net.ipv4.tcp_timestamps: 1 --> 0
RedHat claims that TCP timestamps may cause performance spikes due to time accounting code on high-performance connections. Disable it. See RedHat: https://access.redhat.com/documenta...ml/tuning_guide/reduce_tcp_performance_spikes
vm.compact_unevictable_allowed: 1 --> 0
Do not allow compaction of unevictable pages. With this set to 1, more compactions can happen at the cost of small page fault stalls. Turn this off to compact less but avoid aforementioned stalls.
vm.dirty_background_ratio: 5 --> 10
Start writing back dirty pages (pages that have been modified but not yet written to the disk) asynchronously at 10% memory dirtied instead of 5%. Writing dirty pages back too early can be inefficient and overutilize the storage device.
vm.dirty_ratio: 20 --> 30
This tunable is the same as the former, but it is the ceiling for synchronous dirty writeback, meaning all I/O will stall until all dirty pages are written out to the disk. We usually won't need to worry about hitting this value, as the background writeback can catch up before we reach 20% memory dirtied. But as a precaution (i.e. heavy file transfers), increase this value to a 30% ceiling to prevent visible system stalls. We are sacrificing available memory in exchange for a reduced change of a brief system stall.
vm.dirty_expire_centisecs: 300 (3s) --> 1000 (10s)
This is the longest that dirty pages can remain in the system before they are forcefully written out to the disk. By increasing this value, we can allow the dirty background writeback to take its time asynchronously, and avoid unnecessary writebacks that can clog the flusher thread.
vm.dirty_writeback_centisecs: 500 (5s) --> 0 (0s)
Do not periodically writeback data every 5 seconds. Instead, leave it to the dirty background writeback to wake up when the dirty memory of the system hits 10%. This allows the dirty pages to stay in memory for longer, possibly increasing cache locality as the page cache is still available in memory.
vm.extfrag_threshold: 500 --> 750
Compact memory more often, even if the memory allocation was estimated to be due to a low-memory status. This lets us put more data into RAM at the expense of running compation more often. This is a worthy tradeoff, as it reduces memory fragmentation, which is incredibly important for ZRAM.
vm.oom_dump_tasks: 1 --> 0
Do not dump debug information when (or if) we run out of memory. If we have a lot of tasks running, and are OOMing often, then this overhead can add up.
vm.page-cluster: 3 --> 0
Disable reading additional pages from the swap device (in most cases, ZRAM). This is the same philosophy as disabling readahead.
vm.reap_mem_on_sigkill: 0 --> 1
When we kill a task, clean its memory footprint to free up whatever amount of RAM it was consuming.
vm.stat_interval: 1 --> 10
Update /proc/stat information every 10 seconds instead of every second, reducing jitter on loaded systems.
vm.swappiness: 100 --> 80
Swap to ZRAM less often if we don't have to. ZRAM can become expensive due to constant compression and decompression. If we can keep some of the memory uncompressed in regular RAM, we can avoid that overhead.
vm.vfs_cache_pressure: 100 --> 200
This tunable controls the kernel's tendency to reclaim inodes and dentries over page cache. Inodes and dentries are information about file metadata and directory structures, while page cache is the actual cached contents of a file. By increasing this value to 200, we tell the kernel to prefer claiming inodes and dentries over the page cache, increasing the chance of a cache hit when referencing recently used data, while not polluting the RAM with less-important information.
Next Buddy
By scheduling the last woken task first, we can increase cache locality since that task is likely to touch the same data as before.
No Strict Skip Buddy
Usually, the scheduler will always choose to skip tasks that call yield(). However, these yeilding tasks may be of higher importance than the last or next buddy that are available. Do not always skip the skip buddy if we don't have to.
No Nontask Capacity
The scheduler decrements the perceived CPU capacity that longer the CPU has been idle for. This means that an idle CPU may be skipped during task placement, and a task can be grouped with a busier CPU. Disable this to improve task start latency.
TTWU Queue
Allow the scheduler to place tasks on their origin CPU, increasing cache locality if the CPU is non-local (i.e. a cache hit would definitely have been missed).
Governor Tweaks
hispeed_load: 90 --> 80: Jump to a higher frequency if we are approaching the end of the frequency list, where a task may begin to starve or begin to stutter.
hispeed_freq: : Set the "higher freq" (referencing hispeed_load) to the maximum frequency available to take advantage of Race-To-Idle.
CAF CPU Boost Tweaks
input_boost_freq: 1.4 GHz (closest freq) as a generic, universal boost frequency to the little cluster.
input_boost_ms: 250 ms, not consuming too much power but boosting for important, interactive events such as clicking on things.
I/O
iostats: 1 --> 0: Disable I/O statistics accounting, which adds overhead.
readahead: 0: Disable readahead, which is intended for disks with long seek times (HDD), whereas mobile devices use flash storage with zero seek time.
nr_requests: 128 --> 512: Allow more I/O requests to be issued before flushing the queue, slightly increasing latencies but allowing more requests to be executed before being put to sleep.
noop / none: Use a scheduler with little CPU overhead to reduce I/O latencies, which is essential for fast flash storage (eMMC & UFS).
ZRAM
ZRAM reduces disk wear by reducing disk writes, and also increases cache locality by allowing more data to fit in RAM at once. KTweak configures ZRAM to take up at most half of the available RAM on the system, which is a good ratio of RAM to ZRAM for a mobile device.
Other Notes
You should know that KTweak applies after 60s of uptime as to prevent Android's init from overwriting any values.
Contact
You can find me on telegram at @tytydraco. Feel free to email me at [email protected].
Downloads
All releases and the entire source code for KTweak is available on GitHub:
Downloads
XDA:DevDB Information
KTweak, Tool/Utility for all devices (see above for details)
Contributors
tytydraco, tytydraco
Source Code: https://github.com/tytydraco/ktweak
Version Information
Status: Stable
Current Stable Version: v1.0.7
Stable Release Date: 2020-08-16
Created 2020-08-16
Last Updated 2020-08-16
What are the requirements to use this? Root with Magisk is a given - but Linux kernel version, Android OS version, device, etc?
MishaalRahman said:
What are the requirements to use this? Root with Magisk is a given - but Linux kernel version, Android OS version, device, etc?
Click to expand...
Click to collapse
The script adjusts only the tweaks that are compatible with your version. It contains tweaks for EAS, HMP, and supports 3.18 and above in testing. It likely supports even lower. Otherwise, it's totally universal.
KTweak now has an official Telegram channel for release information and changelogs: @ktweak
Thank you for your work and great explanation ?
This will work on lineage kernel?
Hello there. Im using ver 1.0.9. I updated and tried 1.1.0 but ended up in reboots after boot complete. I am using NX kernel which seta vfs cache pressure to 100. May that be the case?
Now back to 1.0.9 and everything seems fine. However, I had to uninstall and reinstall magisk, because when Ive flashed 1.0.9 ober 1.1.0, I was still experiwncing problems.
lapirado said:
Thank you for your work and great explanation ?
This will work on lineage kernel?
Click to expand...
Click to collapse
This should work on any kernel
myaslioglu said:
Hello there. Im using ver 1.0.9. I updated and tried 1.1.0 but ended up in reboots after boot complete. I am using NX kernel which seta vfs cache pressure to 100. May that be the case?
Now back to 1.0.9 and everything seems fine. However, I had to uninstall and reinstall magisk, because when Ive flashed 1.0.9 ober 1.1.0, I was still experiwncing problems.
Click to expand...
Click to collapse
Hi! Thanks for the report. Which device and Android version are you using? I have an idea of why this could be happening.
myaslioglu said:
Hello there. Im using ver 1.0.9. I updated and tried 1.1.0 but ended up in reboots after boot complete. I am using NX kernel which seta vfs cache pressure to 100. May that be the case?
Now back to 1.0.9 and everything seems fine. However, I had to uninstall and reinstall magisk, because when Ive flashed 1.0.9 ober 1.1.0, I was still experiwncing problems.
Click to expand...
Click to collapse
Hi myaslioglu,
I've released v1.1.1 which adds an additional 20 second sleep after Android reports that it has been initialized. This should prevent init and any post-boot init scripts from running alongside ktweak. I believe your issue stems from ZRAM resizing itself alongside bootup, where memory is most scarce, possibly causing your device to think it failed to bootup correctly.
Please let me know if v1.1.1 fixes your issue. It is live on GitHub releases and Telegram.
tytydraco said:
Hi myaslioglu,
I've released v1.1.1 which adds an additional 20 second sleep after Android reports that it has been initialized. This should prevent init and any post-boot init scripts from running alongside ktweak. I believe your issue stems from ZRAM resizing itself alongside bootup, where memory is most scarce, possibly causing your device to think it failed to bootup correctly.
Please let me know if v1.1.1 fixes your issue. It is live on GitHub releases and Telegram.
Click to expand...
Click to collapse
Hello. Sorry I forgot to report my device, it is s8 exynos just in case. But 1.1.1 fixed the issue. Works perfect! Thanks
myaslioglu said:
Hello. Sorry I forgot to report my device, it is s8 exynos just in case. But 1.1.1 fixed the issue. Works perfect! Thanks
Click to expand...
Click to collapse
1.1.2 got me reboots again. What has changed? Only the swappiness? Worked fine on 1.1.1 and did not work on 1.1.0 as aforementioned.
Can zram be the issue?
1.1.1 made my op7pro freeze with weeb kernel ??* and we have the same device draco
Doesn't work on stock kernel of redmi note 9s, freezes a few seconds after boot,forcing me to hard restart
It compatible with j5 (2015)?
To those of you getting freezes, I have identified the cause to be related to ZRAM. I will push an update today that will remove ZRAM tweaking from the script.
The reason I believe this is happening is because ktweak tries to resize the ZRAM. That requires all data that is currently in ZRAM to decompress and enter your main memory unit. If we run out of memory during this process, we will freeze.
The solution is to not adjust the zram size when using ktweak. Sorry for the inconveniences that may have been caused. I'll get straight to fixing this as soon as possible.
I've heard about your work from xda Telegram channel.
I read the info and thought to test it, but as some users reported as latest update having freeze issue. I'll test with freeze issue fixed update.?
tytydraco said:
To those of you getting freezes, I have identified the cause to be related to ZRAM. I will push an update today that will remove ZRAM tweaking from the script.
The reason I believe this is happening is because ktweak tries to resize the ZRAM. That requires all data that is currently in ZRAM to decompress and enter your main memory unit. If we run out of memory during this process, we will freeze.
The solution is to not adjust the zram size when using ktweak. Sorry for the inconveniences that may have been caused. I'll get straight to fixing this as soon as possible.
Click to expand...
Click to collapse
I ever disabled ZRAM on my OP7 PRO feels more fluid
Is working on mi 10 pro?
Vivo v9
How can I root vivo v9 1723?
I tried many methods but nothing work for me.
Please help
tyagis777 said:
How can I root vivo v9 1723?
I tried many methods but nothing work for me.
Please help
Click to expand...
Click to collapse
Really? You created an account for this post?