I absolutely take no creative credit in making this kernel as all I have done is putting them together and build based on the LEO kernel tree. The real credit goes to them.
I am using a TMobile HD2 / ChuckyDroidROm / Radio 2.12.50. Please note that the HAVS does not work well with interactive governor (but it may still works for you device). If you are experiencing scrolling lag, try the kernel without BFS feature.
I did not go through each one of them. I have only tested the BFQ-OC-UV-AXI-850mv-0.1.e with darkstone's HD, which works fine on my HD2. Its bit slow at start once everything is settle down, its pretty fast and no lag for me. But this might not be the case for you.
In the future, i will only provide the kernels that are popular. Right now, there are just too many combinations and takes really long time to upload them.
feature:
AB: Audio Boost
AXI: AXI frequency tweak
BFQ: BFQ IO scheduler (default CFS)
BFS: BFS cpu scheduler (default CFS)
HAVS: Hybrid Adaptive Voltage Scaling (Static Voltage Scaling - SVS is default)
OC: OverClock
UV: UnderVolt
OC, UV and AXI features are the standard feature for EVO based kernel.
EBAT: Extended battery (please provide feedback to hastarin http://forum.xda-developers.com/showthread.php?t=787588)
By default, the EVO based kernels are not overclocked. Please use setCPU or userinit.sh/user.conf script to enable overclock.
You can choice the combination you want.
EVO based kernel:
version 0.1.h (I will do another kernel update tomorrow as there is a new commit which fixes random ts freeze)
BFQ-OC-UV-AXI_850mv-0.1.h-evo.zip
BFQ-OC-UV-AXI_925mv-0.1.h-evo.zip
BFQ-OC-UV-AXI_1000mv-0.1.h-evo.zip
BFQ-OC-UV-AXI_1050mv-0.1.h-evo.zip
BFQ-OC-UV-AXI-AB_850mv-0.1.h-evo.zip
BFQ-OC-UV-AXI-AB_925mv-0.1.h-evo.zip
BFQ-OC-UV-AXI-AB_1000mv-0.1.h-evo.zip
BFQ-OC-UV-AXI-AB_1050mv-0.1.h-evo.zip
BFQ-OC-UV-AXI-EBAT_850mv-0.1.h-evo.zip
BFQ-OC-UV-AXI-EBAT_925mv-0.1.h-evo.zip
BFQ-OC-UV-AXI-EBAT_1000mv-0.1.h-evo.zip
BFQ-OC-UV-AXI-EBAT_1050mv-0.1.h-evo.zip
BFQ-OC-UV-AXI-EBAT-AB_850mv-0.1.h-evo.zip
BFQ-OC-UV-AXI-EBAT-AB_925mv-0.1.h-evo.zip
BFQ-OC-UV-AXI-EBAT-AB_1000mv-0.1.h-evo.zip
BFQ-OC-UV-AXI-EBAT-AB_1050mv-0.1.h-evo.zip
BFS-BFQ-OC-UV-AXI_850mv-0.1.h-evo.zip
BFS-BFQ-OC-UV-AXI_925mv-0.1.h-evo.zip
BFS-BFQ-OC-UV-AXI_1000mv-0.1.h-evo.zip
BFS-BFQ-OC-UV-AXI_1050mv-0.1.h-evo.zip
BFS-BFQ-OC-UV-AXI-AB_850mv-0.1.h-evo.zip
BFS-BFQ-OC-UV-AXI-AB_925mv-0.1.h-evo.zip
BFS-BFQ-OC-UV-AXI-AB_1000mv-0.1.h-evo.zip
BFS-BFQ-OC-UV-AXI-AB_1050mv-0.1.h-evo.zip
BFS-BFQ-OC-UV-AXI-EBAT_850mv-0.1.h-evo.zip
BFS-BFQ-OC-UV-AXI-EBAT_925mv-0.1.h-evo.zip
BFS-BFQ-OC-UV-AXI-EBAT_1000mv-0.1.h-evo.zip
BFS-BFQ-OC-UV-AXI-EBAT_1050mv-0.1.h-evo.zip
BFS-BFQ-OC-UV-AXI-EBAT-AB_850mv-0.1.h-evo.zip
BFS-BFQ-OC-UV-AXI-EBAT-AB_925mv-0.1.h-evo.zip
BFS-BFQ-OC-UV-AXI-EBAT-AB_1000mv-0.1.h-evo.zip
BFS-BFQ-OC-UV-AXI-EBAT-AB_1050mv-0.1.h-evo.zip
BFS-HAVS-BFQ-OC-UV-AXI_850mv-0.1.h-evo.zip
BFS-HAVS-BFQ-OC-UV-AXI_925mv-0.1.h-evo.zip
BFS-HAVS-BFQ-OC-UV-AXI_1000mv-0.1.h-evo.zip
BFS-HAVS-BFQ-OC-UV-AXI_1050mv-0.1.h-evo.zip
BFS-HAVS-BFQ-OC-UV-AXI-AB_850mv-0.1.h-evo.zip
BFS-HAVS-BFQ-OC-UV-AXI-AB_925mv-0.1.h-evo.zip
BFS-HAVS-BFQ-OC-UV-AXI-AB_1000mv-0.1.h-evo.zip
BFS-HAVS-BFQ-OC-UV-AXI-AB_1050mv-0.1.h-evo.zip
BFS-HAVS-BFQ-OC-UV-AXI-EBAT_850mv-0.1.h-evo.zip
BFS-HAVS-BFQ-OC-UV-AXI-EBAT_925mv-0.1.h-evo.zip
BFS-HAVS-BFQ-OC-UV-AXI-EBAT_1000mv-0.1.h-evo.zip
BFS-HAVS-BFQ-OC-UV-AXI-EBAT_1050mv-0.1.h-evo.zip
BFS-HAVS-BFQ-OC-UV-AXI-EBAT-AB_850mv-0.1.h-evo.zip
BFS-HAVS-BFQ-OC-UV-AXI-EBAT-AB_925mv-0.1.h-evo.zip
BFS-HAVS-BFQ-OC-UV-AXI-EBAT-AB_1000mv-0.1.h-evo.zip
BFS-HAVS-BFQ-OC-UV-AXI-EBAT-AB_1050mv-0.1.h-evo.zip
HAVS-BFQ-OC-UV-AX_850mv-0.1.h-evo.zip
HAVS-BFQ-OC-UV-AX_925mv-0.1.h-evo.zip
HAVS-BFQ-OC-UV-AX_1000mv-0.1.h-evo.zip
HAVS-BFQ-OC-UV-AX_1050mv-0.1.h-evo.zip
HAVS-BFQ-OC-UV-AX-AB_850mv-0.1.h-evo.zip
HAVS-BFQ-OC-UV-AX-AB_925mv-0.1.h-evo.zip
HAVS-BFQ-OC-UV-AX-AB_1000mv-0.1.h-evo.zip
HAVS-BFQ-OC-UV-AX-AB_1050mv-0.1.h-evo.zip
HAVS-BFQ-OC-UV-AX-EBAT_850mv-0.1.h-evo.zip
HAVS-BFQ-OC-UV-AX-EBAT_925mv-0.1.h-evo.zip
HAVS-BFQ-OC-UV-AX-EBAT_1000mv-0.1.h-evo.zip
HAVS-BFQ-OC-UV-AX-EBAT_1050mv-0.1.h-evo.zip
HAVS-BFQ-OC-UV-AX-EBAT-AB_850mv-0.1.h-evo.zip
HAVS-BFQ-OC-UV-AX-EBAT-AB_925mv-0.1.h-evo.zip
HAVS-BFQ-OC-UV-AX-EBAT-AB_1000mv-0.1.h-evo.zip
HAVS-BFQ-OC-UV-AX-EBAT-AB_1050mv-0.1.h-evo.zip
Click to expand...
Click to collapse
if you are experiencing scrolling lag, try the kernel without BFS.
N1/htc-msm-2.6.32.9 based kernel (I tested the BFS-HAVS-BFQ-OC-UV-AXI_850mv-0.1.b kernel works fine so far.):
version 0.1.d
BFQ-OC-UV-AXI_850mv-0.1.d-n1.zip
BFQ-OC-UV-AXI_925mv-0.1.d-n1.zip
BFQ-OC-UV-AXI_1000mv-0.1.d-n1.zip
BFQ-OC-UV-AXI_1050mv-0.1.d-n1.zip
BFS-BFQ-OC-UV-AXI_850mv-0.1.d-n1.zip
BFS-BFQ-OC-UV-AXI_925mv-0.1.d-n1.zip
BFS-BFQ-OC-UV-AXI_1000mv-0.1.d-n1.zip
BFS-BFQ-OC-UV-AXI_1050mv-0.1.d-n1.zip
BFS-HAVS-BFQ-OC-UV-AXI_850mv-0.1.d-n1.zip
BFS-HAVS-BFQ-OC-UV-AXI_925mv-0.1.d-n1.zip
BFS-HAVS-BFQ-OC-UV-AXI_1000mv-0.1.d-n1.zip
BFS-HAVS-BFQ-OC-UV-AXI_1050mv-0.1.d-n1.zip
HAVS-BFQ-OC-UV-AXI_850mv-0.1.d-n1.zip
HAVS-BFQ-OC-UV-AXI_925mv-0.1.d-n1.zip
HAVS-BFQ-OC-UV-AXI_1000mv-0.1.d-n1.zip
HAVS-BFQ-OC-UV-AXI_1050mv-0.1.d-n1.zip
version 0.1.c
BFQ-OC-UV-AXI_925mv-n1-0.1.c.zip (2.21 MB)
version 0.1.b
BFQ-OC-UV-AXI_850mv-0.1.b.zip
BFQ-OC-UV-AXI_925mv-0.1.b.zip
BFQ-OC-UV-AXI_1000mv-0.1.b.zip
BFQ-OC-UV-AXI_1050mv-0.1.b.zip
BFS-BFQ-OC-UV-AXI_850mv-0.1.b.zip
BFS-BFQ-OC-UV-AXI_925mv-0.1.b.zip
BFS-BFQ-OC-UV-AXI_1000mv-0.1.b.zip
BFS-BFQ-OC-UV-AXI_1050mv-0.1.b.zip
BFS-HAVS-BFQ-OC-UV-AXI_850mv-0.1.b.zip
BFS-HAVS-BFQ-OC-UV-AXI_925mv-0.1.b.zip
BFS-HAVS-BFQ-OC-UV-AXI_1000mv-0.1.b.zip
BFS-HAVS-BFQ-OC-UV-AXI_1050mv-0.1.b.zip
HAVS-BFQ-OC-UV-AXI_1000mv-0.1.b.zip
HAVS-BFQ-OC-UV-AXI_1050mv-0.1.b.zip
HAVS-BFQ-OC-UV-AXI_850mv-0.1.b.zip
HAVS-BFQ-OC-UV-AXI_925mv-0.1.b.zip
Click to expand...
Click to collapse
EVO Log:
version 0.1.h
- based on git commit. Check gitorious for detail
* ts improvement (Markinus committed code to improve TS performance, This should reduce/eliminate the scrolling lag)
version 0.1.g
- based on git commit. Check gitorious for detail
- BFS 357
- minor change to BFQ
version 0.1.f
- based on git commit
- patch to 2.6.32.24
version 0.1.e
- based on git commit
* Working compass. A big thanks to Rajko!
- Extended battery support by Hastarin
- Thanks to michyprima's patch to fix issue with Airplane mode freezing the phone
- Memory leak fixed in firmware
- Mutex bug fix
- fix dma_sync_single_range*
- fix incorrect optimization for cpu govenors
- remove rwsem lock from CPUFREQ_GOV_STOP call (second call site) in CPUFREQ
- EXT4
* flush delaloc blocks when space is low
* fix async i/o write beyond 4GB to a sparse file
* correctly calculate number of blocks for fiemap
* prevent creation of files larger than RLIMIT_FSIZE using fallocate
* Ensure zeroout blocks have no dirty metadata
* fix possible lost inode write in journal mode
* fix memory leaks in error path handling of ext4_ext_zeroout()
* fix BUG_ON at fs/buffer in no journal mode
* fix potential quota dealock
- CIFS
* remove bogus frist)time check in NTLMv2 session setup code
* don't attemp busy-file rename unless it's in same directory
* fix malicious redirect problem in DNS lookup code
- CFS cpu scheduler
* fix over scheduling bug
* implement different treatment for idle shares
- fixes voltage table for both HAVS and SVS
Many of these patches are from kernel.git and all credit goes to the linux project
version 0.1.d
base on commit a8211687
- patch by gauner1986
* add video clean up and many twaking by gauner1986
* enable dot11n (gauner1986)
* add INT_AD6_EXT_VFR to fake irq (gaunner1986)
- add hastarin compass offset
make sure you add "nand_boot=0" parameter to kernel cmdline argument in startup.txt. eg.
{{{
set cmdline "rel_path=Android nand_boot=0"
}}}
version 0.1.c
add interactive cpufreq governor (as i forgot to apply the patch in previous versions).
version 0.1.b
disable framefuffer console to reduce wake up delay and high standby power consumption
version 0.1.a (EVO based commit
- BFS version 318
- BFQ I/O scheduler
- msm_kgsl mod
* enable shadow write to improve video performance
* Use writecombine flag to map vmalloced memory (video performance improvement)
- Overclock to 1.152GHz
- Provide four different undervolt versions 850mV, 925mV, 1000mV and 1050mV(default)
- Audio boost
- Interactive governor
- Some minor tweaking to on-demand and conservative governor
- Ext4 is enabled by default
Click to expand...
Click to collapse
N1 Log:
version 0.1.d
- minor BFQ update
- BFS 357
version 0.1.c (experimental)
- fix the TS freeze issue (i haven't encounter freeze yet)
- Working compass. A big thanks to Rajko! (haven't test it yet)
- add ElBartoME's BT port (not sure this is working or not)
- patch kernel to 2.6.32.24 (for BFS testing)
version 0.1.b
minor HAVS changes
version 0.1.a N1 based commit )
- BFS version 318
- BFQ I/O scheduler
- msm_kgsl mod
* enable shadow write to improve video performance
* Use writecombine flag to map vmalloced memory (video performance improvement)
- Overclock to 1.152GHz
- Provide four different undervolt versions 850mV, 925mV, 1000mV and 1050mV(default)
- Audio boost
- Interactive governor
- Some minor tweaking to on-demand and conservative governor
- Ext4 is enabled by default
Click to expand...
Click to collapse
The purpose of HAVS is to minimize the power consumption by
dynamic adjust the optimal voltage, and limit the maximum voltage.
The optimal voltage is actively determined for each frequency and
temperature. HAVS actively adjusts the CPU voltage as the CPU
frequency and temperature changes.
Click to expand...
Click to collapse
BFQ(Budget Fair Queueing) is a I/O Scheduler. BFQ is a proportional
share disk scheduling algorithm, based on CFQ, that supports
hierarchical scheduling using a cgroups interface.
BFQ generally performs better (for desktops) were perceived intractability
(vs real throughput) is preferred. CFQ may unwittingly penalise a well written
program with fast throughput, in favour of a slower program by virtue of its
reliance on allocated 'throughput' vs BFQ's 'time' reliance.
http://algo.ing.unimo.it/people/paolo/disk_sched/
http://groups.google.com/group/zen_kernel/browse_thread/thread/88871a70cecd707b#
Click to expand...
Click to collapse
What is BFS(Brain **** Scheduler):http://ck.kolivas.org/patches/bfs/sched-BFS.txt
FAQS about BFS:http://ck.kolivas.org/patches/bfs/bfs-faq.txt
WIKI http://en.wikipedia.org/wiki/Brain_Fuck_Scheduler
Click to expand...
Click to collapse
Credits:
ridikolous, ReX83, eyanlaya (for testing)
HTC LEO kernel tree (base kernel, based on NEXUS one/HTC-MSM-2.6.32 kernel tree)
HTC LEO kernel tree (base kernel, based on HTC EVO kernel tree)
Con Kolivas (BFS)
Fabio Checconi (BFQ)
Ian (Overclock, undervolt and AXI)
pershoot (voltages and other fixes)
IntersectRaven (HAVS)
and many other developers.
Click to expand...
Click to collapse
I hope someone can take advantage of the source and make it better as i have limited time to test and improve them.
My gitorious for evo based kernel (something wrong with my old tree, so i recreate a new one)
if you like the work i do, you are always welcome to buy me a cup of coffee
thx good work
http://forum.xda-developers.com/showpost.php?p=8050200&postcount=8
Hi,
is the freeze fix from gauner1986 include (previos post)?
with friendly greet
starbase64
support for extended battery , PLZZZZZZZZZZZZZZZZZZZZ
how to use this ??? are these zimages ...--(but wats this tun.ko and bcm4329.ko?)
Hi,
copy and overwrite the ko files to /system/lib/modules.
with friendly greet
starbase64
Does this fix the battery consumption and wake-up from sleep problems which were encountered with the G-sensor fix kernel?
support for extended battery included?
mattc 1.7 ppp
Nice have to test it out.
Testing on DarkStone's Sense V2
does this include darkstones graphic improvement mod?
edit: just tried it and the accelerometer response is slow and so is the touchscreen. That said the performance is very good and it played ashalt 5 the smoothest i have seen any kernel do. Im using the 850 undervolt version with mattc 1.7 rmnet. Thanks for the kernel but i think ill wait until these issues are fixed
Thank you..
this kernel is very nice for Froyostone v2.
starbase64 said:
Hi,
copy and overwrite the ko files to /system/lib/modules.
with friendly greet
starbase64
Click to expand...
Click to collapse
thankuuuu brother
peace
Nice...look good for freeze problem
What is this for this guy not even answering that question
testing in bangter 1.2a
my quadran result 1920 (of max cpu speed )
chris-m said:
testing in bangter 1.2a
my quadran result 1920 (of max cpu speed )
Click to expand...
Click to collapse
can you use anyone of these?
no sorry, i'm using bangters relase for the quotidian usage
and i use kernel 1050mV(default);
i shall test the other builds if the battery wears out too fast..
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.
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
Custom kernel for Samsung Galaxy S Advance
Code:
/*
* Your (probably expired) warranty is now void.
*
* I am not responsible for bricked devices, dead SD cards,
* thermonuclear war, or you getting fired because the alarm app failed. Please
* do some research if you have any concerns about features included in this kernel
* before flashing it! YOU are choosing to make these modifications, and if
* you point the finger at me for messing up your device, I will laugh at you.
*/
Hi there!
Because of numerous issues found in 3.4.113 kernel, I'm temporarily moving to development on 3.0.101 base.
What is difference between chrono kernel (CK) and CK refresh build? CK was mostly tested on MM-based ROMs, but appeared not to work stably on Android 4.4.x. Aim of this build is to properly enable support for older ROMs (like kitkat), and when done, merge these changes to 3.4.113 kernel.
This build is based upon chrono kernel r4.1 build, so to avoid versions confusion, I'm creating a separate topic.
Features:
CPU, GPU and DDR OC support
more governors and I/O schedulers
Lite kernel - some kernel features moved as modules
F2FS support
ABB-charger tweaks
many others features and tweaks...
Credits:
@dh.harald and @hafidzduddin for contribution on U8500 platform sources
@ Team Canjica for a base for this kernel
@ Nova Fusion for F2FS implementation
@zwliew for contribution on TC kernel
@cocafe for LiveOPP, GPU OC, abbamp and abb-charger tweaks and many cool patches which I've used from his kernel
@faux123 for dynamic Fsync implementation
@Christopher83 for dynamic management of dirty page writebacks implementation
@KINGbabasula for contribution on TC kernel sources
@boype for SIOPlus tweaks and OndemandPlus governor
@Adi_Pat for abbamp, kernel tweaks
@PolishVodka for initramfs scripts for 4.2.x and 5.0.x
@Rox for help in fixing initramfs scripts for 4.1.2
@ace2nutzer for optimization CPU OC and for whatever scripts which I have used in my kernel
@Meticulus for BLN, Sweep2wake and Doubletap2wake
@mkaluza for huge LiveOPP/Mali improvements and Dynamic governor
@yanpol199 for help with F2FS support in TWRP
@ all users who tests this kernel and directs the development along the right path
@ all those users, who I forgot to mention (PM me if so)
Team Win for TWRP recovery
Samsung for opening kernel source
Linus Torvalds for Linux sources
Special Thanks:
@isaak, @enkflr, @Pdevo, @prometej-zg for donating this phone!
[*]@S.AMU for providing FTP-Server
Source Code:
LK 3.0.y based releases
Installation:
Flash temporary kernel (if coming from other recoveries than TWRP 3.1.1)
Reboot recovery
Flash kernel zip
Notice: this kernel is not compatible with NovathorSettings app, be sure to remove it before installing a kernel!
Download:
FTP
XDA:DevDB Information
Chrono Kernel Refresh, Kernel for the Samsung Galaxy S Advance I9070
Contributors
ChronoMonochrome, cocafe, faux123, zwliew, mkaluza, Meticulus, KINGbabasula, ace2nutzer, TeamCanjica
Source Code: https://github.com/ChronoMonochrome/Chrono_Kernel-1/commits/refresh-3.0.101
Kernel Special Features:
Version Information
Status: Testing
Stable Release Date: 1974-11-11
Beta Release Date: 1974-11-11
Created 2018-03-22
Last Updated 2018-03-23
Changelogs
Changelog
R4.6.2
rebased to CM14.1 branch (added support for 6.0.1 and 7.1.2 ROMs)
R4.6.1
fixed CPU OC instabilities
LCDCLK is adjusted to fix tearing issues *
adjusted Dynamic CPU governor tunables for a better battery live
adjusted PowerHAL profiles **
genfstab: storages swap is disabled by default (remove /ramdisk/fstab_specs.txt before flashing to take this change in an effect)
updated temporary kernel zip
* tested with apps like Impossible Game, a display tearings are mostly resolved here. Apps like Youtube, though, might still causing tearings when playing video.
** the minimum CPU freq is set to 400 MHz. I've decided to use it as a default since 200 and 400 MHz CPUfreq steps are anyway using the same voltage, so unless you're undervolting the CPU, there won't be any significant difference in a battery drain.
R4.6
updated to r4.6 LowMemoryKiller implementation - best so far!
Disabled HighMem
removed some CPUfreq steps *
Dynamic governor: parameters are tuned for the better performance (credits: @ace2nutzer)
Added performance profiles (the corresponding parameters can be found in /ramdisk/perf.profiles.rc)
Other updates from r4.6 (various updates from LK 3.4, tweaks etc)
* Avalable CPU frequency steps are: 200, 800, 1000, 1100, 1200, 1215 Mhz. I've decided just to give it a try - this is a necessary part of tuning the CPU governor. If anyone doesn't like that frequencies between 200 and 800 MHz were removed I can add them back, but until performance-related issues are not resolved I'd suggest just leave as it is.
R4.1
Initial build for janice (kernel sources based on Chrono Kernel r4.1)
LiveOPP: updated to r5.7.1 kernel version
Exfat: test fixes for Stock 4.1.2 ROM (not tested)
Enabled CONFIG_STE_TRACE_MODEM (test fix for Stock ROM incoming / outgoing calls)
Kexec: added janice support
Misc
Storages switch
By default, this kernel comes with internal and external storages switched. You can revert this behavior, by changing the line
Code:
use_swap=1
to
Code:
use_swap=0
in file /ramdisk/fstab_specs.txt and flashing the kernel package. This setting will remain until you format /ramdisk partition.
Thank you Chrono again.
So far I am still having issues with calls on 4.1.2 stock, I took another logcat in case would help you, and seems like phone can't enter deepsleep mode, but I will investigate further this issue with some days of usage.
I couldn't get exfat working, I took the exfat-fuse binary from /sbin in TWRP, then ran "exfat-fuse /dev/block/mmcblk1p1 /storage/extSdCard", tryed also with "mount.exfat-fuse etc etc", the fact is the card is correctly mounted and usable from recovery, but this does not matter after all.
The nice thing is I find multitasking working far better, phone seems to be more responsive in situations where more apps are running at the same time, this is very good to me!.
Another big point is installation went fine and recovery is working perfectly, so problems with possible bootloops are solved (and after some more usage I will go further to your more updated roms )
If there is something more to provide you, test or informations missing, please ask me Chrono
I tested chrono kernel r4.1 on Lineage OS 11.
-Compared to the previous chrono_kernel_r5.7.1, this is considerably slow, especially during the opening of apps like Settings, Contacts, Google News, Play store.
-If I set 1000 Mhz as maximum clock of the dynamic governor, the phone becomes slower and a bit hot on the back.
Multitasking is severely affected by that clock. Multitasking is more stable at 800 Mhz, despite it's still slow.
-If I reboot the phone, the maximum clock of 1000 Mhz is automatically resetted at 800 Mhz.
-If I attempt to reboot the phone in recovery mode from Lineage Os 11 ROM with the PC USB charging cable on, phone will shutdown instead. Disconnecting the charging cable before rebooting the phone in recovery mode is the only workaround. It doesn't happen with the Epirex Kernel, so I think it's related to your kernel.
In my attachment there is a meminfo that I took while the phone was under load.
If it isn't enough, I attached a full logcat. There are some errors and crashes.
@Pdevo, @isaak, thanks for testing!
I tested chrono kernel r4.1 on Lineage OS 11.
-Compared to the previous chrono_kernel_r5.7.1, this is considerably slow, especially during the opening of apps like Settings, Contacts, Google News, Play store.
Click to expand...
Click to collapse
Probably I've rushed things, or sort of. I had a hard time trying to find a considerably stable kernel 3.0.101 base (this one appeared to work stably, though not best, in terms of the performance). Nevertheless, the multitasking should already be better (at least better than in r5.7.1, as in this one LowMemoryKiller appeared not to work at all). I'm updating the sources to a new kernel base, r4.6 which should be even better in multitasking term.
-If I reboot the phone, the maximum clock of 1000 Mhz is automatically resetted at 800 Mhz.
Click to expand...
Click to collapse
Should be fixed in upcoming release.
-If I attempt to reboot the phone in recovery mode from Lineage Os 11 ROM with the PC USB charging cable on, phone will shutdown instead. Disconnecting the charging cable before rebooting the phone in recovery mode is the only workaround. It doesn't happen with the Epirex Kernel, so I think it's related to your kernel.
Click to expand...
Click to collapse
It's a bug in CM11 ramdisk, I've took another one from Codina, and now this issue should be resolved as well.
Pdevo said:
So far I am still having issues with calls on 4.1.2 stock, I took another logcat in case would help you, and seems like phone can't enter deepsleep mode, but I will investigate further this issue with some days of usage.
I couldn't get exfat working, I took the exfat-fuse binary from /sbin in TWRP, then ran "exfat-fuse /dev/block/mmcblk1p1 /storage/extSdCard", tryed also with "mount.exfat-fuse etc etc", the fact is the card is correctly mounted and usable from recovery, but this does not matter after all.
Click to expand...
Click to collapse
I'm afraid that exfat driver built in the kernel is not compatible with this userspace mount.exfat-fuse utility. I won't be able to fix it, until I find a time to return to stock & rebuild either mount.exfat-fuse or kernel driver in order to make them compatible each with other.
As for the deepsleep issue, I can say that at least 4.4.4 is not affected by this bug. Try making sure that no apps are preventing deep sleep (Better battery stats or Wakelock detector can help in that).
New build r4.6 is up!
Changelog
updated to r4.6 LowMemoryKiller implementation - best so far!
Disabled HighMem
removed some CPUfreq steps *
Dynamic governor: parameters are tuned for the better performance (credits: @ace2nutzer)
Added performance profiles (the corresponding parameters can be found in /ramdisk/perf.profiles.rc)
Other updates from r4.6 (various updates from LK 3.4, tweaks etc)
* Avalable CPU frequency steps are: 200, 800, 1000, 1100, 1200, 1215 Mhz. I've decided just to give it a try - this is a necessary part of tuning the CPU governor. If anyone doesn't like that frequencies between 200 and 800 MHz were removed I can add them back, but until performance-related issues are not resolved I'd suggest just leave as it is.
ChronoMonochrome said:
Changelog
updated to r4.6 LowMemoryKiller implementation - best so far!
Disabled HighMem
removed some CPUfreq steps *
Dynamic governor: parameters are tuned for the better performance (credits: @ace2nutzer)
Added performance profiles (the corresponding parameters can be found in /ramdisk/perf.profiles.rc)
Other updates from r4.6 (various updates from LK 3.4, tweaks etc)
* Avalable CPU frequency steps are: 200, 800, 1000, 1100, 1200, 1215 Mhz. I've decided just to give it a try - this is a necessary part of tuning the CPU governor. If anyone doesn't like that frequencies between 200 and 800 MHz were removed I can add them back, but until performance-related issues are not resolved I'd suggest just leave as it is.
Click to expand...
Click to collapse
Tested on Lineage Os 11 without CCleaner.
After flashing this new kernel I had to force a Media scan with Fx File Explorer (that detected over 300 changed files) because the phone was really slow. That was sufficient to speed up the multitasking that now it's much better than previous 4.1 build.
Additional observations:
- Do you think it's possible to improve Media scanner reactivity via kernel?
- Fx File Explorer detects my external sd card as Main storage and Media card as internal storage. This doesn't happen on Epirex kernel.
- Battery usage is higher than previous kernel. If I stay on a webpage in idle, after 30 seconds my battery decreases of one percentage point (i.e. from 70% to 69%). I noticed that a simple swipe on the screen jumps the current clock directly to the maximum frequency, this could be one of the reasons.
- There is only FIOPS as I/O Scheduler and I miss all the other schedulers.
I think you're on the right track!
isaak said:
- Do you think it's possible to improve Media scanner reactivity via kernel?
Click to expand...
Click to collapse
I don't think it's possible. The only possible way is to overclock CPU, though it won't help much.
- Fx File Explorer detects my external sd card as Main storage and Media card as internal storage. This doesn't happen on Epirex kernel.
Click to expand...
Click to collapse
This is a default behaviour in Chrono Kernel. Because on codina we have only 4 Gb of available space, it makes sense just to remove internal storage partition and use the external one as primary. If anyone wants, I can revert this behavior. It's possible to switch storages back by editing file /ramdisk/fstab_specs.txt (set use_swap value to 0) and flashing a kernel package.
- Battery usage is higher than previous kernel. If I stay on a webpage in idle, after 30 seconds my battery decreases of one percentage point (i.e. from 70% to 69%). I noticed that a simple swipe on the screen jumps the current clock directly to the maximum frequency, this could be one of the reasons.
Click to expand...
Click to collapse
Ok, I'll consider of tuning CPU governor in order to provide more battery friendly setup. I was afraid that the battery usage might be too high, but that was a necessary evil, I guess. In the meantime, as a temporary workaround, the maximum CPU frequency can even be lowered to 800 MHz, it should be still fast enough.
- There is only FIOPS as I/O Scheduler and I miss all the other schedulers.
I think you're on the right track!
Click to expand...
Click to collapse
To load more I/O schedulers, you can copy (or symlink) a module file to /system/lib/modules/autoload, then reboot the phone. This doesn't seem to work, a script that loads modules, is broken.
Because usually I don't change I/O scheduler, by default, no more I/O scheds are loaded. Do you have any preferred I/O scheds?
ChronoMonochrome said:
I don't think it's possible. The only possible way is to overclock CPU, though it won't help much.
Click to expand...
Click to collapse
Nevermind.
ChronoMonochrome said:
This is a default behaviour in Chrono Kernel. Because on codina we have only 4 Gb of available space, it makes sense just to remove internal storage partition and use the external one as primary. If anyone wants, I can revert this behavior. It's possible to switch storages back by editing file /ramdisk/fstab_specs.txt (set use_swap value to 0) and flashing a kernel package.
Click to expand...
Click to collapse
I'd like to revert the behavior, so I would appreciate If you could provide the same instructions here and in the other kernel thread..
ChronoMonochrome said:
To load more I/O schedulers, you can copy (or symlink) a module file to /system/lib/modules/autoload, then reboot the phone. This doesn't seem to work, a script that loads modules, is broken.
Because usually I don't change I/O scheduler, by default, no more I/O scheds are loaded. Do you have any preferred I/O scheds?
Click to expand...
Click to collapse
I would suggest deadline, noop, sioplus, zen (plus the existent FIOPS).
ChronoMonochrome said:
This is a default behaviour in Chrono Kernel. Because on codina we have only 4 Gb of available space, it makes sense just to remove internal storage partition and use the external one as primary. If anyone wants, I can revert this behavior. It's possible to switch storages back by editing file /ramdisk/fstab_specs.txt (set use_swap value to 0) and flashing a kernel package.
To load more I/O schedulers, you can copy (or symlink) a module file to /system/lib/modules/autoload, then reboot the phone. This doesn't seem to work, a script that loads modules, is broken.
Because usually I don't change I/O scheduler, by default, no more I/O scheds are loaded. Do you have any preferred I/O scheds?
Click to expand...
Click to collapse
Personally I really appreciate and find useful the external sdcard storage as primary one, should be the default behaviour for me, it makes sense and also I never liked to have some files on one unit and some files on another one (download, pictures, recordings on extsdcard, apps folders, screens, other apps downloads etc on internal), I really like the idea of sdcard as main, like the old times of galaxy mini
Fiops to me is a fair good scheduler, maybe also noop would be useful, but I guess having as much things as modules as possible can help load only the strictly necessary, but I say this without dev knowledge.
I will test this build and especially the deepsleep issues, to see if there are apps causing phone not to sleep, the problem is I didn't add any app, just using the same enviroment that with cocore was going to deepsleep. I will report soon, anyway, good job chrono, keep it up
Pdevo said:
Fiops to me is a fair good scheduler, maybe also noop would be useful, but I guess having as much things as modules as possible can help load only the strictly necessary, but I say this without dev knowledge.
Click to expand...
Click to collapse
Yes, FIOPS is good. I just think that having 2 or 3 additional schedulers to select would be better for different uses.
In my previous post I replaced sioplus with zen, according to the conclusions of this guide. There is an useful (up to date) list of recommended IO schedulers, ordered for everyday usage, battery life, heavy multitasking, etc.
New build r4.6.1 is up!
Hey guys and sorry for having to wait that long for a new releases!
I'm still working on 3.4.x kernel - no great news here, but at least I've found a more less stable sources base, so the only what needed now, is a time to bring up some stability fixes and feature changes.
For now releasing a 3.0.101 kernel with some minor changes:
R4.6.1
fixed CPU OC instabilities
LCDCLK is adjusted to fix tearing issues *
adjusted Dynamic CPU governor tunables for a better battery live
adjusted PowerHAL profiles **
genfstab: storages swap is disabled by default (remove /ramdisk/fstab_specs.txt before flashing to take this change in an effect)
updated temporary kernel zip
* tested with apps like Impossible Game, a display tearings are mostly resolved here. Apps like Youtube, though, might still causing tearings when playing video.
** the minimum CPU freq is set to 400 MHz. I've decided to use it as a default since 200 and 400 MHz CPUfreq steps are anyway using the same voltage, so unless you're undervolting the CPU, there won't be any significant difference in a battery drain.
ChronoMonochrome said:
** the minimum CPU freq is set to 400 MHz. I've decided to use it as a default since 200 and 400 MHz CPUfreq steps are anyway using the same voltage
Click to expand...
Click to collapse
On Lineage OS 11:
Using more accurately the Performance function in Lineage Os Settings (an example here), there are different bugs:
1) Minimum CPU freq here is still set at 200 MHz after I flashed chrono kernel 4.6.1.. but this time I forgot to flash the temporary kernel before your kernel.
Anyway chrono kernel 4.6.1 was flashed without issue using TWRP 2.8.7.0.
2) Maximum CPU freq is automatically restored at 1000 Mhz after any reboot, even if I set 1200 Mhz (with any governor).
3) Deadline scheduler is automatically set after any reboot, even if I set FIOPS as default scheduler.
4) Dynamic governor is automatically set after any reboot, even if I set Zenx as default governor.
5) On the Performance UI, performance profile results automatically set on Balanced after any reboot, even if I set Power save as default (it may be reproducible with "Performance" option too, I didn't check).
UPDATE: I've reinstalled chrono kernel again and these behaviors still happen.
For me the minimum freq was correctly 400 mhz as expected, as always running on stock 4.1.2.
After two days of use I can say you are following the right path.
This time I wanted to remove every possible source of doubts and I went for a clean installation, so doing a complete reset and flashing your kernel, of course after the temporary one. I still have the phone not going to deepsleep and the call issues (basically it is impossible to do and receive phone calls on stock rom).
A part from these I can say I didn't noticed any other issue at all, finding memory management a little improved compared to previous release and battery life still good, considering the phone isn't going to sleep mode.
I think this will continue to improve and soon all these glitches will just be gone away, thank you so much chrono also hoping to settle for a bit on your ultimateROM, only waiting for the vibration working, because that is basically the only notification for me
isaak said:
On Lineage OS 11:
Using more accurately the Performance function in Lineage Os Settings (an example here), there are different bugs:
1) Minimum CPU freq here is still set at 200 MHz after I flashed chrono kernel 4.6.1.. but this time I forgot to flash the temporary kernel before your kernel.
Anyway chrono kernel 4.6.1 was flashed without issue using TWRP 2.8.7.0.
2) Maximum CPU freq is automatically restored at 1000 Mhz after any reboot, even if I set 1200 Mhz (with any governor).
3) Deadline scheduler is automatically set after any reboot, even if I set FIOPS as default scheduler.
4) Dynamic governor is automatically set after any reboot, even if I set Zenx as default governor.
5) On the Performance UI, performance profile results automatically set on Balanced after any reboot, even if I set Power save as default (it may be reproducible with "Performance" option too, I didn't check).
UPDATE: I've reinstalled chrono kernel again and these behaviors still happen.
Click to expand...
Click to collapse
1) Isn't an issue here, the showed CPU frequency is 200 MHz, but the actual CPU pll clock set at 400 MHz. Might be confusing, but yet that is better for a battery life.
2) These aren't really bugs, it's how LOS 11.0 performance profiles works. To change min / max CPU freq, you either need to edit /ramdisk/perf.profiles.rc (and set a custom values) or disable perf profiles. Actually there is one more way - to remove CPUfreq adjusting lines completely from that script - would anyone like this change introduced in a new release?
3-4) I've checked it right now - no issues for me... Have you set "apply on boot" checkbox?
5) It's a known bug of CM11 perf profiles. AFAIK, @ace2nutzer fixed this bug in his CM11 builds. @ace2nutzer, can you please remind how this could be worked around?
ChronoMonochrome said:
2) Maximum CPU freq is automatically restored at 1000 Mhz after any reboot, even if I set 1200 Mhz (with any governor).
Click to expand...
Click to collapse
2) These aren't really bugs, it's how LOS 11.0 performance profiles works. To change min / max CPU freq, you either need to edit /ramdisk/perf.profiles.rc (and set a custom values) or disable perf profiles. Actually there is one more way - to remove CPUfreq adjusting lines completely from that script - would anyone like this change introduced in a new release?
Click to expand...
Click to collapse
Honestly I don't know how to disable perf profiles. If it's a simple thing to do (like a command or two to execute), please tell me how to do it because it's enough for me, otherwise I'd like to try the third way and see.
ChronoMonochrome said:
3) Deadline scheduler is automatically set after any reboot, even if I set FIOPS as default scheduler.
4) Dynamic governor is automatically set after any reboot, even if I set Zenx as default governor.
Click to expand...
Click to collapse
3-4) I've checked it right now - no issues for me... Have you set "apply on boot" checkbox?
Click to expand...
Click to collapse
Yes, "Set on boot" options are correctly set for both Processor and I/O Scheduler.
And I keep "Enable per-app profiles" option turned off.
@ChronoMonochrome
UPDATE 1: It occurs only randomly and with particular combinations. The best way to reproduce is to set these, one at a time:
1) Zenx as governor, min. 200 max 800, Noops scheduler. Reboot.
2) Zenx as governor, min. 200 max 800, Fiops scheduler. Reboot.
2) Zenx as governor, min. 200 max 800, Sioplus scheduler. Reboot.
After the first, the second or the third reboot, some of these values you've set will change spontaneously on their own.
UPDATE 2: I've got a screen flicker issue while I was browsing in Naked Browser with the new LCDCLK frequency.
Tried to set echo 1 > /sys/kernel/mcde/lcdclk, it's ok now, but I've noticed that this value is not kept after a reboot.
Do you need a specific log?
In case please write me any command and I'll give you the output.
isaak said:
On Lineage OS 11:
Using more accurately the Performance function in Lineage Os Settings (an example here), there are different bugs: .....
Click to expand...
Click to collapse
I suggest to keep it unchecked, otherwise it'll change the profile randomly, and that's probably not what u want.
ChronoMonochrome said:
....
5) It's a known bug of CM11 perf profiles. AFAIK, @ace2nutzer fixed this bug in his CM11 builds. @ace2nutzer, can you please remind how this could be worked around?
Click to expand...
Click to collapse
There's still no fix ! But what i did is to add the perf. profile in my control app ... that works fully independently.
But that's probably not what u guys want.
My last try was to do that over build.prop .. this works only for around 15 seconds (after wiping dalvik cache it's around 30 sec.) and then it sets back to "balanced" .. so i use it anyway just for speeding up the boot sequence:
Code:
# CM Performance Profiles (only during boot)
# 0= powersave; 1= balanced; 2= performance - default
sys.perf.profile=2
IMO the best way is to add the perf. profiles button to the quick settings, then it's very easy to switch between the 3 profiles.
Using the same profile for everything is for sure not the best option if u want performance + powersave at the same time.
Personally i use performance, and when i read an pdf or watch a YouTube Video then i switch to powersave.
Using powersave or even balanced for normal usage isn't recommended as it can drain even more battery than using performance, because it's slower and the CPU will stay too long on max. freq and the LCD also will stay longer ON, which leads both to increase power consumption.
So the faster the cpu is, the quicker it'll go on idle (min cpu 200) which is powersaving freq and the faster u'll turn OFF the screen, and logical bigger time on suspend --> deep sleep :highfive:
ace2nutzer said:
I suggest to keep it unchecked, otherwise it'll change the profile randomly, and that's probably not what u want.
There's still no fix ! But what i did is to add the perf. profile in my control app ... that works fully independently.
But that's probably not what u guys want.
My last try was to do that over build.prop .. this works only for around 15 seconds (after wiping dalvik cache it's around 30 sec.) and then it sets back to "balanced" .. so i use it anyway just for speeding up the boot sequence:
Code:
# CM Performance Profiles (only during boot)
# 0= powersave; 1= balanced; 2= performance - default
sys.perf.profile=2
IMO the best way is to add the perf. profiles button to the quick settings, then it's very easy to switch between the 3 profiles.
Using the same profile for everything is for sure not the best option if u want performance + powersave at the same time.
Personally i use performance, and when i read an pdf or watch a YouTube Video then i switch to powersave.
Using powersave or even balanced for normal usage isn't recommended as it can drain even more battery than using performance, because it's slower and the CPU will stay too long on max. freq and the LCD also will stay longer ON, which leads both to increase power consumption.
So the faster the cpu is, the quicker it'll go on idle (min cpu 200) which is powersaving freq and the faster u'll turn OFF the screen, and logical bigger time on suspend --> deep sleep :highfive:
Click to expand...
Click to collapse
Sorry for so late response, I had to take a break in a development because suddenly got sick with a flu (I'm fine now, btw) :silly:
I think I've found a temporary solution to this bug, take a look if you're interested:
https://github.com/ChronoMonochrome...mmit/bd0dcce403633543f1bf11e5f8b476a3e88322cb
New build is up!
Changelog
R4.6.2
rebased to CM14.1 branch (added support for 6.0.1 and 7.1.2 ROMs) *
Hey there! I've been testing 6.0.1 / 7.1.2 ROMs and I've recently got some issues with camera on 3.4.x kernel build, so I've decided to release a new refresh build (based on 3.0.101 sources).
I've rebased the most of recent changes to CM14.1 branch in order to support these ROMs (so if you're using older ROMs like stock 4.1.2 then better to use previous release cause some patches might be missing here).