Related
These kernels should work on every stock ICS LG rom or custom rom based on LG ICS rom.
Civato kernels build with V30B LG source & compiled on google 4.4.3 toolchain.
Thanks to :
WKPARK patchesRamHack and first OC patch
Also want to thank pengus77 , ezterry, godmachine81 , Thor2002ro, Faux123,chad0989 , Pidozz
NOTE:
I'm not a DEV and not pretending to be one, I'm a android enthusiast.
I would like to thank all XDA members that are helpful.
I build and mod stuff for my personal needs and then I share them.
Do I want something in return? NO.
You don't like it, no problem, there are enough good DEV's with there kernel to help you along.
So on request I started a separate thread for this kernel , it started with my rom and the need for a good custom kernel.
Click to expand...
Click to collapse
I don't provide any guarantee or a lawer if your phone explode and you get accused and charged for a terrorist act.
To be clear , the kernel got the POSSIBILITY to OC and tweak , if you don't do anything it runs at stock settings.
Meaning = MAX speed 1000MHz , Noop scheduler , interactive governor= LG default settings.
CivZ_SkyWalker_RF2.5rm
SU660 version of this kernel is available here
Sithlord in 3 different versions.
Ramhack or no ramhack
usb FastCharge
Compiled with Optimized flags-O3/-O2
-OC up to 1.5GHz , UV/OV , default boot up speed is 1.0GHz
-Minimum UV 650mV , Maximum OV 1400mV
Best CPU control app when you want to UV is free for XDA members SETCPU , download 2.24 or buy it, SUPPORT the devs! (it allows you to type in voltage changes and not only slide), Remember only steps of 10mV are real values , if you apply a step of 25mV it will actually be 20mV. So use setcpu to type in voltage steps of 10mV , 20mV , 30mV, ...............
-GPU 3D & 2D ( scales from 300 - 425MHz)
(stock is 300)
-Terminal kernel control commands
(Led light , FSYNC control , ZRam , Modules, SWAP increase)
-USB FastCharge (disabled at default)
-Available RamHack :No ramhack /24mb / 32mb
- Extra zRam 96Mb(disabled by default)
-Governors:
Powersaver
PERFORMANCE
USERSPACE
ONDEMAND
INTERACTIVE in dynamic mode (default)
CONSERVATIVE
LulzActive
(LulzActive tegrak tweak app included)
LionHeart
-Shedulers
NOOP(default)
DEADLINE
CFQ
SIO
ROW
BFQ-v5
Zen
VR
-Led control thanks to pengus77 (Max at default)
-Dynamic FSYNC @ Faux123 & Pengus77 (Disabled at default)
-Extra Modules loadable/unloadable on the fly
-Voltages / Frequencies:
NO 5mV steps as they are not supported by the LG regulator (Thanks Pengus77 for the heads-up)
750mV(216MHz) ; 780mV(312MHz) ; 800mV(456MHz) ; 850mV(608MHz) ; 900mV(760MHz); 920mV(816MHz) ; 950mV(912MHz) ; 1000mV(1000MHz boot up speed) ; 1050mV(1100MHz) 1100mV( 1200MHz); 1150mV(1300MHz); 1200mV(1408MHz) ; 1300mV(1504MHz)
Kernel control options to use with Terminal: (Settings are applied immediately and stick even after reboot now)
For a list of the commands on your phone (in case you forgot)
Type in terminal
su(enter)civz(enter)
Dynamic FSYNC control: (disabled by default)
Terminal command:
su (enter) df_on (enter) = This will enable Dynamic FSYNC (setting are applied immediately and sticks after reboot)
su (enter) df_off (enter) = This will disable Dynamic FSYNC (setting are applied immediately and sticks after reboot)
Led Brightness control: (Maximum brightness by default)
Terminal command:
su (enter) ledmin (enter) = This will set led at minimum brightness (setting are applied immediately and sticks after reboot)
su (enter) ledmed (enter) = This will set led at medium brightness (setting are applied immediately and sticks after reboot)
su (enter) ledmax (enter) = This will set led at maximum brightness (setting are applied immediately and sticks after reboot)
Load/unload Extra Modules : (Modules are unloaded by default)
(Cifs; hfs; hfs+; md4; nls_utf8; sha256; sha512)
Terminal command:
su (enter) m_load (enter) = This will load the extra modules (setting are applied immediately and sticks after reboot)
su (enter) m_unload (enter) = This will unload the extra modules (setting are applied immediately and sticks after reboot)
Enable/Disable EXTRA ZRam96MB: (Disabled by default)
Terminal command:
su (enter) zram_on (enter) = This will enable ZRam96MB (Reboot is needed to apply changes and sticks after reboot)
su (enter) zram_off (enter) = This will disable ZRam96MB (Reboot is needed to apply changes and sticks after reboot)
Enable/Disable LG 131MB SWAP or 260MB SWAP: (131MB is LG default)
Terminal command:
su (enter) lg_swap_of (enter) = This will disable LG swap (Reboot is needed to apply changes and sticks after reboot)
su (enter) lg_swap130_on (enter) = This will enable LG 130MB swap (Reboot is needed to apply changes and sticks after reboot)
su(enter)lg_swap260_on(enter) = This will enable LG 260MB swap (Reboot is needed to apply changes and sticks after reboot)
Note on LG swap: The 131Mb is default of LG
LG got this enabled in the stock LG rom and it uses the dev/block/mmcblk0p4 (unused partition) for it so not the same as ZRam that uses /dev/block/zram0 file. The LG Swap partition is enabled by default , I just add this command so if a user don't want to use the LG swap it can be done now with a single command.
Change system swappines value: (Android default is 60)
(setting are applied immediately and sticks after reboot)
Terminal command:
su(enter)swappines_0(enter) = set swappines at 0 = system waits very long to swap , Kills tasks very quick
su(enter)swappines_20(enter) = set swappines at 20 = Performance setting for gaming
su(enter)swappines_40(enter) = set swappines at 40 = Performance setting and some multitasking
su(enter)swappines_60(enter) = set swappines at 60 = Androids default , balanced setting
su(enter)swappines_80(enter) = set swappines at 80 = Aimed for multitasking/Balanced
su(enter)swappines_100(enter) = set swappines at 100 = Aimed for extreme multitasking , NOT GAMING
Update GPS lto
(this is done automatically with a init.d script , so in case it failed, here a way to do this manually)
Terminal command:
su (enter) gps_update (enter) = This will update gps lto file , if the file is not older then 5 days it won' t update.
Change system Fatsdormancy setting:
(setting are applied immediately and sticks after reboot)
Terminal command:
su(enter)fastdormancy_on(enter)=enable Fastdormancy = android default
su(enter)fastdormancy_off(enter)=disable Fastdormancy
Note about fastcharge option in kernel:
It is OFF at default, user needs to enable it.
Use at own risk, it is meant to use on car/plain chargers, don't know the effect in the long term.
And I don't know the effect when ussed on a PC usb connection.
The "FastCharge" app from playstore is installed in data, use it to toggle ON/OFF.
Or use the following terminal commands:
To enable it = echo 1 > /sys/kernel/fast_charge/force_fast_charge
To disable it= echo 0 > /sys/kernel/fast_charge/force_fast_charge
If you use fastcharge on a pc, usb will not be mounted and no data can be received or send.
Based on the work of chad0989 , Pidozz and Pengus77.
Click to expand...
Click to collapse
Click to expand...
Click to collapse
LG-P990-VERSIONS
CivZ_SkyWalker_RF2.5rm
CivZ_SkyWalker_RF2.5rm_24RH
CivZ_SkyWalker_RF2.5rm_32RH
SU660-VERSIONS of this kernel is available here
Side note on USB BSOD (screen off and pluging in usb resulting in BSOD)
I noticed that with enabled Dynamic FSYNC or a to high OC it can still occur.
So in that case please turn on screen before plugging in USB.
Click to expand...
Click to collapse
Changelog:
New in RF1.3-Cleaned out the kernel source
-Powersaver governor activated
-Optimized deadline scheduler
-Nvidia USB plugin BSOD fix
New in RF1.4:
-Added BFQ-v5r1 scheduler
@ iBluemind
(More info see Q&A)
-More versions.
New in RF1.5:
-Fix for governor switching
(coming from hotplug to a other governor made one core stuck in sleep state , resulting in bad performance and instability).
-3 New governors: "Aggressive" , "Gallimaufry", "Sakuractive".
-Most governors optimized.
(reverted BFQ to V5 version, performance is smoother I think)
-New "Zen" scheduler and most schedulers optimized
-Reduced android logger time.
-Increased readahead (1024kb instead of the default 128kb)
-Included mmc_cap hard brick fix. (Don't know if it is needed on this phone but can't hurt, a lot of samsung phones died this way when wiping data in recovery)
-Controle led brightness
ledmin ; ledmed; ledmax
NEW RF1.5_FC edition
Added USB Fast Charge in this edition.
8-Feb-2013:
RF1.6:
-Only compiled on -03 CF flags and with FastCharge option.
-GPU 3D clock up to 400MHz
(Before it was 350 where stock is 300)
-Patch for EXt4 error.
-CPU Freq lock off
-Reverted deadline scheduler
-Ramdisk got back the old settings for better battery life when not OC'd.
-216 and 312 MHz default voltage dropped with 25mV.
-Ramp-up speed on interactive back to 80 , you can change this in setcpu.
10-Feb-2013
RF1.7:
-Max CPU OC is now 1.5GHz
-New Lower default Voltage table:
750mV(216MHz) ; 775mV(312MHz) ; 800mV(456MHz) ; 850mV(608MHz) ; 900mV(760MHz); 925mV(816MHz) ; 950mV(912MHz) ; 975mV(1000MHz) ; 1050mV(1100MHz) 1125mV( 1200MHz) ; 1150mV( 1248MHz) ;1200mV(1300MHz) 1250mV(1352MHz) ; 1275mV(1404MHz) ; 1300mV( 1456MHz) ; 1325mV(1500MHz)
-Voltage settings changed in tegra2_dvfs.c so the 1.5GHz is stable.
-GPU 2D clock OC'd up to 400MHz
(stock is 300)
-Secondary clock epp & mpe OC'd to 350MHz
(stock is 300)
-ARCH power enabled
12-Feb-2013:
RF1.8 released
Update for stability reason that some users experienced.
Thanks to all the testers and there feedback.
-2D & 3D clock decreased back to 350MHz OC
(this is the RF1.4 setting as this is the best for all users)
Performance gain is not enough to justified to OC to 400MHz.
The 400MHz version will not be released public as it is not good for most users, please don't ask for it.
-Secondary mpe clock back to stock for the stability reason.
-RATE_LIMIT of 3D back to stock for the stability reason.
13-Feb-2013:
RF1.9
-Bug fix for Reboot /shutdown freeze when OC'd.
-Voltage table updated.
-Lower voltage for 1500 and 1456 MHz
Minimum UV voltage is now 675mV
-3D GPU 400MHz OC.
16-Feb-2013:
RX2.0
New Voltage table for higher stability.
New CPU max speed 1.544GHz.
New GPU 2D clock of 400MHz.
New terminal kernel commands.
Compiled with new flags (-O2 with some parts of -O3 flags to reduce code size).
Updated voltage table to gain stability when OC'd.
Dynamic FSYNC @ Faux123 integrated (Disabled at default)
Kernell-HZ increased to 256HZ (stock is 100) for better performance and smoothness.
User HZ increased to 200HZ (stock is 100) for smoothness
Support for NTFS
Support for NFS 3/4
HFS & HFS+ as modules
CIFS as module
md4 as module
sha512 as module
utf8 as module.
16-Feb-2013:
RX2.0_b released
Fix for the terminal commands error.
21-Feb-2013:
RX2.1 Released
Reverted User and Kenrel HZ to stock for stability.
Reverted back to -O3 custom flags
New terminal commands for ZRam and Extra modules
USB OTG (on the go) enabled (testing)
22-Feb-2013:
RX2.2 released:
Changed some custom flags for decrease of code size.
Reverted OTG setting (not working and causing problems)
Shed_Features back to stock setting (causing USB pluggin BSOD)
New Terminal command 'civz"
I hope this is a 100% rock solid stable version and I'm truly sorry for the many releases the last few days.
I wish to bring a stable kernel so some features are reverted as wow factor is not what I look for.01-Mar-2013:
CivZ_SithLord_再见 released
Main goal 100% stable kernel with good battery life, that is why the following changes are applied:
Forced governor linked patch (Make sure both cpu's run at the same governor, even with "setcpu & antutu") thanks Ezterry.
Max OC 1500MHz with lower voltage table (see in kernel info) , this to reduce battery consumption.
Removed a bunch of governors as they caused problems in some situations (so it seemed), see kernel ifo for what is included.
LulzActive Governor (with app) , tweaked by me to be less aggressive.
02-Mar-2013:
CivZ_SithLord_再见_r2 released
Reverted voltage table to RX2.2 release as some users had problems on max OC with lower rail voltages.
I can UV with -50mV on all frequencies but that is all up to the quality of your tegra2 cpu.07-Mar-2013:
CivZ_SkyWalker_RF1.0 released
New name because the OC code totaly changed compared to SithLord.
Totally new OC code with new frequencies and very low default voltages.(Thanks to my friend ezterry)
Max = Min frequency really fixed (now it won't be stuck at 750MHz when setting max frequency below 760MHz and not just showing the value but actually applying it so now you can set screen-off max at example: 312MHz in a profile with a cpu app).
Dynamic MODE enable on the interactive governor.
Min Max cpu frequency code changed and editable in defconfig before compiling kernel(Thanks to my friend ezterry)
Compiling optimizations flags changed (again thanks to my friend ezterry)
LulzActive governor balanced settings with max screen-off frequency of 608MHz
I would like to thank all the beta testers and I hope the result is up to your expectations!
08-Mar-2013:
CivZ_SkyWalker_RF1.1 released
More aggressive lulzactive governor settings on user request
New terminal command for LG 131MB swap
New terminal command for manual updating GPS lto file
Also a SU660 version available
96ZRam disabled by default from now on (not needed in my opinion, swap already got 131Mb on unused partition, but it is still available as a option)
10-Mar-2013:
CivZ_SkyWalker_RF1.2 released
New Max OC speed of 1544MHz
2D GPU back to 400MHz OC
OC code updated
New Terminal command to increase LG SWAP to 260MB
Updated FSYNC with latest Pengus77 release
Enabled ARCH-Power
SU660 24RH version available
"civz" terminal command updated with latest commands
13-Mar-2013:
CivZ_SkyWalker_RF2.0 released
Reverted MAX OC to 1504MHz (this way I could drop rail voltages so it will stay cooler, settings of RF1.0)
New Voltage table (no 5mV steps as pengus77 mentioned the regulator doesn't except 5mV steps)
Real min voltage is now 650mV (again thanks for pengus77 pointing me this out that board power and regulator had to be modded)Best CPU control app when you want to UV is free for XDA members SETCPU , download 2.24 or buy it, SUPPORT the devs! (it allows you to type in voltage changes and not only slide), Remember only steps of 10mV are real values , if you apply a step of 25mV it will actually be 20mV. So use setcpu to type in voltage steps of 10mV , 20mV , 30mV, ..
New Governor , LionHeart , tweaked by me to be very battery friendly.
GPU 2 D & 3D scales from 300 - 450MAX . What does this mean: When you play a stressfull game it will go up to Max 450MHz if it can depending on = It scales with voltage and process ID , lower voltage/ lower stress/ lower CPU speed = lower GPU speed. I hope this is the best solution for all users and best for battery/performance.
FastCharge updated to pengus77 edition.
Kernel Panic Timeout increased to 10 so a automatic reboot can be prevented when running out of memory on multitasking.
SU660 gets all versions.
FOR RF2.0 I would like to thank Pengus77 for his contribution on the voltage control and the updates of FSYNC and FastCharge.
I would also like to thank my good friend ezterry and godmachine81 for the OC code and GPU code.
Next I thank all my beta testers for the info and stressing there phone.
14-Mar-2013:
CivZ_SkyWalker_RF2.0-b released
New terminal commands to control the swappines
LG terminal command name change !!!
civz command updated
The rest of the kernel is 100% the same!
23-Mar-2013:
CivZ_SkyWalker_RF2.2-b released
New secondary , GPU frequency table.
3D Clock scales max to 425MHz.
2D clock scales up to 400MHz max (only when needed in heavy load)
USB connection delay patch
Fastdormancy terminal command
29-Mar-2013:
CivZ_SkyWalker_RF2.3rm released
gspca_main.ko module moved to optional modules
Stripped of all debugging = Lighter and optimized code
Fixed some code errors while compiling
06-Jul-2013:
CivZ_SkyWalker_RF2.5rm released
SetCPU 3.1.0 and higher reverted voltage fixed so on older versions of setCPU this kernel won't report correctly.
Note on LG SWAP increase:
Remember that on stock LG rom the default LG swap is 131MB. If you change kernel that doesn't got this terminal option and you changed the swap size or disabled it , no problem the swap commands are installed in system/bin so if you didn't delete them you can always use it. This does not count for other terminal command that come with the kernel.
Side note on USB BSOD
It is very random and still not 100% solved.
I noticed that with enabled Dynamic FSYNC or a to high OC it can still occur.
Just turn on your screen before connecting to pc and safe yourself a battery pull.
Click to expand...
Click to collapse
Side note:
Kernels comes as a boot.img = ramdisk with zImage.
Reason is that I made some changes in ramdisk. , init.d support.......
The meaning of this kernel is if you don't OC you get supurb battery life and 100% stability. If you start changing default governors and schedulers it will and can have a effect on battery life and OC to much with to much UV it will get unstable.
I recommend 1.2-1.3GHz for 24/7 use and not more. Governors can have a great effect on battery life. The flexibility in the kernel is there for the user to pick his/her favorite setting.
Source see second post!
More info about Sithlord and the effect of RamHack and Zram
INFO:
Thanks to jee'sgalaxy for the explanation
These Governors are included
1: OnDemand Governor:
This governor has a hair trigger for boosting clockspeed to the maximum speed set by the user. If the CPU load placed by the user abates, the OnDemand governor will slowly step back down through the kernel's frequency steppings until it settles at the lowest possible frequency, or the user executes another task to demand a ramp.
OnDemand has excellent interface fluidity because of its high-frequency bias, but it can also have a relatively negative effect on battery life versus other governors. OnDemand is commonly chosen by smartphone manufacturers because it is well-tested, reliable, and virtually guarantees the smoothest possible performance for the phone. This is so because users are vastly more likely to ***** about performance than they are the few hours of extra battery life another governor could have granted them.
This final fact is important to know before you read about the Interactive governor: OnDemand scales its clockspeed in a work queue context. In other words, once the task that triggered the clockspeed ramp is finished, OnDemand will attempt to move the clockspeed back to minimum. If the user executes another task that triggers OnDemand's ramp, the clockspeed will bounce from minimum to maximum. This can happen especially frequently if the user is multi-tasking. This, too, has negative implications for battery life.
2: Performance Governor:
This locks the phone's CPU at maximum frequency. While this may sound like an ugly idea, there is growing evidence to suggest that running a phone at its maximum frequency at all times will allow a faster race-to-idle. Race-to-idle is the process by which a phone completes a given task, such as syncing email, and returns the CPU to the extremely efficient low-power state. This still requires extensive testing, and a kernel that properly implements a given CPU's C-states (low power states).
3:Conservative Governor:
This biases the phone to prefer the lowest possible clockspeed as often as possible. In other words, a larger and more persistent load must be placed on the CPU before the conservative governor will be prompted to raise the CPU clockspeed. Depending on how the developer has implemented this governor, and the minimum clockspeed chosen by the user, the conservative governor can introduce choppy performance. On the other hand, it can be good for battery life.
The Conservative Governor is also frequently described as a "slow OnDemand," if that helps to give you a more complete picture of its functionality.
4: Userspace Governor:
This governor, exceptionally rare for the world of mobile devices, allows any program executed by the user to set the CPU's operating frequency. This governor is more common amongst servers or desktop PCs where an application (like a power profile app) needs privileges to set the CPU clockspeed.
5: Interactive Governor:
Much like the OnDemand governor, the Interactive governor dynamically scales CPU clockspeed in response to the workload placed on the CPU by the user. This is where the similarities end. Interactive is significantly more responsive than OnDemand, because it's faster at scaling to maximum frequency.
Unlike OnDemand, which you'll recall scales clockspeed in the context of a work queue, Interactive scales the clockspeed over the course of a timer set arbitrarily by the kernel developer. In other words, if an application demands a ramp to maximum clockspeed (by placing 100% load on the CPU), a user can execute another task before the governor starts reducing CPU frequency. This can eliminate the frequency bouncing discussed in the OnDemand section. Because of this timer, Interactive is also better prepared to utilize intermediate clockspeeds that fall between the minimum and maximum CPU frequencies. This is another pro-battery life benefit of Interactive.
However, because Interactive is permitted to spend more time at maximum frequency than OnDemand (for device performance reasons), the battery-saving benefits discussed above are effectively negated. Long story short, Interactive offers better performance than OnDemand (some say the best performance of any governor) and negligibly different battery life.
Interactive also makes the assumption that a user turning the screen on will shortly be followed by the user interacting with some application on their device. Because of this, screen on triggers a ramp to maximum clockspeed, followed by the timer behavior described above.
6: Powersave Governor:
The opposite of the Performance governor, the Powersave governor locks the CPU frequency at the lowest frequency set by the user.
7: LulzActive:
Highly tweakable governor @ tegrak, use the included app to tweak it.
Click to expand...
Click to collapse
Schedulers:
1: Noop:
Inserts all the incoming I/O requests to a First In First Out queue and implements request merging. Best used with storage devices that does not depend on mechanical movement to access data (yes, like our flash drives). Advantage here is that flash drives does not require reordering of multiple I/O requests unlike in normal hard drives.
Advantages:
Serves I/O requests with least number of cpu cycles. (Battery friendly?)
Best for flash drives since there is no seeking penalty.
Good throughput on db systems.
Disadvantages:
Reduction in number of cpu cycles used is proportional to drop in performance.
2: Deadline:
Goal is to minimize I/O latency or starvation of a request. The same is achieved by round robin policy to be fair among multiple I/O requests. Five queues are aggressively used to reorder incoming requests.
Advantages:
Nearly a real time scheduler.
Excels in reducing latency of any given single I/O.
Best scheduler for database access and queries.
Bandwidth requirement of a process - what percentage of CPU it needs, is easily calculated.
Like noop, a good scheduler for solid state/flash drives.
Disadvantages:
When system is overloaded, set of processes that may miss deadline is largely unpredictable.
3: CFQ:
Completely Fair Queuing scheduler maintains a scalable per-process I/O queue and attempts to distribute the available I/O bandwidth equally among all I/O requests. Each per-process queue contains synchronous requests from processes. Time slice allocated for each queue depends on the priority of the 'parent' process. V2 of CFQ has some fixes which solves process' i/o starvation and some small backward seeks in the hope of improving responsiveness.
Advantages:
Considered to deliver a balanced i/o performance.
Easiest to tune.
Excels on multiprocessor systems.
Best database system performance after deadline.
Disadvantages:
Some users report media scanning takes longest to complete using CFQ. This could be because of the property that since the bandwidth is equally distributed to all i/o operations during boot-up, media scanning is not given any special priority.
Jitter (worst-case-delay) exhibited can sometimes be high, because of the number of tasks competing for the disk.
5: SIO:
Simple I/O scheduler aims to keep minimum overhead to achieve low latency to serve I/O requests. No priority quesues concepts, but only basic merging. Sio is a mix between noop & deadline. No reordering or sorting of requests.
Advantages:
Simple, so reliable.
Minimized starvation of requests.
Disadvantages:
Slow random-read speeds on flash drives, compared to other schedulers.
Sequential-read speeds on flash drives also not so good.
6: V(R):
Unlike other schedulers, synchronous and asynchronous requests are not treated separately, instead a deadline is imposed for fairness. The next request to be served is based on it's distance from last request.
Advantages:
May be best for benchmarking because at the peak of it's 'form' VR performs best.
Disadvantages:
Performance fluctuation results in below-average performance at times.
Least reliable/most unstable.
7) BFQ:
Instead of time slices allocation by CFQ, BFQ assigns budgets. Disk is granted to an active process until it's budget (number of sectors) expires. BFQ assigns high budgets to non-read tasks. Budget assigned to a process varies over time as a function of it's behavior.
Advantages:
Believed to be very good for usb data transfer rate.
Believed to be the best scheduler for HD video recording and video streaming. (because of less jitter as compared to CFQ and others)
Considered an accurate i/o scheduler.
Achieves about 30% more throughput than CFQ on most workloads.
Disadvantages:
Not the best scheduler for benchmarking.
Higher budget assigned to a process can affect interactivity and increased latency.
Click to expand...
Click to collapse
Please share your settings, battery life, benchmark score.................................
My personal settings for a while now:
-SithLord_RF1.2_32RH_cf03
-1248MHz 24/7
-SavagedZen
-row
It is very snappy and battery friendly.
1248MHz SavagedZen / Row
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
1456MHz Performance / ROW
cannot be used on cm10 right?
Re: [KERNEL] CivZ SITHLORD Kernel - for LG ICS roms / New bootloader only
Where can I change CPU frequency?
Sent from my LG-P990 using xda app-developers app
Taking loads of kernel patches from other peoples Github and providing your kernel as a tarball is (most likely) fine by the rules, but still considered bad.
It doesn't take long to set up github, so I'd like to ask you kindly to give back to the community if you take from it.
Edit: Before anyone gets this the wrong way, read my clarification post below.
tonyp said:
Taking loads of kernel patches from other peoples Github and providing your kernel as a tarball is (most likely) fine by the rules, but still considered bad.
It doesn't take long to set up github, so I'd like to ask you kindly to give back to the community if you take from it. Especially as a Recognized Contributor.
Click to expand...
Click to collapse
Well i have to agree 100% with Tonyp on this one. Please setup a github and commit your work, keeping clear and polished references to the cherry-picks you make. GPL is quite clear on this: all modifications to the original source code must keep a reference to the author of the patch. Github is a fantastic way to keep in line with the gpl because it does it all by itself
Re: [KERNEL] CivZ SITHLORD Kernel - for LG ICS roms / New bootloader only
Thanks for doing this, and also making new tread for it. As an experienced noob I appreciate it.
Tony, you might be right, but rules are rules, and users love rules like this. Why? We're addicts of flashing he he......
Sent from my LT18i using xda premium
No.
---------- Post added at 11:20 PM ---------- Previous post was at 11:16 PM ----------
proyatzu said:
cannot be used on cm10 right?
Click to expand...
Click to collapse
No.
Re: [KERNEL] CivZ SITHLORD Kernel - for LG ICS roms / New bootloader only
louiscypherbr, you type from my mind
tonyp said:
Taking loads of kernel patches from other peoples Github and providing your kernel as a tarball is (most likely) fine by the rules, but still considered bad.
It doesn't take long to set up github, so I'd like to ask you kindly to give back to the community if you take from it. Especially as a Recognized Contributor.
Click to expand...
Click to collapse
pengus77 said:
Well i have to agree 100% with Tonyp on this one. Please setup a github and commit your work, keeping clear and polished references to the cherry-picks you make. GPL is quite clear on this: all modifications to the original source code must keep a reference to the author of the patch. Github is a fantastic way to keep in line with the gpl because it does it all by itself
Click to expand...
Click to collapse
Working on it so ....... like I mentioned I'm new to this linux world.
It got nothing to do with the RC title. It got to do with more important things in life then setting up github.
I will get there when I got time.
If this is bad , well sorry then.
No problem, I will ask admin to close thread and I will remove all links as y'all think I'm in violation of GPL and don't have the patience to let me learn how to setup a github properly.
Hmm, and like I never gave anything back to the community?
civato said:
No problem, I will ask admin to close thread and I will remove all links as y'all think I'm in violation of GPL and don't have the patience to let me learn how to setup a github properly.
Click to expand...
Click to collapse
Uhm, no no no, I don't think you're violating anything, don't get this in the wrong way.
I just wanted to encourage you to set up a Github account, as this will ensure that all other kernel developers will participate from your work as well.
Due to pengus77 github profile you were able to use his patches, if he wants to use something of your work it's quite hard for him to do so as he would have to extract that from your zip.
If you need help in setting it up or got questions about how to properly work with git feel free to PM me anytime.
@louiscypherbr: I'm not interested in pushing people away, I'm interested in ensuring everyone can take patches from others, as that will lead, ultimatively, to even better kernels.
So there's no place for your attitude and swearwords.
@louiscypherbr civato, tonyp, pengus77 etc know what to do. Nobody pushes away none.
tonyp made it clear that he has no intention to make civato stop developing his great kernel. It is common sense that github helps people share their ideas and experience for making and improving projects. It's not bad at all. I am very sure that Civato will push his code at github when he is ready.
Keep up guys and leave the code in peace!
Post not needed
Re: [KERNEL] CivZ SITHLORD Kernel - for LG ICS roms / New bootloader only
I think that those self imposed CENTURIONS, have the law in their hands and we all agree with the rules. But there is another gold rule that has to be used...TACT is like a velvet revolver that SOFTENS the blow of truth.
There was the case of the great integrator GUESTE, now CIVATO who is next?, carburano?, Jishur?.
We all agree with GPL, but most agree with the great work of this people, that make things for them and share!!....
CENTURIONS, if you are eagerly seeking for standards and good practices...A F.......G PERSONAL MESSAGE IS MANDATORY...
I don't see Linus Torvalds complain in nobody's threads....
Guys, we the people are the one that you affect the most...we are learning... but not only with your WORK, we learn from many people.
SO STOP GETTING OUT GOOD PEOPLE FROM XDA AND HAVE TACT AND PATIENCE...YOU WILL HAVE YOUR LINES OF CODE ON ITS TIME...
Sent from my LG-P990 using Tapatalk 2
galpec said:
I think that those self imposed CENTURIONS, have the law in their hands and we all agree with the rules. But there is another gold rule that has to be used...TACT is like a velvet revolver that SOFTENS the blow of truth.
There was the case of the great integrator GUESTE, now CIVATO, who is next?, carburano?, Jishur?.
We all agree with GPL, but most agree with the great work of this people, that make things for them and share!!....
CENTURIONS, if you are eagerly seeking for standards and good practices...A F.......G PERSONAL MESSAGE IS MANDATORY...
I don't see Linus Torvalds complain in nobodys threads....
Guys, we the people are the one that you affect the most...we are learning... but not only with your WORK, we learn from many people.
SO STOP GETTING OUT GOOD PEOPLE FRPM XDA AND HAVE TACT AND PATIENCE...YOU WILL HAVE YOUR LINES OF CODE ON ITS TIME...
Sent from my LG-P990 using Tapatalk 2
Click to expand...
Click to collapse
All good so far and i agree, but see, i'm one of those that you probably refer to as "centurions" and i feel a little weird about that (if not, it's ok, my misunderstanding). All my code is on github and ALL the devs are picking it up to improve their kernels. Well, devs is a big word apparently, most of the stuff around now is merely a collection of cherry picks in the end...
But anyway, because of this i was asking civato to push his code to github, to keep track of other people's code in his kernel and to allow other developers to pick his things. This is the spirit of open source and open development that i've been following for almost 20 years now so, please, don't tell me that i want people out of xda only because i asked for public source tracking. It's a normal and standard thing, nothing impossible or difficult, nothing that requires a degree in cs, and nothing that is out of the ordinary. It was a polite request, remembering how important is to adhere to the gpl rules (not xda ones, i wouldn't even dare such a comment) because i fully do and, probably because i'm used to this, i expect other kernel developers to do the same... just my 2 cents...
Edit: @civato don't consider this an attack or something against you please, it's not my intention at all. I just feel weird about tarballs and i usually forget to put my details in the code i write, so it gets lost in there Anyway i'll gladly help you in setting up your github if you pm me or add me on gtalk !
pengus77 said:
All good so far and i agree, but see, i'm one of those that you probably refer to as "centurions" and i feel a little weird about that. All my code is on github and ALL the devs are picking it up to improve their kernels. Well, devs is a big word apparently, most of the stuff around now is merely a collection of cherry picks in the end...
But anyway, because of this i was asking civato to push his code to github, to keep track of other people's code in his kernel and to allow other developers to pick his things. This is the spirit of open source and open development that i've been following for almost 20 years now so, please, don't tell me that i want people out of xda only because i asked for public source tracking. It's a normal and standard thing, nothing impossible or difficult, nothing that requires a degree in cs, and nothing that is out of the ordinary. It was a polite request, remembering how important is to adhere to the gpl rules (not xda ones, i wouldn't even dare such a comment) because i fully do and, probably because i'm used to this, i expect other kernel developers to do the same... just my 2 cents...
Click to expand...
Click to collapse
^ this. There was never an obligation in his post, he was just asking kindly to help the community by sharing his work in an appropriate way.
Re: [KERNEL] CivZ SITHLORD Kernel - for LG ICS roms / New bootloader only
@tonyp I think this is the kind of message you should use...for other occasions that need goalkeeping actions...
"If you need help in setting it up or got questions about how to properly work with git feel free to PM me anytime."
If somebody doesn't understand, a PM is mandatory but as this.
Suggested Personal Message:
"Due to great developers that have github profile, people were able to use their patches, there is the case of pengus77, that helped your great work. But if we want to use something of your great work it's quite hard for us to do so as we would have to extract that from your zip.
So please I encourage you to unite forces with us, and share with the same utilities like github."
@civato Don't go please we are learning just not downloading...
Best regards to all.
galpec
Sent from tapatalk app.
---------- Post added at 06:09 PM ---------- Previous post was at 06:05 PM ----------
First of all I think that @tonyp and you @pengus77 are a great giving, dev, geniuses, etc. examples. So nothing personal here at all . But we have to Use the rules not only in developing, also in best practices of communication such as tact...so:
@pengus77
@tonyp: I did't see nothing polite in starting helping somebody telling this as starting sentence:
"Taking loads of kernel patches from other peoples Github and providing your kernel as a tarball..."
In my last message it's a quite example of how to do this... not hitting and then say "no offense mate but...it's the law...." mmmmm
Best regards to all
galpec
Sent from my LG-P990 using Tapatalk 2
Ok, guys/gals(if any)
This thread has kind of taken a really bad turn right at the start. I've gone through and cleaned some of the off topic stuff,(left some in). How about we try this all over again and start from scratch from this point on.
Lets keep on topic now that we have a new start
Thanks!
Edit: Didn't see kangis post.
Let's get back on topic.
wawyed said:
^ this. There was never an obligation in his post, he was just asking kindly to help the community by sharing his work in an appropriate way.
Click to expand...
Click to collapse
This.
Hi Guys,
i thought it would be a good idea to put all the infos of the zzmoove governor around here together on one place
for better way to find it, to have a place to dump stuff for future versions and to give support for specific questions.
for now i just copied the allready existend posts here but will edit this further when i have more time
so lets start with the first
initial version:
ZZMoove Governor v0.1
(post from 18th December 2012, 10:27 PM)
Why that “zzmoove” governor and how it works:
I thought it were pretty cool to have one of my favorite governors back from the old SGS1-days on my actual device, so i decided to take the sources and give that a try on top of boeffla kernel. It worked well so this is now the result of that experiment.
More about the internals:
Basically this is the ported SGS1 version of the well known "smoove" governor from the good old midnight kernel from Michael Weingaertner (mialwe) with a modified CPU hotplug implementation of the ktoonservative governor from ktoonesz. The original implementation from ktoonesz worked well but I observed that on idle most of the time only one cpu was going to sleep. Well that was not enough for me so I made a modification to put the other cpu's also to sleep (except cpu0). That means that this governor uses more often only one cpu on idle and as a consequence of that it needs less energy. Depending on System load and governor settings all 4 cores will be instantly up again if it is needed.
In short:
So what you can expect now from this thingy is a battery-friendly behaving hotplug conservative governor which
uses a frequency lookup table for faster upscaling (so called "smooth scaling") So this is more a energy-safer than a performer.
Tuneables/Defaults:
Sampling Rate (default=2) tuneable: /sys/devices/system/cpu/cpufreq/zzmoove/sampling_rate
Sampling Down Factor (default=4) tuneable: /sys/devices/system/cpu/cpufreq/zzmoove/sampling_down_factor
Up Threshold (default=70) tuneable: /sys/devices/system/cpu/cpufreq/zzmoove/up_threshold
Up Threshold Hotplug (default=68) tuneable: /sys/devices/system/cpu/cpufreq/zzmoove/up_threshold_hotplug
Down Threshold (default=52) tuneable: /sys/devices/system/cpu/cpufreq/zzmoove/down_threshold
Down Threshold Hotplug (default=55) tuneable: /sys/devices/system/cpu/cpufreq/zzmoove/down_threshold_hotplug
Ignore Nice Load (default=0) tuneable: /sys/devices/system/cpu/cpufreq/zzmoove/ignore_nice_load
Freqency Step (default=5) tuneable: /sys/devices/system/cpu/cpufreq/zzmoove/freq_step
Smooth Up (default=75) tuneable: /sys/devices/system/cpu/cpufreq/zzmoove/smooth_up
Links:
Midnight kernel
KT747 Kernel
Common Infos about Governors,I/O Schedulers etc.
Credits to:
mialwe for his smoove governor
ktoonesz for original hotplug implementation
ZZMoove Governor v0.3
(Post from 25th February 2013, 05:06 PM - "more improvements")
there are now many new possibilities to adjust the governor more precisely via sysfs!
Following new tuneables were introduced in this new version:
The so called "sleep" values which were hardcoded in previous version are now changed
to sysfs-tuneables:
The Smooth Scaling for sleep (Screen off):
tuneable -> /sys/devices/system/cpu/cpufreq/zzmoove/smooth_up_sleep
possible values from 1 to 100, default: 100
The up/down Threshold for sleep (Screen off):
tuneable -> /sys/devices/system/cpu/cpufreq/zzmoove/up_threshold_sleep
possible Values from above "down_threshold_sleep" to 100, default: 90
tuneable -> /sys/devices/system/cpu/cpufreq/zzmoove/down_threshold_sleep
possible Values from 11 to under "up_threshold_sleep", default: 44
The Sampling Rate for sleep (Screen off):
tuneable -> /sys/devices/system/cpu/cpufreq/zzmoove/sampling_rate_sleep_multiplier
possible values 1 or 2, default: 2
The amound of cores which should run at "screen off":
tuneable -> /sys/devices/system/cpu/cpufreq/zzmoove/hotplug_sleep
possible Values 0 = do not touch cores (the same behaving as in standard setting of zzmoove) 1, 2 or 3
the number of cores to run on screen off. btw. setting "4" doesn't exist as u can use "0" for that setting!
Beside of that you can now change the hotplug threshold per core independently (thx to gsw5700 for the inital idea!)
and turn cores off completely.
For that purpose following tuneables were introduced and are replacing
the old hotplug up/down threshold tuneables:
tuneable -> /sys/devices/system/cpu/cpufreq/zzmoove/up_threshold_hotplug1
hotplug up threshold for core 1 - 0 = turn off core 1, possible range from "down_threshold" to 100, default: 68
tuneable -> /sys/devices/system/cpu/cpufreq/zzmoove/up_threshold_hotplug2
hotplug up threshold for core 2 - 0 = turn off core 2, possible range from "down_threshold" to 100, default: 68
tuneable -> /sys/devices/system/cpu/cpufreq/zzmoove/up_threshold_hotplug3
hotplug up threshold for core 3 - 0 = turn off core 3, possible range from "down_threshold" to 100, default: 68
tuneable -> /sys/devices/system/cpu/cpufreq/zzmoove/down_threshold_hotplug1
hotplug down threshold for core 1 - possible range from 11 to under "up_threshold", default: 55
tuneable -> /sys/devices/system/cpu/cpufreq/zzmoove/down_threshold_hotplug2
hotplug down threshold for core 2 - possible range from 11 to under "up_threshold", default: 55
tuneable -> /sys/devices/system/cpu/cpufreq/zzmoove/down_threshold_hotplug3
hotplug down threshold for core 3 - possible range from 11 to unter "up_threshold", default: 55
Thanks to:
gsw5700 for the initial Idea "hotplug threshold per core".
brijmathew indirectly for the initial idea "just one core at screen off" (i think he did'nt meant exactly that in his post but hey he switched on the led in my head! *gg*)
ZZMoove Governor v0.4
(Post from 1st May 2013, 10:59 PM - "limits")
Changelog:
Frequency Limits:
First of all there is now a (by me so called) "soft" limit function for limiting frequencies at screen off but also at screen on if u wish. however i recommend to set the screen on limit always with the (if provided) max scaling functionality of the kernel as this is the better way of doing it and "works better" for following reasons: touchboost and wake up frequencies can go above that governor-soft-limit (mostly to 800/1000 mhz) because the governor has no control over these "events" and will be "bypassed" by cpufreq driver! nevertheless by setting this soft limit at screen off the use of frequencies higher than the given limit will be strongly reduced and therefore this will reduce power consumption at screen off. and that was the main intention - saving power if u do not use your phone!
For this function following new tuneables were indroduced to set in sysfs (/sys/devices/system/cpu/cpufreq/zzmoove/):
freq_limit_sleep: limit freqency at screen off (possible values 0 disable limit, 200000-1600000, default: 0)
freq_limit: limit freqency at screen on (possible values 0 disable limit, 200000-1600000, default: 0)
Fast Scaling:
As a second feature in this new version i added the so called (again by me *g*) "fast scaling" for faster up/down scaling! This should bring more performance but on the other hand this can be of course a little bit more power consumptive. try it, it makes things snappier and some people reported that with this setting touch boost can then also be disabled which wasn't really "possible" with previous versions of zzmoove governor.
For this function following new tuneables were indroduced to set in sysfs (/sys/devices/system/cpu/cpufreq/zzmoove/):
fast_scaling: fast scaling at screen on (possible values 0 disable or 1 enable, default: 0)
fast_scaling_sleep: fast scaling at screen off (possible values 0 disable or 1 enable, default: 0)
As last "feature" and to complete the "set" the tuneable "freq_step_sleep" was included to be able to change freq step only at screen off
possible settings are the same as the "freq_step" tuneable which are values from 0% (stops freq scaling) to 100% (switches frequencies from lowest to highest frequency and vice versa like ondmand governor) default is 1 in all settings (bat/opt/perf) at screen off.
ZZMoove Governor v0.5 aka "The Beast"
(performance and fixes)
Changelog:
- completely reworked fast scaling functionality. now using a "line jump" logic instead of fixed freq "colums".
fast scaling now in 4 steps and 2 modes possible (mode 1: only fast scaling up and mode2: fast scaling up/down)
- added support for "Dynamic Screen Frequency Scaling" (original implementation into zzmoove governor highly improved by Yank555)
originated by AndreiLux more info: http://forum.xda-developers.com/showpost.php?p=38499071&postcount=3
- re-enabled broken conservative sampling down factor functionality ("down skip" method).
originated by Stratosk - upstream kernel 3.10rc1: https://git.kernel.org/cgit/linux/k...id=refs/tags/v3.10-rc1&qt=author&q=Stratos+Ka
- changed down threshold check to act like it should.
originated by Stratosk - upstream kernel 3.10rc1: https://git.kernel.org/cgit/linux/k...id=refs/tags/v3.10-rc1&qt=author&q=Stratos+Ka
- implemented/ported "early demand" from ondemand governor.
originated by Stratosk - more info: http://www.semaphore.gr/80-latests/98-ondemand-early-demand
- implemented/ported "sampling down momentum" from ondemand governor.
originated by Stratosk - more info: http://www.semaphore.gr/80-latests/80-sampling-down-momentum
- modified some original conservative code parts regarding frequency scaling which should work better now.
originated by DerTeufel1980: https://github.com/DerTeufel/androi...mmit/6bab622344c548be853db19adf28c3917896f0a0
- added the possibility to use sampling down momentum or conservative "down skip" method.
- increased possible max sampling rate sleep multiplier to 4 and sampling down factor to 100000
accordingly to sampling down momentum implementation.
- added frequency search limit for more efficient frequency searching in scaling "table" and for improving
frequency "hard" and "soft" limit handling.
- added cpu idle exit time handling like it is in lulzactive
again work from ktoonsez : https://github.com/ktoonsez/KT747-JB/commit/a5931bee6ea9e69f386a340229745da6f2443b78
description in lulzactive governor: https://github.com/ktoonsez/KT747-J...f2443b78/drivers/cpufreq/cpufreq_lulzactive.c
- fixed a little scaling step mistake and added overclocking frequencies up to 1800 mhz in scaling frequency "tables".
- fixed possible freezes during start/stop/reload of governor and frequency limit change.
- fixed hotplugging logic at online core 0+3 or 0+2 situations and improved hotplugging in general by
removing mutex locks and skipping hotplugging when it is not needed.
- added possibility to disable hotplugging (that's a debugging relict but i thought maybe someone will find that usefull so i didn't remove it)
- try to fix lags when coming from suspend if hotplug limitation at sleep was active by enabling all offline cores during resume.
- code cleaning and documentation.
for this functions following new tuneables were indroduced:
Early Demand:
early_demand -> switch to enable/disable early demand functionality (possible values 0 disable or 1 enable, default: 0)
grad_up_threshold -> scale up frequency if the load goes up in one step of grad up value (possible range from 11 to 100, default 50)
little example for understanding: when the load rises up in one big 50% step then the
frequency will be scaled up immediately instead of wating till up_threshold is reached.
Fast Scaling (improved):
Fast scaling has now 8 levels which at the same time have 2 modes included. Values from 1-4 equals to scaling jumps in the frequency table and uses the Fast Scaling up but normal scaling down mode. Values from 5-8 equals to 1-4 scaling jumps but uses the fast scaling up and fast scaling down mode.
Hotplugging switch:
disable_hotplug -> switch to enable/disable hotplugging (possible values are any value above 0 to disable hotplugging and 0 to
enable it, default 0)
Sampling Down Factor and Sampling Down Momentum:
Description: From the original author of ondemand_sampling_factor David Niemi:
"This improves performance by reducing the overhead of load evaluation and helping the CPU stay
at its top speed when truly busy, rather than shifting back and forth in speed."
And that "Sampling Down Momentum" function from stratosk does this dynamicly now!
sampling_down_max_momentum -> max sampling down factor which should be set by momentum (0 disable momentum, possible range from sampling_down_factor up to MAX_SAMPLING_DOWN_FACTOR, default 0 disabled)
sampling_down_momentum_sensitivity -> how fast the sampling down factor should be switched (possible values from 1 to 500, default 50)
sampling_down_factor -> depending on which mode is active the factor for sampling rate multiplier which influences the whole
sampling rate or the value for stock "down skip" functionality which influences only the down scaling
mechanism (possible values are from 1 to MAX_SMPLING_DOWN_FACTOR, default 1 disabled)
Original conservative "down skip" or "stock" method can be enabled by setting the momentum tuneable to 0. so if momentum is inactive there will be a fallback to the stock method. as the name "down skip" says this method works "slightly" different from the ondemand stock sampling down method (on which momentum was based on). It just skips the scaling down code for the given samples. if u want to completely disable the sampling down functionality u can achieve this by setting sampling down factor to 1. so concluded: setting sampling_down_momentum = 0 and sampling_down_factor = 1 will disable sampling down completely (that is also the governor default setting)
Dynamic Screen Frequency Scaling:
Dynamicly switches the screen frequency to 40hz or 60hz depending on cpu scaling and hotplug settings. For compiling and enabling this functionality u have to do some more modification to the kernel sources, please take a look at AndreiLux Perseus repository and there at following commit: https://github.com/AndreiLux/Perseus-S3/commit/3476799587d93189a091ba1db26a36603ee43519 After adding this patch u can enable the feature by setting "CPU_FREQ_LCD_FREQ_DFS=y" in your kernel config and if u want to check if it is really working at runtime u can also enable the accounting which AndreiLux added by setting LCD_FREQ_SWITCH_ACCOUNTING=y in the kernel config. If all goes well and u have the DFS up and running u can use following tuneables to do some screen magic: (thx to Yank555 for highly extend and improving this!)
lcdfreq_enable -> to enable/disable LCDFreq scaling (possible values 0 disable or 1 enable, default: 0)
lcdfreq_kick_in_down_delay -> the amount of samples to wait below the threshold frequency before entering low display frequency mode (40hz)
lcdfreq_kick_in_up_delay -> the amount of samples to wait over the threshold frequency before entering high display frequency mode (60hz)
lcdfreq_kick_in_freq -> the frequency threshold - below this cpu frequency the low display frequency will be active
lcdfreq_kick_in_cores -> the number of cores which should be online before switching will be active. (also useable in combination
with kickin_freq)
So this version is a kind of "featured by" release as i took (again *g*) some ideas and work from other projects and even some of that work
comes directly from other devs so i wanna thank and give credits:
First of all to stratosk for his great work "sampling down momentum" and "early demand" and for all the code fixes which found their way into
the upstream kernel version of conservative governor! congrats and props on that stratos, happy to see such a nice and talented dev directly
contibuting to the upstream kernel, that is a real enrichment for all of us!
Second to Yank555 for coming up with the idea and improving/completeing (leaves nothing to be desired now *g*) my first
rudimentary implementation of Dynamic Screen Frequency Scaling from AndreiLux (credits for the idea/work also to him at this point!).
Third to DerTeufel1980 for his first implementation of stratosk's early demand functionality into version 0.3 of zzmoove governor
(even though i had to modify the original implementation a "little bit" to get it working properly ) and for some code optimizations/fixes regarding scaling.
Last but not least again to ktoonsez - I "cherry picked" again some code parts of his ktoonservative governor which should improve this governor
too!
ZZMoove Governor 0.5.1a
(bugfixes)
urgend bugfix release:
- fix governor switching issues (deadlocks) which oviously werend fixed in version v0.5
- optimised scaling function a lot (thx and credits to Yank555!)
ZZMoove Governor 0.5.1b (in cooperation with Yank555)
(bugfixes and more optimisations)
Changelog:
- now really fixed the governor switching issues! (gotcha *****! *g*)
- again some changes in scaling logic from Yank555 (thx and credits)
- simplified some tuneables by using already available stuff instead of using redundant code (thx Yank555)
- reduced/optimised hotplug logic and preperation for automatic detection of available cores
(maybe this fixes also the scaling/core stuck problems)
ZZMoove Governor 0.6 (in cooperation with Yank555)
(flexibility)
Changelog:
- removed fixed scaling lookup tables and use the system frequency table instead
changed scaling logic accordingly for this modification (thx and credits to Yank555)
- reduced new hotplug logic loop to a minimum
- again try to fix stuck issues by using seperate hotplug functions out of dbs_check_cpu (credits to ktoonesz)
- added support for 2 and 8 core systems and added automatic detection of cores were it is needed
(for setting the different core modes you can use the macro 'MAX_CORES'. possible values are: 2,4 or 8, default are 4 cores)
reduced core threshold defaults to only one up/down default and use an array to hold all threshold values
- fixed some mistakes in "frequency tuneables" (Yank555):
stop looping once the frequency has been found
return invalid error if new frequency is not found in the frequency table
ZZMoove Governor 0.6a (in cooperation with Yank555)
(scaling logic flexibility)
Changelog:
- added check if CPU freq. table is in ascending or descending order and scale accordingly
(compatibility for systems with 'inverted' frequency table like it is on OMAP4 platform)
thanks and credits to Yank555!
ZZMoove Governor 0.7 aka "Tamed Beast" (in cooperation with Yank555)
(slow down)
Changelog:
- reindroduced the 'old way' of hotplugging and scaling in form of the 'Legacy Mode' (macros for enabling/disabling this done by Yank555, thx!)
NOTE: this mode can only handle 4 cores and a scaling max frequency up to 1800mhz.
- added hotplug idle threshold for a balanced load at CPU idle to reduce possible higher idle temperatures when running on just one core.
(inspired by @JustArchi observations, thx!)
- added hotplug block cycles to reduce possible hotplugging overhead (credits to @ktoonsez)
- added possibility to disable hotplugging only at suspend (inspired by a request of @STAticKY, thx for the idea)
- introduced hotplug frequency thresholds (credits to Yank555)
- hotplug tuneables handling optimized (credits to Yank555)
- added version information tuneable (credits to Yank555)
for this functions following new tuneables were indroduced:
legacy_mode -> for switching to the 'old' method of scaling/hotplugging. possible values 0 to disable, any values above 0 to enable (default is 0)
NOTE: the legacy mode has to be enabled by uncommenting the macro ENABLE_LEGACY_MODE
hotplug_idle_threshold -> amount of load under which hotplugging should be disabled at idle times (respectively at scaling minimum). possible values 0 disable, from 1 to 100 (default is 0)
hotplug_block_cycles -> slow down hotplugging by waiting a given amount of cycles before plugging. possible values 0 disbale, any values above 0 (default is 0)
disable_hotplug_sleep -> same as disable_hotplug but will only take effect at suspend. possible values 0 disable, any values above 0 to enable (default is 0)
up_threshold_hotplug_freq1 -> hotplug up frequency threshold for core1. possible values 0 disable and range from over down_threshold_hotplug_freq1 to max scaling freqency (default is 0)
up_threshold_hotplug_freq2 -> hotplug up frequency threshold for core2. possible values 0 disable and range from over down_threshold_hotplug_freq2 to max scaling freqency (default is 0)
up_threshold_hotplug_freq3 -> hotplug up frequency threshold for core3. possible values 0 disable and range from over down_threshold_hotplug_freq3 to max scaling freqency (default is 0)
down_threshold_hotplug_freq1 -> hotplug down frequency threshold for core1. possible values 0 disable and range from min saling to under up_threshold_hotplug_freq1 freqency (default is 0)
down_threshold_hotplug_freq2 -> hotplug down frequency threshold for core2. possible values 0 disable and range from min saling to under up_threshold_hotplug_freq2 freqency (default is 0)
down_threshold_hotplug_freq3 -> hotplug down frequency threshold for core3. possible values 0 disable and range from min saling to under up_threshold_hotplug_freq3 freqency (default is 0)
version -> show the version of zzmoove governor
ZZMoove Governor 0.7a
(little fix)
Changelog:
- fixed a glitch in hotplug freq threshold tuneables which prevented setting of values in hotplug down freq thresholds when hotplug
up freq thresholds were set to 0. NOTE: enabling the legacy mode in the source is not part of that fix i just forgot to set it back to standard (disabled) before pushing, sry to lazy to fix that fix now
ZZMoove Governor 0.7b
(compatibility improved and forgotten things)
Changelog:
- fixed stuck at max scaling frequency when using stock kernel sources with unmodified cpufreq driver and without any oc capabilities.
- readded forgotten frequency search optimisation in scaling logic (only effective when using governor soft frequency limit)
- readded forgotten minor optimisation in dbs_check_cpu function.
- as forgotten to switch in last version Legacy Mode now again disabled by default
- minor code format and comment fixes
ZZMoove Governor 0.7c
(again compatibility and optimisations)
Changelog:
- frequency search optimisation now fully compatible with ascending ordered system frequency tables (thx to @psndna88 for testing!)
- again minor optimisations at multiple points in dbs_check_cpu function
- code cleaning - removed some unnecessary things and whitespaces nuked - sry for the bigger diff but from now on it will be clean!
- corrected changelog for previous version regarding limits
ZZMoove Governor 0.7d (bugfix!)
(broken things)
Changelog:
- fixed hotplug up threshold tuneables to be able again to disable cores manually via sysfs by setting them to 0
- fixed the problem caused by a "wrong" tuneable apply order of non sticking values in hotplug down threshold tuneables when
hotplug up values are lower than down values during apply.
NOTE: due to this change right after start of the governor the full validation of given values to these tuneables is disabled till
all the tuneables were set for the first time. so if you set them for example with an init.d script or let them set automatically
with any tuning app be aware that there are illogical value combinations possible then which might not work properly!
simply be sure that all up values are higher than the down values and vice versa. after first set full validation checks are enabled
again and setting of values manually will be checked again.
- fixed a typo in hotplug threshold tuneable macros (would have been only a issue in 8-core mode)
- fixed unwanted disabling of cores when setting hotplug threshold tuneables to lowest or highest possible value
which would be a load of 100%/11% in up/down_hotplug_threshold and/or scaling frequency min/max in up/down_hotplug_threshold_freq
CPU Governor ZZMoove Changelog
ZZMoove Governor 0.8
(cool down baby!)
Changelog:
- indroduced scaling block cycles (in normal and legacy mode) to reduce unwanted jumps to higher frequencies (how high depends on settings) when a load comes up just for a short peroid of time or is hitting the scaling up threshold more often because it is within some higher to mid load range. reducing these jumps lowers CPU temperature in general and may also save some juice. so with this function u can influence the little bit odd scaling behaving when you are running apps like for example games which are constantly 'holding' system load in some range and the freq is scaled up too high for that range. in fact it just looks like so, monitoring apps are mostly too slow to catch load in realtime so you are watching almost only 'the past'. so actually it's not really odd it's more like: an app is stressing the system and holding it on a higher load level, due to this load level scaling up threshold is more often reached (even if monitoring shows a lower load than up_threshold!) the governor scales up very fast (usual zzmoove behaving) and almost never scales down again (even if monitoring shows a lower load than down_threshold!). now in patricular these scaling block cycles are throttling up scaling by just skipping it for the amount of cycles that you have set up and after that are making a forced scale down in addition for the same amount of cycles. this should bring us down to a 'appropriate' frequency when load is hanging around near up threshold.
- indroduced (D)ynamic (S)ampling (R)ate - thx to hellsgod for having the same idea at the same time and pointing me to an example. even though at the end i did 'my way' DSR switches between two sampling rates depending on the given load threshold from an 'idle' to a 'normal' one.
- added read only tuneable 'sampling_rate_current' for DSR to show current SR and internally use this sampling rate instead of automatically changing 'sampling_rate' tuneable in DSR. this keeps things more compatible and avoids problems when governor tuneables are set with tuning apps which are saving actual shown values.
- changed setting of sampling rate in governor from 'sampling_rate' to 'sampling_rate_current' and the value at suspend to 'sampling_rate_idle' value instead of using current active sampling rate to avoid accidentally setting of 'normal operation' sampling rate in sampling rate idle mode which has usually a much lower value.
- indroduced build-in profiles in seperate header file (credits to Yank555 for idea and prototype header file) you can switch between multible build in profiles by just piping a number into the tuneable 'profile_number'. all tuneable values of the set profile will be applied on-the-fly then. if a profile is active and you change any tuneable value from it to a custom one the profile will switch to '0' in 'profile_number' and 'custom' in 'profile' for information. with this profiles support developers can simplify their governor settings handling by adding all their desired and well proven governor settings into the governor itself instead of having to fiddle around with init.d scripts or tuning apps. NOTE: this is just an optional feature, you can still set all tuneables as usual just pay attention that the tuneable 'profile_number' is set to '0' then to avoid overwriting values by any build-in profile! for further details about profiles and adding own ones check provided 'cpufreq_zzmoove_profiles.h' file.
- added 'profiles_version' tuneable to be able to show seperate profiles header file version.
- added enabling of offline cores on governor exit to avoid cores 'stucking' in offline state when switching to a non-hotplug-able governor
and by the way reduced reduntant code by using an inline function for switching cores on and using the better 'sheduled_work_on-way' at all needed places in the code for that purpose.
- moved some code parts to legacy mode macro which has only relevance when including the legacy mode in the governor and in addition excluded it during runtime if legacy mode is disabled.
- improved freq limit handling in tuneables and in dbs_check_cpu function
- changed value restriction from '11' to '1' in hotplug down threshold and grad up tuneables as this restriction is only nessesary in
scaling down tuneable
- added missing fast scaling down/normal scaling up mode to fast scaling functionality (value range 9-12 and only available in non-legacy mode thx @OldBoy.Gr for pointing me to that missing mode!)
- added auto fast scaling aka 'insane' scaling mode to fast scaling functionality - lucky number 13 enables this mode in fast_scaling tuneable NOTE: a really funny mode, try it but keep in mind setting this in combination with a set freq limit (at sleep or awake)would not make much sense as there is not enough frequency range available to jump around then.
- back from the precautious 'mutex_try_lock' to normal 'mutex_lock' in governor 'LIMIT' case -> this should be save again, no deadlocks expected any more since hotplug logic has significantly changed in zzmoove version 0.6
- removed also the no longer required and precautious skipping of hotplugging and dbs_check_cpu on multiple places in code and removed the mutex locks at governor stop and early suspend/late resume
- added hotlug freq thresholds to legacy scaling mode (same usage as in normal scaling mode)
- seperated hotplug down and up block cycles to be more flexible. this replaces 'hotplug_block_cycles' with 'hotplug_block_up_cycles' tuneable and adds one new tunable 'hotplug_block_down_cycles'. functionality is the same as before but u can now differentiate the up and down value.
- added 'early demand sleep' combined with automatic fast scaling (fixed to scaling up mode 2) and if not set already automatic (depending on load) switching of sampling rate sleep multiplier to a fixed minimum possible multiplier of 2. this should avoid mostly audio or general device connection problems with 'resource hungrier' apps like some music players, skype, navigation apps etc. and/or in combination with using bluetooth equipment during screen is off. NOTE: this overwrites a possible fast 'scaling_sleep' setting so use either this or 'fast_scaling_sleep'
- added some missing governor tunebable default value definitions
- removed tuneable apply order exception and removed analog value checks in hotplug threshold and hotplug frequency tuneables to avoid tuneable values not changing issues. NOTE: keep in mind that all 'down' values should be lower then the analog 'up' values and vice versa!
- removed 200 mhz up hotplugging restriction, so up hotplugging starts at 200 mhz now
- removed some unnecessary macros in scaling logic
- added maximum fast scaling and frequency boost to late resume to react wakeup lags
- merged some improvements from ktoonservativeq governor version for the SGS4 (credits to ktoonsez)
changes from here: https://github.com/ktoonsez/KT-SGS4/commits/aosp4.4/drivers/cpufreq/cpufreq_ktoonservativeq.c
Use dedicated high-priority workqueues
Use NEW high-priority workqueue for hotplugging
Improved hotplugging in general by reducing calls to plugging functions if they are currently running,
by reducing calls to external function in up plugging and by changing the down plug loop to an optimized one
- added hotplug boost switch to early demand functionality and up hotplugging function
- added 'hotplug_idle_freq' tuneable to be able to adjust at which frequency idle should begin
- transfered code for frequency table order detection and limit optimisation into a inline function and use this function in START,LIMIT case and early suspend/late resume instead of using redundant code
- execute table order detection and freq limit optimization calculations at 'START' and 'LIMIT' case to avoid possible wrong setting of freq
max after governor start (currently set max frequency value was sometimes not applied) and a wrong soft limit optimization setting after undercutting the soft limit with a lower hard limit value
- minor optimisation in hotplug, hotplug block and in all freq search logic parts
- added debugging sysfs interface (can be included/excluded using #define ZZMOOVE_DEBUG) - credits to Yank555!
- added some missing annotation as a prepareation and mainly to avoid some errors when compiling zzmoove in combination with 3.4+ kernel sources
- fixed hotplugging issues when cpufreq limit was set under one or more hotplugging frequency thresholds NOTE: now hotplugging frequency thresholds will be completely disabled and a fall back to normal load thresholds will happen if the maximal possible frequency will undercut any frequency thresholds
- fixed stopping of up scaling at 100% load when up threshold tuneable is set to the max value of 100
- fixed smooth up not active at 100% load when smooth up tuneable is set to the max value of 100
- fixed many code style and dokumentation issues and made a massive code re-arrangement
for this functions following new tuneables were indroduced:
early_demand_sleep -> same function as early demand on awake but in addition combined with fast scaling and sampling rate switch and only active at sleep. (possible values 0 disable or 1 enable, default is 1)
grad_up_threshold_sleep -> 2 way functionality: early demand sleep grad up (load gradient) threshold and at the same time load threshold for switching internally (tuneables are staying at set values!) sampling_rate_sleep_multiplier to 2 and fast_scaling to 2 (possible values from 1 to 100, default is 35)
hotplug_block_up_cycles -> (replaces hotplug_block_cycles) slow down up hotplugging by waiting a given amount of cycles before plugging. possible values 0 disbale, any values above 0 (default is 0)
hotplug_block_down_cycles -> (replaces hotplug_block_cycles) slow down down hotplugging by waiting a given amount of cycles before plugging. possible values 0 disbale, any values above 0 (default is 0)
hotplug_idle_freq -> freq at which the idle should be active (possible values 0 disable and any possible scaling freq, default is 0)
sampling_rate_current -> read only and shows currently active sampling rate
sampling_rate_idle -> sampling rate which should be used at 'idle times' (possible values are any sampling rate > 'min_sampling_rate', 0 to disable whole function, default is 0)
sampling_rate_idle_delay -> delay in cycles for switching from idle to normal sampling rate and vice versa (possible values are any value and 0 to disable delay, default is 0)
sampling_rate_idle_threshold -> threshold under which idle sampling rate should be active (possible values 1 to 100, 0 to disable function, default is 0)
scaling_block_cycles -> amount of gradients which should be counted (if block threshold is set) and at the same time up scaling should be blocked and after that a forced down scaling should happen (possible values are any value, 0 to disable that function, default is 0)
scaling_bock_freg -> frequency at and above the blocking should be active (possible values are any possible scaling freq, 0 to enable blocking permanently at every frequency, default is 0)
scaling_block_threshold -> gradient (min value) of load in both directions (up/down) to count-up cycles (possible value are 1 to 100, 0 to disable gradient counting)
scaling_block_force_down -> multiplicator for the maximal amount of forced down scaling cycles (force down cycles = block_cycles * force_down) therefore the forced down scaling duration (possible value are 2 to any value, 0 to disable forced down scaling and use only scaling up blocks)
profile -> read only and shows name of currently active profile ('none' = no profile, 'custom' = a profile value has changed)
profile_number -> switches profile (possible value depends on amount of profiles in cpufreq_zzmoove_profiles.h file, please check this file for futher details!) 0 no profile set = tuneable mode, default 0)
version_profiles -> read only and shows version of profile header file
if ZZMOOVE_DEBUG is defined:
debug -> read only and shows various usefull debugging infos
ZZMoove Governor 1.0 Final
(EOL)
Changelog:
EOL commit: https://github.com/zanezam/cpufreq-governor-zzmoove/commit/b22eed13461fbb59b8e9e0121656582d6ef10696
Governor: https://github.com/zanezam/cpufreq-governor-zzmoove/blob/snapdragon/CHANGELOG.txt
Profiles: https://github.com/zanezam/cpufreq-governor-zzmoove/blob/snapdragon/CHANGELOG_PROFILES.txt
Current Test-Versions (obsolete but kept for reference):
Version 1.0 beta8
(outbreak)
Changelog:
https://github.com/zanezam/cpufreq-governor-zzmoove/commit/bef4355a652fdfc268b774e874b355bd269dbc07
Version 1.0 beta7a (bugfix)
(outbreak)
Changelog:
https://github.com/zanezam/cpufreq-governor-zzmoove/commit/1ce22579b0e6dfce0d9916b9f0644e7d707d8587
Version 1.0 beta7 (sync)
(outbreak)
Changelog:
https://github.com/zanezam/cpufreq-governor-zzmoove/commit/52ad61b169c24258ec1b0e6a630bbab5142faa67
Version 1.0 beta6a (Andip71 aka Lord Boeffla)
(outbreak)
Changelog (credits to Andip71):
https://github.com/zanezam/cpufreq-governor-zzmoove/commit/9b01250eb988e86c98d289dabe6773ba748f58dd
Version 1.0 beta6 (feature preview, for opo only atm.)
(outbreak)
Changelog:
https://github.com/zanezam/cpufreq-governor-zzmoove/commit/75c431aeff8354f224e4c688faa1559ac463ab8a
Version 1.0 beta5
(outbreak)
Changelog:
https://github.com/zanezam/cpufreq-governor-zzmoove/commit/1d2727cb9cefe0484573ace9e0dc9b55ba6c26f6
Version 1.0 beta4 (sync)
(outbreak)
Changelog:
- use again the conservative governor usual canceling of dbs work syncron instead of asyncron when exiting the governor as this change was
only needed in combination with older hotplug implementations. as also done in opo version removed again all previously merged kernel crash
fix attempts and precautions as they were not really needed
- bump version to beta4 to bring opo/i9300 versions in sync again
Version 1.0 beta3 (bugfix for opo-bacon)
(outbreak)
Changelog:
- changed back canceling of dbs work to syncron instead of asyncron in dbs_timer_exit function to avoid random kernel chrashes (again oops in smp.c)
when using this governor with the cpufreq implementation of kernel versions 3.10+. problem was initiated by governor restarts during hotplugging
- as an additional precaution check if a core is online before doing critical stuff in dbs_check_cpu main function (might be removeable at a later
time, more analyses/tests will show)
profile header file (Version 0.3 beta2 OPO)
- corrected/adjusted sampling rate values in settings where they were lower than the minimal possible value of 60000
Version 1.0 beta2
(outbreak)
Changelog:
- avoid kernel crash (usually a oops in smp.c) by checking if a core is online before putting work on it: this problem appeared on opo qualcomm
platform with proprietary mpdecision hotplugging service. assumption is that there is a delay between initiating hotplugging events from 'userland'
and gathering core state info in 'kernel land' so under some rare circumestances the governor doesn't 'know about' a changed core state and tries to
put work on a meanwhile offline core or that hotplug event happend during putting work on a core in the governor.
Version 1.0 beta1
(outbreak)
Changelog:
- bump version to 1.0 beta1 because of brought forward plan 'outbreak'
- reworked scaling logic:
removed unessesary calls of external cpufreq function and use a static variable instead to hold the system freq table during runtime fixed frequency stuck on max hard and soft frequency limit (under some circumstances freq was out of scope for the main search loop) and added precautions to avoid problems when for what ever reason the freq table is 'messed' or even not available for the governor fixed not properly working scaling with descend ordered frequency table like it is for example on qualcomm platform added additional propotional scaling mode (mode '1' as usual decide and use the lowest freq, new mode '2' use only propotional frequencies like ondemand governor does - switchable as before in 'scaling_proportional' tuneable)
- use static frequency table variable in all frequency checks agains system frequency table in the governor
- fixed 'update_ts_time_stat idle accounting' (kernel patch for kernel version 3.0.x needed, example available in github zzmoove repository)
- fixed non setting of scaling down threshold tuneables under some circumstances (issue on kernel 3.4 when running multible zzmoove instances)
- changed some variable names in scaling range evaluation and debugging tuneable
- added compatibility for kernel version 3.4 (or higher, but only tested on 3.4.0 yet)
- added compatibility for cpufreq implementation used since kernel version 3.10 (NOTE: for backports u can use the macro CPU_IDLE_TIME_IN_CPUFREQ)
- added support for powersuspend (used on some platforms since kernel version 3.4)
- added support for opo specific 'backlight ext control' (kernel patch for opo bacon devices needed, example available in github zzmoove repository)
- added macros to exclude hotplugging functionality (default in this version is enabled=uncommented)
profile header file (Version 0.3 beta1)
- bump version to 0.3 beta1 because of brought forward plan 'outbreak'
- removed dynamic freq scaling tuneable leftovers
- added macros to switch code depending of used power management implementation
or used supend/resume backlight hook (opo specific)
- added macros to be able to disable hotplugging
Version 0.9 beta4
(slimline)
Changelog:
- removed 'freq_step' functionality as it never had any function in this governor. it was a left over from mialwes 'smoove' governor and also
had no function in his governor back then. so yeah all the 'feelings' about it's influence were placebo
- introduced 'proportional scaling' for more 'connectivity' to current load, this should give more 'balanced' frequencies
in general. when enabled all targeted frequencies in scaling logic will be compared with the ones from system table method and at the end
the lowest of them both will be used. so all used scaling frequencies will be 'tentential' lower in both directions
- added support for exynos4 CPU temperature reading (patches available in zzmoove repositories: https://github.com/zanezam)
this must be enabled via 'CONFIG_EXYNOS4_EXPORT_TEMP=y' in the config of a kernel which has exynos4 CPU temperature export
implementation
included. the default temp polling interval is 1000 ms and can be set with DEF_TMU_READ_DELAY. however the TMU driver has it's own polling
interval which is 10 seconds, so leaving it at the default value of 1 second is recommended temperature reading will only be enabled if the
tuneable 'scaling_block_temp' is set and will be disabled whenever early suspend is entered
- if exynos4 CPU temperature reading is enabled in the code use current CPU temperature in scaling block functionality to be able to 'hold' the cpu
temperatue to the given one in 'scaling_block_temp'. this function is used in combination with the already existent tuneable 'scaling_block_freq'
so u have to set both to enable it. the possible temperature range is 30°C to 80°C (lower temps are making no sense and higher temps would reach
into exynos4 TMU driver trottling range)
- if exynos4 CPU temperature reading is enabled added current CPU temperature to debug info tuneable
- added auto adjustment of all available frequency thresholds when scaling max limit has changed
- again some code style and comment changes/fixes
profile header file (Version 0.2 beta3):
- added scaling block temperature tuneable to all profiles if CONFIG_EXYNOS4_EXPORT_TEMP is defined
- use CPU temperature treshold of 65°C instead of 15 scaling block cycles in game profile if
CONFIG_EXYNOS4_EXPORT_TEMP is defined
- added proportional frequency tuneable to all profiles
- added auto adjust freq thresholds to all profiles (disabled by default)
- enabled scaling proportional in ybat, ybatext, zzbat, zzbatp, zzmod and zzgame profile
- enabled scaling fast down over 1200MHz and resposiveness over 400Mhz with up threshold of 20
in ybat, ybatext, zzbat, zzbatp, and zzmod profile
- added core macros to exclude not used code like it is in governor
- removed freq_step tuneable from all profiles
Version 0.9 beta3
(slimline)
Changelog:
merged some changes originated by ffolkes (all credits and thx to him)
(source https://github.com/ffolkes/android_...44e1e3190d5/drivers/cpufreq/cpufreq_zzmoove.c
- reordered sysfs attributes
description by ffolkes: some apps set tuneables by the order in which they are listed in the filesystem. this causes problems when one
tuneable needs another set first in order to correctly validate. (e.g. you cannot set down_threshold properly until you have first set up_threshold)
- added 'fast down' functionality (based on commits to pegasusq in perseus by andreilux and extended for this version by ZaneZam)
description by ffolkes: fastdown dynamically applies a (presumably) higher up_threshold and down_threshold after a frequency threshold has been reached. the goal is to encourage less time spent on the highest frequencies
- added 'hotplug engage' functionality
description by ffolkes: when set >0, will not bring any cores online until this frequency is met or exceeded
goal: reduce unnecessary cores online at low loads
- added 'scaling responsiveness' functioniality
description by ffolkes: similar to 'frequency for responsiveness' in other governors
defines a frequency below which we use a different up_threshold to help eliminate lag when starting tasks
- instead of failing when set too high in down_threshold tuneables set the value to the highest it can safely go
- increased possible sampling rate sleep multiplier value to a max of 8 (ZaneZam)
- added missing error handling to some tuneables (ZaneZam)
- fixed non setting of 'hotplug_sleep' tuneable when applying profiles (ZaneZam)
- added up/down threshold to debug tuneable (ZaneZam)
- some code style and comment changes/fixes (ZaneZam)
for this functions following new tuneables were introduced:
scaling_fastdown_freq-> will be enabled once this frequency has been met or exceeded (0 to disable, all possible system frequencies, default is 0)
scaling_fastdown_up_threshold-> once the above frequency threshold has been met, this will become the new up_threshold until we fall below the scaling_fastdown_freq again. (range from over fastdown_down_threshold to 100, default is 95)
scaling_fastdown_down_threshold-> once the above frequency threshold has been met, this will become the new down_threshold until we fall below the scaling_fastdown_freq again. (range from 11 to under fastdown_up_threshold, default is 90)
scaling_responsiveness_freq-> will be enabled once this frequency has been met or exceeded (0 to disable, all possible system frequencies, default is 0)
scaling_responsiveness_up_threshold-> the up_threshold that will take effect if scaling_responsiveness_freq is set (range from 11 to 100, default is 30)
hotplug_engage_freq -> will not bring any cores online until this frequency is met or exceeded (0 to disable, any possible system frequencies, default is 0)
profile header file (Version 0.2 beta2):
- added values for following new tuneables (credits to ffolkes):
hotplug_engage_freq (disabled by default in all profiles)
scaling_fastdown_freq (disabled by default in all profiles)
scaling_fastdown_up_threshold (default to 95 in all profiles)
scaling_fastdown_down_threshold (default to 90 in all profiles)
scaling_responsiveness_freq (disabled by default in all profiles)
scaling_responsiveness_up_threshold (default to 30 in all profiles)
- adjusted up/down thresholds for core 2 in moderate setting
- changed sampling rate sleep multiplier from 4 to 6 in all settings (except in default setting)
Version 0.9 beta2
(slimline)
Changelog:
- support for setting a default settings profile at governor start without the need of using the tuneable 'profile_number'
a default profile can be set with the already available macro 'DEF_PROFILE_NUMBER' check zzmoove_profiles.h for details about
which profile numbers are possible. this functionality was only half baken in previous versions, now any given profile will be really
applied when the governor starts. the value '0' (=profile name 'none') in 'DEF_PROFILE_NUMBER' disables this profile hardcoding and
that's also the default in the source. u still can (with or without enabling a default profile in the macro) as usual use the tuneable
'profile_number' to switch to a desired profile via sysfs at any later time after governor has started
- added 'blocking' of sysfs in all tuneables during apply of a settings profile to avoid a possible and unwanted overwriting/double
setting of tuneables mostly in combination with tuning apps where the tuneable apply order isn't influenceable
- added tuneable 'profile_list' for printing out a list of all profiles which are available in the profile header file
- fixed non setting of 'scaling_block_force_down' tuneable when applying profiles
- some documentation added and a little bit of source cleaning
Version 0.9 beta1
(slimline)
Changelog:
- bump version to beta for public
- added/corrected version informations and removed obsolete ones
profile header file (Version 0.2 beta1):
- bump version to beta for public
- corrected version informations
Version 0.9 alpha-2
Changelog:
- added auto fast scaling step tuneables:
afs_threshold1 for step one (range from 1 to 100)
afs_threshold2 for step two (range from 1 to 100)
afs_threshold3 for step three (range from 1 to 100)
afs_threshold4 for step four (range from 1 to 100)
profile header file (Version 0.2alpha-2):
- corrected documentation
- corrected version information
- added auto fast scaling step tuneables and values to all profiles
Version 0.9 alpha1 (Yank555.lu)
Changelog (credits to Yank555!):
- splitted fast_scaling into two separate tunables fast_scaling_up and fast_scaling_down so each can be set individually
to 0-4 (skip 0-4 frequency steps) or 5 to use autoscaling.
- splitted fast_scaling_sleep into two separate tunables fast_scaling_sleep_up and fast_scaling_sleep_down so each
can be set individually to 0-4 (skip 0-4 frequency steps) or 5 to use autoscaling.
- removed legacy mode (necessary to be able to split fast_scaling tunable)
- removed LCD frequency DFS
profile header file (Version 0.2):
- split fast_scaling and fast_scaling_sleep into fast_scaling_up/fast_scaling_down and
fast_scaling_sleep_up/fast_scaling_sleep_down
- adjusted values for profiles Yank Battery and Yank Battery Extreme
Currently in the Workshop:
working on Current versions of ZZMoove big.LITTLE Edition (bLE)
Sources:
https://github.com/zanezam/cpufreq-governor-zzmoove
General project status and repository changes:
NOTE: Changes in repository since 15.08.14
the test repository was deleted and all previous beta and stable commits are available now in the main repository.
all future commits will also land there! branches in this repo are "i9300" the new merged master branch and a new one
was added "desktop" for the "desktop edition" of zzmoove (which is btw. still WIP and far from stable, but it compiles).
Since 12.10.2014 there is a new branch called "opo-bacon" where u can find a special version for One Plus One devices and
some needed additional kernel patches for it.
NOTE: Changes in repository since 12.08.15:
renamed branch 'i9300' to 'exynos' and branch 'opo-bacon' to 'snapdragon'
added CHANGELOG_PROFILES file with the changelog of the profiles header file of this version
updated README with some quick infos about predefinded settings in this version
'desktop' branch synced with current version (same base for all now, just other settings)
new 'develop' branch based on 'snapdragon' version created for quick changes, pull requests, etc.
in short this will be the main develop branch in the future and will provide changes and fixes
earlier. but this branch also shall be considered as more experimental!
NOTE: Changes in repository since 26.05.20:
rebase: fixed all broken links to implementation examples linking to original boeffla kernels (dev has retired and removed all his work)
by using links to my still available forks. deleted 'develop' branch as it's obsolete now since old versions 'snapdragon' and 'exynos' and 'desktop'
are final and EOL now. changed default branch to 'bLE-develop-k49x' which is the newest development version.
Status:
I recently did a formal change by merging all the recent changes from the already
old 'develop' branch into a new final 1.0 version on variants 'exynos',
'snapdragon' and 'desktop' which all totally can be considered as end of life.
After 'some time' of beta state and after many successful implementations
over the years, at it's 'best times' running on tousands of devices in
different kernels, beeing stable as it currently is (used it for years 24/7
on all my meanwhile 10 devices, and still do!) and as it can be (well i have
to admit sometimes it was a beast!! *gg*) im going to make the almost 3 years
old 'develop' version finally the version 1.0 and consider it as stable.
By doing this i'm also closing this old development chapter by making the
'exynos,snapdragon and desktop' versions final and EOL. The 'develop' branch
is now obsolete and gets deleted.
Finally stable, phew what a journey!
Thx to all contributing devs and ppl who contributed with their ideas, tests
and nervs when it did 'mock around'! Last but not least thx to all of those
which let 'the beast' running on their devices! I hope u all enjoyed it like i did!
NOTE: Despite me beeing not as active as some years ago with development i
want to let u know that there meanwhile exists a 'big Little brother' (poor
one even has NO version number at all yet) of ZZMoove governor which is still
happily hopping around on 'newer' devices. This newer version exists already since
about 3 years and were already running in (meanwhile also EOL) boeffla kernels for
the OnePlus 3/5 and also can be found in some recent OnePlus 6 kernels (at least in the ones i
fiddled recently *g*). By the way i shamelessly take the opportunity: If u still
have a OnePlus 6/6T u really you should consider trying one of these builds, more
info can be found here: https://github.com/zanezam/ZZupreme-Builds
ZZMoove still rocks by significantly influencing speed and battery usage in a
positive way! Just saying.
Enjoy!
ZZMoove Governor Settings
Description of how u can switch build in Profiles
Beside of the well known ones like "Yank...","Battery","Performance" etc. settings
i did some new ones for ZZMoove v1.0 in addition which can be checked out
in particular in the new profile exynos header file provided HERE
So for those of u which have not the possibility to switch profiles with kernel dev provided tools/scripts/or what
ever but still want to switch to any of the build in settings you can do following:
use tools like Android Tuner ,SetCPU, Kernel Adiutor or similar tools which are supporting the change of multible tuneables on-the-fly or just do it directly in kernel sysfs via a terminal emulator and give the tuneable "profile_number" one of the following values:
for Default (set governor defaults)
for Yank Battery -> old untouched setting (a very good battery/performance balanced setting DEV-NOTE: highly recommended!)
for Yank Battery Extreme -> old untouched setting (like yank battery but focus on battery saving)
for ZaneZam Battery -> old untouched setting (a more 'harsh' setting strictly focused on battery saving DEV-NOTE: might give some lags!)
for ZaneZam Battery Plus -> NEW! reworked 'faster' battery setting (DEV-NOTE: recommended too! )
for ZaneZam Optimized -> old untouched setting (balanced setting with no focus in any direction DEV-NOTE: relict from back in the days, even though some people still like it!)
for ZaneZam Moderate -> NEW! setting based on 'zzopt' which has mainly (but not strictly only!) 2 cores online
for ZaneZam Performance -> old untouched setting (all you can get from zzmoove in terms of performance but still has the fast down scaling/hotplugging behaving)
for ZaneZam InZane -> NEW! based on performance with new auto fast scaling active. a new experience!
for ZaneZam Gaming -> NEW! based on performance with new scaling block enabled to avoid cpu overheating during gameplay
for ZaneZam Relax -> NEW! based on moderate (except hotplug settings) with relaxed sleep settings (to react audio/bluetooth/wakeup issues)
for asad007 lwk -> NEW! made by xda user asad007 with yet unknown direction
(since version 0.9 beta4: cpu temperature threshold of 65°C enabled if exynos4 cpu temperature reading support was compiled with the governor)
after a tunebable view-refresh in the tools/console u can see the name of the currently set profile in the "profile" tuneable,
but keep in mind not every tool supports returning chars in tunebables as some of them are internally handling them as numbers,
even though in fact they are chars in kernel sysfs so u might see a "-1" then (for example with SetCPU) not so with
Android Tuner which shows (again) what a great app this is.
Some last note for the game profile: plz do not complain about ingame performance issues or lags with this setting.
i tuned it to be more aggressive in terms of bringing freq down. reference game was angy birds star wars *g* calming
down zzmoove while playing this game was really a chellange, don't know why but it stresses the system a lot more
than others and u know how 'hasty' zzmoove can be another test game was temple run 2 and here u can see a significant
improvement with this setting. it's a bit difficult to give u THE universal setting for all games as they differ too much in terms
of how much the system is stressed by them. so we have to share our experiences to further optmize it till i made scaling
blocks more "intelligent" and therefore more automatically (idea already exists!!)
Have fun with all the settings and feel free to report back how they work for you, and/or post new ones! :highfive:
You're the Master of text!
Great and detailed
Gesendet von meinem GT-I9300 mit Tapatalk 2
romskii said:
You're the Master of text!
Great and detailed
Gesendet von meinem GT-I9300 mit Tapatalk 2
Click to expand...
Click to collapse
hehe thx i try my best to make it understandable
but i'm just about editing to shorten this novel
I do not know, but this makes the problem gov.mi / freeze and delay / I do not know where the problem is.?
I use boeffla kernel and I zzmove and still the problem
the gov.pegasusq so good
misacek said:
I do not know, but this makes the problem gov.mi / freeze and delay / I do not know where the problem is.?
I use boeffla kernel and I zzmove and still the problem
the gov.pegasusq so good
Click to expand...
Click to collapse
you are on actual beta boeffla kernel, right? do you have this on all provided settings up to "perf"? Do you uv? if so try to avoid uv for some time just to exclude this. and if you have zram enabled, can u try without this too? or maybe there is some app which is not dancing with the "beast" ? all guessed sorry can not give more advices, actual boeffla/zzmoove version runs without problems on my phone.
Great thanks I'll keep trying and testing
Finally we have a thread for zzmove governor!! :victory:
Great explanations Zane! I don't understand a few things though haha.
This is very useful, thank you very much. I'll try to learn and test tweaks for this governor, but will be probably asking you about some new features I don't get to understand
Thanks!! :good::good:
Enviado desde mi GT-I9300 usando Tapatalk 2
the best is disable touchboost or enable=?
I'm very happy for this thread! !
I will study it to understand better zzmove
un pò di tap qui e là...
Rom: Maya Rom v5.2
Kernel: Boeffla 2.12 beta 8
Modem: Buemc2
Operator: Tim
Recovery: Philz touch
@ZaneZam
I've been trying to setup lcdfreq to stay on 40hz regardless of frequency and cores.. No matter how I set it up I can't get it to sit on 40... I can get it to sit on 40 MOST of the time, but not ALL the time...
Any help appreciated..
Oh and I'm using temasek's ROM (RC5.4.1) and kernel (160613 wolfston with abb)..
Thanks
TP.
core720 said:
the best is disable touchboost or enable=?
Click to expand...
Click to collapse
since version 0.4 u can if u want, on earlier versions it lagged like hell.
it works quite well without touchboost on v0.5.x but for my taste i leave it on as i want my phone as touch responsive as possible.
but just try it maybe u like it without touchboost.
STAticKY said:
@ZaneZam
I've been trying to setup lcdfreq to stay on 40hz regardless of frequency and cores.. No matter how I set it up I can't get it to sit on 40... I can get it to sit on 40 MOST of the time, but ALL the time...
Any help appreciated..
Oh and I'm using temasek's ROM (RC5.4.1) and kernel (160613 wolfston with abb)..
Thanks
TP.
Click to expand...
Click to collapse
ok have u tried to enter 1300000? (assuming 1400000 is your max scaling setting) that should enable it all the time.
i dunno exaclty which lcd freq scaling implementation is used in temaseks kernel but i assume it's the original from
andreilux. in this implementation there is an additional touchboost switch which we removed in the boeffla
implementation. if i remember right this touchboost switch enabales hi frequency on touch. so your settings
might be overwritten by this.
ZaneZam said:
ok have u tried to enter 1300000? (assuming 1400000 is your max scaling setting) that should enable it all the time.
i dunno exaclty which lcd freq scaling implementation is used in temaseks kernel but i assume it's the original from
andreilux. in this implementation there is an additional touchboost switch which we removed in the boeffla
implementation. if i remember right this touchboost switch enabales hi frequency on touch. so your settings
might be overwritten by this.
Click to expand...
Click to collapse
Using max CPU freq at 1400 with lcdfreq freq threshold at 1300. Touch boost turned off.... Baffles me. I've also tryed setting max CPU freq to 1200 and lcdfreq freq threshold to 1300 because of something tema or yank said.. Can't remember what it was off hand.. I'll have a look back
TP.
core720 said:
the best is disable touchboost or enable=?
Click to expand...
Click to collapse
Zane
Enviado desde mi GT-I9300 usando Tapatalk 2
core720 said:
Zane
Enviado desde mi GT-I9300 usando Tapatalk 2
Click to expand...
Click to collapse
He answered you 3 posts up...
TP.
STAticKY said:
Using max CPU freq at 1400 with lcdfreq freq threshold at 1300. Touch boost turned off.... Baffles me. I've also tryed setting max CPU freq to 1200 and lcdfreq freq threshold to 1300 because of something tema or yank said.. Can't remember what it was off hand.. I'll have a look back
TP.
Click to expand...
Click to collapse
What Zane meant is that in Perseus, there was a touch boost for LCDfreq (I believe to remember sth like that at least), this has nothing to do with CPU touch boost. Whenever you touched the screen, LCDfreq would be bumped to 60Hz no matter what, with the idea to remove lags when actively using the device.
In case Temasek has that in his kernel, that would be something we do not have in either Boeffla nor mine ... LCDfreq scaling is purely based on the CPU freq (as per the tunables), touching the screen will not change anything in our implementation.
Might be worth checking...
JP.
Yank555 said:
What Zane meant is that in Perseus, there was a touch boost for LCDfreq (I believe to remember sth like that at least), this has nothing to do with CPU touch boost. Whenever you touched the screen, LCDfreq would be bumped to 60Hz no matter what, with the idea to remove lags when actively using the device.
In case Temasek has that in his kernel, that would be something we do not have in either Boeffla nor mine ... LCDfreq scaling is purely based on the CPU freq (as per the tunables), touching the screen will not change anything in our implementation.
Might be worth checking...
JP.
Click to expand...
Click to collapse
Yea I don't think he has that implemented. Upon touching the screen while benching, while its at 40hz it stays at 40hz
TP.
Hint! -> [ZIP] Synapse + Script => Universal Kernel Manager v2.4 for N4/N5/N7 (2013)
Hello,
I wanted to introduce you here a really great script! I use this script on both phones (N4&N5) ... it's really an ingenious piece of work. :good: I tested the script on the N5 with the UBER & Code Blue kernel. It will also/maybe work with other kernels, try it out! If something is missing -> just ask nice maybe the Dev can manage it!
I'm posting this here because the developer (apb_axel) of the script told me that I would be the only user of the N5 that answers / use it.
This is very unfortunate, so I thought, to post it for you here. (Yes've asked the developers for permission.)
The developer is really friendly and helpful. It's crazy how much time and patience he applied to help users or to reply. :highfive:
If you have any comments or wishes you can ask the developer.
[ZIP] Synapse + Script => Universal Kernel Manager v2.4
[ZIP] Synapse + Script => Universal Kernel Manager v2.4
Hello and welcome! So I started this because I hated having to have a different app to change some of the kernel settings and having init.d scripts for each kernel was a hassle to me, plus some users were having trouble with so many options available so I created this for all those who like to flash & test different kernels like me. I would like to dedicate this project of mine to my friend @ak for all the help and patience he has, he truly is a great dev and we owe him for some of the best kernels available for the Nexus 4.
So how this works is on every boot the script verifies all the tunables it finds specific for the kernel you have at the moment and generates the necessary files so it can be read & displayed on Synapse. Don't feel bad if you don't see all the listed options, it's just your kernel doesn't have those available.
In time I will be adding more scripts so we can have most, if not ALL tunables I can cram into. Hope you like it!
So what you need:
-Root (obviously)
-Working Busybox
-Your ROM has to support init.d scripts
-Synapse
Download Links:
Universal Kernel Manager v2.4
Synapse Google Play Link
UKM Uninstaller
To install:
-Reboot in recovery
-Flash the .zip (No cache/dalvik wipe necessary)
-Install Synapse
-You're done!
Click to expand...
Click to collapse
Features:
Info
General
Model Number
Android Version
Kernel Version
ROM Description
ROM Version
ROM Build Date
SOC Binning
Last KMSG
Status
Battery Temperature
CPU Temperature
Memory
Uptime
Unused CPU States
Time in state for CPUs
Kernel Wakelocks
CPU
Live CPU Frequency
CPU Min Frequency
CPU Max Frequency
CPU Max Screen Off Frequency
CPU Multicore Power Saving
CPU Governor
CPU Governor Options
CPU Governor Tunables
Hotplug
MPDecision (Qualcomm)
Intelliplug (faux123)
ECO Mode
Snakecharmer
Intellithermal
MSM MPDecision (show-p1984)
Screen off Single Core
Min CPUs
Max CPUs
Idle Frequency
Event Boost
MSM Hotplug (myfluxi)
Min CPUs
Max CPUs
Max CPUs Boosted
Boost Lock Duration
Down Lock Duration
History Size
Update Rate
Fast Lane Load
Offline Load
Suspend Frequency
Auto Hotplug (Thalamus)
Disable Load Threshold
Enable Load Threshold
Enable All Load Threshold
Min Sampling Rate
Sampling Periods
Min Online CPUs
Max Online CPUs
Dynamic Hotplug (stratosk)
Minimum Online CPU
Maximum Online CPU
Up Threshold
Up Timer Control
Down Timer Control
Alucard Hotplug (Alucard)
Hotplug Enable
Sampling Rate
Max Cores Limit
Max Cores Limit Sleep
CPU Down Rate
CPU Up Rate
Hotplug Loads
Hotplug RQs
Hotplug Frequencies
Mako Hotplug (franciscofranco)
Cores on touch
First Level
Suspend Frequency
CPU Boost Driver
Boost
Sync Threshold
Input Boost ms
Input Boost Frequency
CPU Voltage
Global Voltage
Frequency Voltage
AK
Faux
Semaphore
I/O Control
Read-ahead Size
I/O Scheduler
General I/O Tunables
I/O Scheduler Tunables
GPU
Live GPU Frequency
GPU Max Frequency
GPU Governor
Simple Governor Tunables
Interactive Governor Tunables
Gamma
Faux Gamma Profiles
Faux Gamma Tunables
Franco Gamma Tunables
Motley Gamma Tunables
LCD Backlight Tunables
Sound
Faux Sound Profiles
Faux Sound Tunables
Franco Sound Tunables
Speaker
Faux Speaker Profiles
Faux Speaker Tunables
Memory
Z-RAM
Virtual Memory
Wake Control
Apply at init.d
DoubleTap2Wake
Touch Wake
Sweep2Wake
Sweep2Sleep
Power Key Suspend
Miscellaneous
TCP Congestion Control
Temperature Control
Temperature Limit Minimum Frequency
Power Suspend State
FSYNC
Dynamic FSYNC
Vibrator Strength
USB Fast Charge
OTG
Battery Life Extender
Touchscreen Accuracy Filter
LED Control
Advanced
C-States
Kernel Samepage Merging (KSM)
Ultra Kernel Samepage Merging (UKSM)
Gentle Fair Sleepers
Low Memory Killer
Build.Prop
Wifi Scan Interval
VM Heapsize
Allow Purgeable Assets
DNS Tweaks
Tools
Toggle Bootloader Lockstate
Toggle Bootloader Tamper Flag
Toggle SELinux Status
Preferred Network Mode
Kernel Image Managment (Backup, Restore)
Log Creation (logcat, dmesg, last_ksmg)
Reboot
Profiles
Changelog:
v2.4
Fixed Wake Notifier bug.
Added Temp Threshold, New Faux Fast Charge.
Added GPU Min Freq.
Ability to set CPU settings for all Cores.
Increased CPU Frequency Poll (download the latest Synapse!).
Added Custom Gamma Profiles (Faux & Franco).
Added MSM Hotplug Load Levels, Fixed Fast Lane Load values.
v2.3
Integrated sqlite3
Fixed Interactive GPU (for good this time)
Added New Semaphore Tunables
Added Franco Hotplug Tunables
Added ability to apply wake options at init.d
Added UKSM Tunables
Added LED Control Tunables
v2.2
Fixed TWRP flash error
Fixed GPU Settings for supported devices
Fixed certain Hotplug settings not displaying
Fixed Live Wakelocks for devices without file
Added Interactive GPU tunables
Added Preferred Network Mode
v2.1
Lowered CPU & GPU refresh rate to display correct CPU & GPU frequency (tested with perfmon)
Fixed Restore Profiles (now checks .tgz first)
Fixed default CPU & GPU values in device config
Fixed incorrect devices parameters in live action
Added Power Suspend State (N5)
Fixed Franco Gamma, Added Franco Sound Tunables
v2.0
No longer N4 exclusive.
Re-coded entire script to support other devices (N4, N5 & N7 for now).
All commands are now called from internal busybox.
Optimized code (faster & less CPU usage).
Added Kernel Image Management (Backup, Restore & Delete).
Added Live Kernel Wakelocks.
v1.7
Integrated busybox for better support
Better way to fix permissions in CPU Frequencies
Fixed Faux Gamma Custom Profiles Link
Fixed Uptime, Unused, Time in State, CPU Freq & Bootloader displays
Fixed Bootloader Lock State. Added Tamper Flag & SELinux Toggles
Added Alucard & CPU Boost Hotplug
Added Allow Purgeable Assets (build.prop)
v1.6
Fix Conservative GPU governor error
Attempt to fix permissions in CPU Frequencies before opening app
Fixed MSM Hotplug display for HellsCore & HellsDoctor users
Added ability to name your backup in Profile
Added Semaphore Hotplug Tunables
Added New Tools Section (Bootloader Lock Status, Log Creation, etc.)
Added Franco Gamma Tunables, New Faux Gamma Profiles
Added Semaphore CPU Voltage Tunables
Added TouchScreen Accuracy Filter Tunables
v1.5
Better UCI support on certain ROMS
Fixed default CPU scaling & New CPU multicore tunable
Fixed display issue in live unused & time in states
More build.prop tweaks, New DNS tweaks
More MSM Hotplug & New Auto Hotplug Tunables
Added LCD Backlight
Added Temperature Limit Minimum Frequency
v1.4
Fixed permission issues in files
Added Fahrenheit Temps, CPU time in state
Added build.prop tweaks
Added Intellithermal Settings
Fixed ondemand sampling_rate_min error
v.1.3
Fixed interactive boostpulse error
Added Global CPU Offset Voltages
Added Faux Sound Settings
Added Live Status
v1.2
Added Faux Gamma Profiles & Tunables
Added Faux Speaker Profiles & Tunables
v.1.1
Fixed CPU live label
Added Profile Settings (For backup & restore)
v1.0
Initial Release
INFO:
Supported devices:
Nexus 4
Nexus 5
Nexus 7 (2013)
Tested kernels:
Should work on any kernel, but my personal tested kernels were the following:
AK
Faux
Matr1x
HellsCore
HellsDoctor
Semaphore
moob
dimfish
F.A.Q.
No UCI support detected? Check the following:
a) Does your ROM support init.d scripts?, IF it doesn't try this,
b) Check in /system/xbin if the uci file exists. IF it doesn't exists you can try reflashing the .zip or run the following in terminal emulator:
su
ln -s /data/N4UKM/uci /system/xbin/uci
c) Check the permissions of /system/xbin/uci AND /data/N4UKM/uci, it should be 755 or 777. IF it isn't you can try reflashing the .zip or run the following in terminal emulator:
su
chmod 755 /system/xbin/uci
chmod 755 /data/N4UKM/uci
d) Check the config.json file in /data/N4UKM/, if the file is blank you can try generating the file again with the following in terminal emulator:
su
uci reset
uci
IF NONE OF THE ABOVE WORKED FOR YOU send me a screenshot of your terminal emulator running the following command to determine your issue:
su
uci reset
uci
Happy testing! :silly:
Please do not forget to thank the developers that provide this damn brilliant piece of work!
@apb_axel
@ak
@AndreiLux
@osm0sis
....
P.S. This is not my "work / app / script"
I put it here just because I'm excited about it. But of course I'll try to help you, if you have questions. (As part of my knowledge)
Sry for my english, I slept in school and Google confuses me more than it helps!
Awesome work mate, going to test!
At last, the most complete kernel app I ever seen
You should post at my kernel thread so people can test!
That was my thought, too. I really have a lot of kernel app's bought but none is so "extensive". Sure, the "other kernel app's" are good, too. But not everyone has the opportunity to buy such app's.
And yes, I'll post in your thread the note to this script.
Nice one...
Gonna give it a try right now
Looks very cool... will take it for a spin!
galaxys said:
Looks very cool... will take it for a spin!
Click to expand...
Click to collapse
Hi guys, any bugs/new tunables you need just let me know, I'll try my best . And thanks to @MotoFlasher for starting this thread.
Looks good, will give it a try
Tapatalk Team SlimRoms
I need to fix a few things for N4 users now and then a new version of UKM will be uploaded.
Click to expand...
Click to collapse
http://forum.xda-developers.com/showpost.php?p=53427200&postcount=649
I can only agree with Nekator. apb_axel is faster than lightning!!!
It works pretty well on Nexus 5 with Uber. Thanks for sharing here!
In Sound tab I have Headphone PowerAmp set to -6 and it seems that I can't change this value.
A lot of useful tweaks into this app
noob question, please: how do i apply a color profile on synapse?
Hint! -> [ZIP] Synapse + Script => Universal Kernel Manager v2.4 for N4/N5/N7...
Stil waiting for update of synapse which fix the not saving speaker gain
Or is it fixed in ukm 3.4.2?
... Deleted...
Hey guys, I'm back with a new KERNEL for both Variants of the Tab S 10.5 (T800 and T805)!
Some guys probably know me from the IronRom . I decided myselfe to create a custom kernel for our really great Tab s 10.5, I'm getting better and better at this stuff, I don't thought that
It is basically the normal kernel with some modifications for better performance and hopefully also batterylife. It is for the stock kitkat (4.4.2) touchwiz and not for cyanogenmod or something else.
I excuse all devs here visiting my github page, it is such a mess (with the commits)! I know it, but I'm doing this the first time, so hopefully you will forgive me.
The kernel is pretty stable, I just call it a beta version, because I can't test the T800 version, so if with thisone also all works great -> stable
IF YOU FOLLOW MY STEPS BELOW, YOU WILL MAY LOSE YOUR WARRANTY, KNOX WILL DISPLAY 0x1! I'M NOT RESPONSIBLE FOR ANY DAMAGED DEVICE!
You can try to use the kernel adiutor app, or just the preinstalled sTweaks, but not both at the same time! This will cause problems.
Notice, V2.0 and onwards is only for TW lollipop and not for kitkat anymore!!
Features of my Kernel::- Built with latest 5.2 Toolchain compiled by myself!!
- Latest Kernel version 3.4.109, includes all updates from linux mainstream, patched it form 3.4.39 up to 3.4.109 (was a lot of work)
- Choose between different CPU governors: Interactive (default), Powersave, Performance, Userspace, Conservative, Intellidemand, Intelliactive, Ondemand, Adaptive, Abyssplug, AbyssplugV2, Badass, DanceDance, ZZmove, Nightmare, Wheatley, Lionheart, Darkness, PegasusQ and Intellimm
- Built with latest ramdisk sources from samsung
- Kernelsource from T805XXU1BOG2
- Underclock to 200MHz and Overclock to 2.0GHz
- GPU works from 100MHz to 733MHz (default)
- I/O schedulers: ROW (Default), cfq, No-op, Deadline, Test, BFQ, FIOPS, SIO, VR, ZEN, FIFO and SIOplus
- Readahead can be set
- UKSM (Ultar Kernel Samepage Merging)
- Gentlefairsleeper and ARCH power
- Android Logger
- data and cache f2fs support!
- Init.d Support
- Busybox support
- Full STweaks support
- Charging Control
- Cpufreq voltcontrol
- ZRam and Swap
- Allow ADB-Insecure
- Low Memory Kill
- TCP (Network) control: Cubic (default), Reno, Bic, Westwood, Highspeed, Hybla, HTCP, Vegas, Veno, Scalable, LP, Yeah and Illinois
- SeLinux is set to permissive
- Compiled as small as it could be (just around 6MB)
Download:In the second post
Googy Max STweaks
Bugs/Problems:-sTweaks can't enable the right GPU over and underclock freqency
-Some other stweaks stuff, you will see
-Didn't tried the voltage table
Instructions:
If you want to install the Kernel, follow this:
1. Install a custom recovery for your tablet, like this one here: TWRP Recovery
2. Follow the instructions on the page above, until you get a working recovery
3. Download the Kernel from below and copy it to your external SD Card
4. Reboot to your recovery by pressing volume up, home button and power button at the same time.
5. Install zip, and select the kernel
6. Wipe cache and dalvik cache (recommand)
7. Reboot
Support:If you like my work, please hit a thanks down on my posts. A thanks is enough!:highfive: If you really really really really really like my work, you can donate something to me, but it is not necessary. I created a paypal account, just in case, someone would give me a small donation. :good:
As I said, you don't have to give me something, but this keeps me motivated to built better roms and keep updating everything. It's your choice, and I'm very thankfull for every donation! No matter how big it is! Thank you so much for supporting me, cheers and have a nice day :fingers-crossed:
Donators for the Kernel:- @Hookmt Thank you very much for your support giving to me! I really love that and it also wasn't the first time you donate something to me! Thank you so much, I really really really appreciat that mate. Transaction number: 42P214019W495221S
Credits/Thanks:- Samsung for sources
- @Christopher83 for the compiler
- @UpInTheAir for the work he already did in his own kernel (could use some of his commits on github (opensource) and see what he did when I didn't know what I did wrong). He also inspired me to work on my own stuff and kernel, thank you very much!
- @googy_anas, without him, I would not have a working kernel here, he did so much for me and also for his own kernel! He
let me use everything he already did, I got so much stuff from his page and included it in my kernel. I'm so thankfull for all the support he gave to me! I know a thank you isn't enough, but I wanted to write it here.
- @googy_anas (again this great man!) and @kryten2k35 thank you so much for let me using your stweaks app! Great work you have done on thatone!
- @faux123 for all the great stuff he did for the kernels
- @Yank555
If you want to take my work and need it somewhere, or do other things with it, please ask me first for the permission. Otherwise you are not allowed to take it! Thank you !
XDA:DevDB Information
Stock Based Kernel for Tab S 10.5, Kernel for the Samsung Galaxy Tab S
Contributors
Tkkg1994, @googy_anas
Source Code: https://github.com/Tkkg1994/IronKernel
Kernel Special Features:
Version Information
Status: Stable
Current Stable Version: V2.5
Stable Release Date: 2015-10-13
Current Beta Version: 1.0
Beta Release Date: 2015-02-19
Created 2015-02-20
Last Updated 2015-10-12
Changelog:
Kitkat
IronKernel Beta V1.0 on 20.02.2015:
Initial release!
Ironkernel V1.1 26.02.2015:
-Temporarly removed Intelli-Plug
-Added voltcontroll for CPU
-Added Stweaks support and Stweaks app (all credits and stuff goes to @googy_anas and @Kryten2k35
-Hell lot of improvements
-Init.d support and busybox support
-GPU overclock to 733MHz
-CPU overclock to 2.1GHz (sorry, I couldn't get it stable )
-for more what I had done, visit here: Commits IronKernel
-Added fast charge support
IronKernel V1.2 01.03.2015:
- Built with latest toolchain (2015.02) by christopher83
- Use frandom from now
- Enable dynamic page writeback with earlysuspend
- Better battery charging control (kernel and stweaks)
- Auto install the right sTweaks version
- Reduce overestimating rq->avg_idle
- Optimize find_busiest_queue()
- Some CPUfreq optimizations
- Dynamic sync control with earlysuspend support
- Lowmemorykiller: implement task's adj rbtree
- Check free memory when tasks switch to background
- Dynamic FSync
- SOO Much more but I don't remember all
- After flashing the kernel, it will be successfull, but then show an error (becaus of mounting partition) don't worry, just reboot. Just ignore it
Changelog V1.3.5 08.03.15:
- Prerelease of V1.3 was on the ironrom
- Script auto-removes all knox containors/apps
- cpufreq: Retain only online cpus in managed_policy->cpus
- cpufreq: make the "scaling_cur_freq" sysfs entry pollable
- cpufreq: Make the "scaling_governor" sysfs node pollable
- cpufreq: Save and restore min and max frequencies
- fix some missing stuff with default governor
- cpufreq: Notify governors when cpus are hot-[un]plugged
- Updated nightmare and zzmoove governors
- net: ipv6: Add a sysctl to make optimistic addresses useful candidates
- fs/proc/task_mmu.c: add user-space support for resetting mm
- net: ipv6: allow choosing optimistic addresses with use_optimistic
- sched/idle: Avoid spurious wakeup IPIs
- cpufreq: Return directly in __cpufreq_get if policy is NULL
- new relation between governors
- ARM: 8226/1: cacheflush: get rid of restarting block
Changelog V1.4 23.03.15:
- It is simply to much to write everything here.. what I did
- Wolfson Control for the sound on our Tab S
- Added voltage control (doesen't work 100%)
- sched: Add an rq migration call-back to sched_class
- sched: Account for blocked load waking back up …
- sched: Normalize tg load contributions against runnable time
- sched: Refactor update_shares_cpu() -> update_blocked_avgs()
- sched/fair: Set se->vruntime directly in place_entity()
- sched: provide per cpu-cgroup option to notify on migrations
- sched: Make sure to not re-read variables after validation
- sched: Add WAKEUP_PREEMPTION feature flag, on by default
And this goes on for like 2 or 3 pages lol So the changelog is tooooooo long.
Lollipop
Changelog V2.0 10.04.15:
- Full lollipop compatible! (not with kitkat anymore!)
- Support CIFS
- Overclock to 2.0 GHz (other will be back soon)
- Include all features of all previous releases! Such as stweask, overclocked gpu etc.
- Based on latest samsung opensource T800XXU1BOCC
Was a lot of work to port all to Lollipop
If you got problems with sTweaks showing "loaded", but nothing happen, go to a root explorer, navigate to system/xbin, copy Busybox and past it in /sbin direction!
Changelog V2.1 16.05.15:
- Fix stweaks problems
- Voltage is still NOT working
- add tripndroid scheduler
- add row scheduler
- add and enable UKSM (ultra kernel samepage merging)
- update ramdisk to latest versions
- f2fs
- update linux to 3.4.107
- more stuff I may forgot
Changelog V2.2 08.07.15:
- Update to latest linux mainstream (3.4.108)
- Updated ramdisk source to OE3
- New source patches from official kernel opensource center (samsung)
- this does only work on the newer bases, as BOE3, the old ones will get a bootloop!
Changelog V2.2.5 16.07.15:
- Fixed "slow" charging (Thanks to AndreiLux and UpInTheAir!)
- Incrased sound so it will be a louder by default
- Some other small ramdisk fixes
Changelog V2.3 08.09.15:
- Kernel Rebased on latest OG2 kernel source
- Fix some heating issues that where reported
- Ramdisk update to OG2
- Fully support f2fs in /data and /cache
- Build with latest 4.9.4 toolchain
Changelog V2.4 05.10.15:
- Update to 5.2 toolchain compiled by myself!
- updated to 3.4.109 linux
- ftrace: Make all inline tags also include notrace
- compiler-gcc4.h: correct verion check for __compiletime_error
- compiler.h: add __visible
- compiler{,-gcc4}.h, bug.h: Remove duplicate macros
- some more optimisations concerning compiler
- msm: cpufreq: Only apply driver limits for scaling_min/max_freq writes
- drivers: cpufreq: Send a uevent when governor changes
- cpufreq: Save user policy min/max instead of policy min/max during hotplug
- cpufreq: Fix broken uevents for cpufreq governor and cpu devices
- cpufreq: Always allow update of user policy
- drivers: cpufreq: Upstream optimizations
- cpufreq: Export user_policy min/max
- cpufreq: Add policy notifiers
- cpufreq: Simplify cpufreq_add_dev()
- some more cpufreq things that I made
- cpufreq_stats: do not remove sysfs files if frequency table is not present
- sched/numa: Rewrite the CONFIG_NUMA sched domain support
- sched/numa: Fix the new NUMA topology bits
- sched/numa: Don't scale the imbalance
- sched/debug: Fix printing large integers on 32-bit platforms
- sched: Remove stale power aware scheduling remnants and dysfunctional knobs
- f2fs: update to latest version
- tima debug log disabled
- uksm: disabled by default
Changelog V2.5 13.10.15:
- enabled tima debug again
- fixed some Random reboots people had
- added pegasusq cpugovernor
- arm/crypto: Add optimized AES and SHA1 routines
- added cifs, nfs, exportfs, cdrom, all ramdisk support (joystick too)
- ARM: 7626/1: arm/crypto: Make asm SHA-1 and AES code Thumb-2 compatible
- ARM: 7723/1: crypto: sha1-armv4-large.S: fix SP handling
- ARM: 8119/1: crypto: sha1: add ARM NEON implementation
- ARM: 8120/1: crypto: sha512: add ARM NEON implementation
- a lot of other crypto optimisations (like 10 patches)
- cpufreq: Move get_cpu_idle_time() to cpufreq.c
- workqueue: set delayed_work->timer function on initialization
- workqueue: don't use WQ_HIGHPRI for unbound workqueues
- workqueue: factor out worker_pool from global_cwq
- workqueue: use @pool instead of @gcwq or @Cpu where applicable
- workqueue: separate out worker_pool flags
- workqueue: introduce NR_WORKER_POOLS and for_each_worker_pool()
- workqueue: reimplement WQ_HIGHPRI using a separate worker_pool
- hashtable: introduce a small and naive hashtable
- workqueue: use new hashtable implementation
- workqueue: drop @bind from create_worker()
- much more workqueue updates, to see them all, please visit here: Github Kernel Updates
Governors and I/O Scheduler:
Original Thread: Governor Explained, all credits go to @stempox
1: OnDemand
2: OndemandX
3: Performance
4: Powersave
5: Conservative
6: Userspace
7: Min Max
8: Interactive
9: InteractiveX
10: Smartass
11: SmartassV2
12: Scary
13: Lagfree
14: Smoothass
15: Brazilianwax
16: SavagedZen
17: Lazy
18: Lionheart
19: LionheartX
20: Intellidemand
21: Hotplug
22: BadAss
23: Wheatley
24: Lulzactive
25: Pegasusq/Pegasusd
26: hotplugx
27: AbissPlug
28: MSM DCVS
29: IntelliActive
30: Adaptive
31: Nightmare
32: ZZmove
1: OnDemand Governor:
This governor has a hair trigger for boosting clockspeed to the maximum speed set by the user. If the CPU load placed by the user abates, the OnDemand governor will slowly step back down through the kernel's frequency steppings until it settles at the lowest possible frequency, or the user executes another task to demand a ramp.
OnDemand has excellent interface fluidity because of its high-frequency bias, but it can also have a relatively negative effect on battery life versus other governors. OnDemand is commonly chosen by smartphone manufacturers because it is well-tested, reliable, and virtually guarantees the smoothest possible performance for the phone. This is so because users are vastly more likely to ***** about performance than they are the few hours of extra battery life another governor could have granted them.
This final fact is important to know before you read about the Interactive governor: OnDemand scales its clockspeed in a work queue context. In other words, once the task that triggered the clockspeed ramp is finished, OnDemand will attempt to move the clockspeed back to minimum. If the user executes another task that triggers OnDemand's ramp, the clockspeed will bounce from minimum to maximum. This can happen especially frequently if the user is multi-tasking. This, too, has negative implications for battery life.
2: OndemandX:
Basically an ondemand with suspend/wake profiles. This governor is supposed to be a battery friendly ondemand. When screen is off, max frequency is capped at 500 mhz. Even though ondemand is the default governor in many kernel and is considered safe/stable, the support for ondemand/ondemandX depends on CPU capability to do fast frequency switching which are very low latency frequency transitions. I have read somewhere that the performance of ondemand/ondemandx were significantly varying for different i/o schedulers. This is not true for most of the other governors. I personally feel ondemand/ondemandx goes best with SIO I/O scheduler.
3: Performance Governor:
This locks the phone's CPU at maximum frequency. While this may sound like an ugly idea, there is growing evidence to suggest that running a phone at its maximum frequency at all times will allow a faster race-to-idle. Race-to-idle is the process by which a phone completes a given task, such as syncing email, and returns the CPU to the extremely efficient low-power state. This still requires extensive testing, and a kernel that properly implements a given CPU's C-states (low power states).
4: Powersave Governor:
The opposite of the Performance governor, the Powersave governor locks the CPU frequency at the lowest frequency set by the user.
5:Conservative Governor:
This biases the phone to prefer the lowest possible clockspeed as often as possible. In other words, a larger and more persistent load must be placed on the CPU before the conservative governor will be prompted to raise the CPU clockspeed. Depending on how the developer has implemented this governor, and the minimum clockspeed chosen by the user, the conservative governor can introduce choppy performance. On the other hand, it can be good for battery life.
The Conservative Governor is also frequently described as a "slow OnDemand," if that helps to give you a more complete picture of its functionality.
6: Userspace Governor:
This governor, exceptionally rare for the world of mobile devices, allows any program executed by the user to set the CPU's operating frequency. This governor is more common amongst servers or desktop PCs where an application (like a power profile app) needs privileges to set the CPU clockspeed.
7: Min Max
well this governor makes use of only min & maximum frequency based on workload... no intermediate frequencies are used.
8: Interactive Governor:
Much like the OnDemand governor, the Interactive governor dynamically scales CPU clockspeed in response to the workload placed on the CPU by the user. This is where the similarities end. Interactive is significantly more responsive than OnDemand, because it's faster at scaling to maximum frequency.
Unlike OnDemand, which you'll recall scales clockspeed in the context of a work queue, Interactive scales the clockspeed over the course of a timer set arbitrarily by the kernel developer. In other words, if an application demands a ramp to maximum clockspeed (by placing 100% load on the CPU), a user can execute another task before the governor starts reducing CPU frequency. This can eliminate the frequency bouncing discussed in the OnDemand section. Because of this timer, Interactive is also better prepared to utilize intermediate clockspeeds that fall between the minimum and maximum CPU frequencies. This is another pro-battery life benefit of Interactive.
However, because Interactive is permitted to spend more time at maximum frequency than OnDemand (for device performance reasons), the battery-saving benefits discussed above are effectively negated. Long story short, Interactive offers better performance than OnDemand (some say the best performance of any governor) and negligibly different battery life.
Interactive also makes the assumption that a user turning the screen on will shortly be followed by the user interacting with some application on their device. Because of this, screen on triggers a ramp to maximum clockspeed, followed by the timer behavior described above.
9: InteractiveX Governor:
Created by kernel developer "Imoseyon," the InteractiveX governor is based heavily on the Interactive governor, enhanced with tuned timer parameters to better balance battery vs. performance. The InteractiveX governor's defining feature, however, is that it locks the CPU frequency to the user's lowest defined speed when the screen is off.
10: Smartass
Is based on the concept of the interactive governor.
I have always agreed that in theory the way interactive works – by taking over the idle loop – is very attractive. I have never managed to tweak it so it would behave decently in real life. Smartass is a complete rewrite of the code plus more. I think its a success. Performance is on par with the “old” minmax and I think smartass is a bit more responsive. Battery life is hard to quantify precisely but it does spend much more time at the lower frequencies.
Smartass will also cap the max frequency when sleeping to 352Mhz (or if your min frequency is higher than 352 – why?! – it will cap it to your min frequency). Lets take for example the 528/176 kernel, it will sleep at 352/176. No need for sleep profiles any more!"
11: SmartassV2:
Version 2 of the original smartass governor from Erasmux. Another favorite for many a people. The governor aim for an "ideal frequency", and ramp up more aggressively towards this freq and less aggressive after. It uses different ideal frequencies for screen on and screen off, namely awake_ideal_freq and sleep_ideal_freq. This governor scales down CPU very fast (to hit sleep_ideal_freq soon) while screen is off and scales up rapidly to awake_ideal_freq (500 mhz for GS2 by default) when screen is on. There's no upper limit for frequency while screen is off (unlike Smartass). So the entire frequency range is available for the governor to use during screen-on and screen-off state. The motto of this governor is a balance between performance and battery.
12: Scary
A new governor wrote based on conservative with some smartass features, it scales accordingly to conservatives laws. So it will start from the bottom, take a load sample, if it's above the upthreshold, ramp up only one speed at a time, and ramp down one at a time. It will automatically cap the off screen speeds to 245Mhz, and if your min freq is higher than 245mhz, it will reset the min to 120mhz while screen is off and restore it upon screen awakening, and still scale accordingly to conservatives laws. So it spends most of its time at lower frequencies. The goal of this is to get the best battery life with decent performance. It will give the same performance as conservative right now, it will get tweaked over time.
13: Lagfree:
Lagfree is similar to ondemand. Main difference is it's optimization to become more battery friendly. Frequency is gracefully decreased and increased, unlike ondemand which jumps to 100% too often. Lagfree does not skip any frequency step while scaling up or down. Remember that if there's a requirement for sudden burst of power, lagfree can not satisfy that since it has to raise cpu through each higher frequency step from current. Some users report that video playback using lagfree stutters a little.
14: Smoothass:
The same as the Smartass “governor” But MUCH more aggressive & across the board this one has a better battery life that is about a third better than stock KERNEL
15: Brazilianwax:
Similar to smartassV2. More aggressive ramping, so more performance, less battery
16: SavagedZen:
Another smartassV2 based governor. Achieves good balance between performance & battery as compared to brazilianwax.
17: Lazy:
This governor from Ezekeel is basically an ondemand with an additional parameter min_time_state to specify the minimum time CPU stays on a frequency before scaling up/down. The Idea here is to eliminate any instabilities caused by fast frequency switching by ondemand. Lazy governor polls more often than ondemand, but changes frequency only after completing min_time_state on a step overriding sampling interval. Lazy also has a screenoff_maxfreq parameter which when enabled will cause the governor to always select the maximum frequency while the screen is off.
18: Lionheart:
Lionheart is a conservative-based governor which is based on samsung's update3 source.
The tunables (such as the thresholds and sampling rate) were changed so the governor behaves more like the performance one, at the cost of battery as the scaling is very aggressive.
19: LionheartX
LionheartX is based on Lionheart but has a few changes on the tunables and features a suspend profile based on Smartass governor.
20: Intellidemand:
Intellidemand aka Intelligent Ondemand from Faux is yet another governor that's based on ondemand. Unlike what some users believe, this governor is not the replacement for OC Daemon (Having different governors for sleep and awake). The original intellidemand behaves differently according to GPU usage. When GPU is really busy (gaming, maps, benchmarking, etc) intellidemand behaves like ondemand. When GPU is 'idling' (or moderately busy), intellidemand limits max frequency to a step depending on frequencies available in your device/kernel for saving battery. This is called browsing mode. We can see some 'traces' of interactive governor here. Frequency scale-up decision is made based on idling time of CPU. Lower idling time (<20%) causes CPU to scale-up from current frequency. Frequency scale-down happens at steps=5% of max frequency. (This parameter is tunable only in conservative, among the popular governors)
To sum up, this is an intelligent ondemand that enters browsing mode to limit max frequency when GPU is idling, and (exits browsing mode) behaves like ondemand when GPU is busy; to deliver performance for gaming and such. Intellidemand does not jump to highest frequency when screen is off.
21: Hotplug Governor:
The Hotplug governor performs very similarly to the OnDemand governor, with the added benefit of being more precise about how it steps down through the kernel's frequency table as the governor measures the user's CPU load. However, the Hotplug governor's defining feature is its ability to turn unused CPU cores off during periods of low CPU utilization. This is known as "hotplugging."
22: BadAss Governor:
Badass removes all of this "fast peaking" to the max frequency. On a typical system the cpu won't go above 918Mhz and therefore stay cool and will use less power. To trigger a frequency increase, the system must run a bit @ 918Mhz with high load, then the frequency is bumped to 1188Mhz. If that is still not enough the governor gives you full throttle. (this transition should not take longer than 1-2 seconds, depending on the load your system is experiencing)
Badass will also take the gpu load into consideration. If the gpu is moderately busy it will bypass the above check and clock the cpu with 1188Mhz. If the gpu is crushed under load, badass will lift the restrictions to the cpu.
23: Wheatley:
Building on the classic 'ondemand' governor is implemented Wheatley governor. The governor has two additional parameters:
target_residency - The minimum average residency in µs which is considered acceptable for a proper efficient usage of the C4 state. Default is 10000 = 10ms.
allowed_misses - The number sampling intervals in a row the average residency is allowed to be lower than target_residency before the governor reduces the frequency. This ensures that the governor is not too aggressive in scaling down the frequency and reduces it just because some background process was temporarily causing a larger number of wakeups. The default is 5.
Wheatley works as planned and does not hinder the proper C4 usage for task where the C4 can be used properly .
For internet browsing the time spend in C4 has increased by 10% points and the average residency has increased by about 1ms. I guess these differences are mostly due to the different browsing behaviour (I spend the last time more multi-tabbing). But at least we can say that Wheatley does not interfere with the proper use of the C4 state during 'light' tasks. For music playback with screen off the time spend in C4 is practically unchanged, however the average residency is reduced from around 30ms to around 18ms, but this is still more than acceptable.
So the results show that Wheatley works as intended and ensures that the C4 state is used whenever the task allows a proper efficient usage of the C4 state. For more demanding tasks which cause a large number of wakeups and prevent the efficient usage of the C4 state, the governor resorts to the next best power saving mechanism and scales down the frequency. So with the new highly-flexible Wheatley governor one can have the best of both worlds.
Obviously, this governor is only available on multi-core devices.
24: Lulzactive:
Lulzactive:
This new find from Tegrak is based on Interactive & Smartass governors and is one of the favorites.
Old Version: When workload is greater than or equal to 60%, the governor scales up CPU to next higher step. When workload is less than 60%, governor scales down CPU to next lower step. When screen is off, frequency is locked to global scaling minimum frequency.
New Version: Three more user configurable parameters: inc_cpu_load, pump_up_step, pump_down_step. Unlike older version, this one gives more control for the user. We can set the threshold at which governor decides to scale up/down. We can also set number of frequency steps to be skipped while polling up and down.
When workload greater than or equal to inc_cpu_load, governor scales CPU pump_up_step steps up. When workload is less than inc_cpu_load, governor scales CPU down pump_down_step steps down.
Example:
Consider
inc_cpu_load=70
pump_up_step=2
pump_down_step=1
If current frequency=200, Every up_sampling_time Us if cpu load >= 70%, cpu is scaled up 2 steps - to 800.
If current frequency =1200, Every down_sampling_time Us if cpu load < 70%, cpu is scaled down 1 step - to 1000.
25: Pegasusq/Pegasusd
The Pegasus-q / d is a multi-core based on the Ondemand governor and governor with integrated hot-plugging.
Ongoing processes in the queue, we know that multiple processes can run simultaneously on. These processes are active in an array, which is a field called "Run Queue" queue that is ongoing, with their priority values arranged (priority will be used by the task scheduler, which then decides which process to run next).
To ensure that each process has its fair share of resources, each running for a certain period and will eventually stop and then again placed in the queue until it is your turn again. If a program is terminated, so that others can run the program with the highest priority in the current queue is executed.
26: hotplugx
It 'a Hotplug modified and optimized for the suspension in off-screen
27: AbissPlug
It 'a Governor derived hotplug, it works the same way, but with the changes in savings for a better battery.
28: MSM DCVS
a very efficient and wide range of Dynamic Clock and
Voltage Scaling (DCVS) which addresses usage models from
active standby to mid and high level processing requirements.
A Krait CPU can smoothly scale from low power, low
leakage mode to blazingly fast performance.
Believe it's a governor that is mfg'd by qualcomm to utilize new on chip features.
MSM is the prefix for the SOC (MSM8960) and DCVS is Dynamic Clock and Voltage Scaling. Makes sense, MSM-DCVS
29: IntelliActive
Based off Google's Interactive governor with the following enhancements:
1. self-boost capability from input drivers (no need for PowerHAL assist)
2. two phase scheduling (idle/busy phases to prevent from jumping directly to max freq
3. Checks for offline cpus and short circuits some unnecessary checks to improve code execution paths
30: Adaptive
This driver adds a dynamic cpufreq policy governor
designed for latency-sensitive workloads and also for demanding
performance.
This governor attempts to reduce the latency of clock
increases so that the system is more responsive to
interactive workloads in loweset steady-state but to
to reduce power consumption in middle operation level level up
will be done in step by step to prohibit system from going to
max operation level.
31: Nightmare
A PegasusQ modified, less aggressive and more stable. A good compromise between performance and battery.
In addition to the SoD is a prevention because it usually does not hotplug.
32: ZZmove
ZZmove Governor optimized for low power consumption with the screen off, with particular attention to the limitation of consumption applications in the background with the screen off, such as listening to music. It has three settings: battery saver, balanced and performance. In addition to a performance boost, there is also the governor zzmove optimized.
I/O Scheduler: Thread:I/O Scheduler explained
The Scheduler is an algorithm that, given a set of requests for access to a resource, establishing a temporal order for the execution of such requests, favoring those that meet certain criteria in order to optimize access to that resource.
The difference between the various scheduler is the focus on certain criteria rather than on others.
The choice of a given scheduler does not produce visible changes so as to the choice of the governor, but still provides some improvements.
As usual schedulers are personally tested to find one that best suits your needs.
Deadline
It aims to provide a deadline, a deadline for all requests in order to avoid undesirable phenomena such as the "starvation" or the eternal waiting for some requests that occurs when one or more background processes are left indefinitely in the queue the ready, because there is always at least one of the highest priority ready process.
V (r)
The next request is performed according to the distance from the last request. In the network running good opinions about this scheduler.
No-op
Push all requests in a single queue simply by their arrival order, grouping together those contiguous.
SIO
E 'the scheduler simpler, does not make any type of sort, is intended only for the purpose of obtaining a low-latency, ie to reduce the amount of time that elapses between the instant at which the request is generated and that in which the request is satisfied.
CFQ
Order requests of different processes in queues for each queue type and assigns a specific interval of time whose duration depends on the priorities assigned to processes. Can be considered the Ondemand the scheduler, the scheduler is in fact more balanced, doing its job in an honest manner.
BFQ
It 's based on CFQ but, instead of the intervals of time, assigns a part of the bandwidth of the disc to each process running in a proportional manner.
Anticipatory
Order requests based on criteria predictive, that puts the demands paused for a short period of time in anticipation that more of this to come to aggregate them.
ADAPTIVE ANTICIPATORY SCHEDULER
For the anticipatory scheduler, we scale up the anticipation timeout (antic expire) using the latency scaling factor over time. When the virtual disk latencies are low a small scaling of the timeout is sucient to prevent deceptive idleness, whereas when the latencies are high a larger scaling of the timeout value may be required to achieve the same. Note that such dynamic setting of the timeout value ensures that we attain a good trade-o between throughput (lost due to idling) and deceptive idleness mitigation. Setting a high value for the scaling factor (increasing idling time) only happens when the disk service latencies themselves are higher. This may not necessarily cause a signicant loss in throughput, because submitting a request from another process instead of idling is not going to improve throughput if the virtual disk itself does not get any faster than it is at the current period. A higher anticipation timeout might also be capable of absorbing process scheduling eects inside the VM. The results for the adaptive anticipatory scheduler are shown in Figure 2. The read time with our modied implementation (third bar in the dierent scheduler combinations) shows that it is possible to mitigate the eects of deceptive idleness by adapting the timeout. An interesting related observation is that the level to which the improve- ment is possible varies for dierent Domain-0 schedulers; noop - 39%, anticipatory - 67% and cfq - 36%. This again points to the fact that the I/O scheduler used in Domain-0 is important for the VM's ability in enforcing I/O scheduling guarantees. Dierent Domain-0 I/O schedulers likely have a dierent service latency footprint inside the VMs, contributing to dierent levels of improvement.
ROW
Row stands for READ Over WRITE which is the main requests dispatch policy of this algorithm. The ROW IO scheduler was developed with the mobile devices needs in mind. In mobile devices we favor user experience upon everything else, thus we want to give READ IO requests as much priority as possible. In mobile devices we won't have as much parallel threads as on desktops. Usually it's a single thread or at most 2 simultaneous working threads for read & write. Favoring READ requests over WRITEs decreases the READ latency greatly.
The main idea of the ROW scheduling policy is: If there are READ requests in pipe - dispatch them but don't starve the WRITE requests too much. Bellow you'll find a small comparison of ROW to existing schedulers. The test that was run for these measurements is parallel read and write.
FIOS
Flash-based solid-state drives (SSDs) have the potential to eliminate the I/O bottlenecks in data-intensive applications However the large performance discrepancy between Flash reads and writes introduces challenges for fair resource usage. Further, existing fair queuing and quanta-based I/O schedulers poorly manage the I/O anticipation for Flash I/O fairness and efficiency. Some also suppress the I/O parallelism which causes substantial performance degradation on Flash. This paper develops FIOS, a new Flash I/O scheduler that attains fairness and high efficiency at the same time. FIOS employs a fair I/O time-slice management with mechanisms for read preference, parallelism, and fairness-oriented I/O anticipation. Evaluation demonstrates that FIOS achieves substantially better fairness and efficiency compared to the Linux CFQ scheduler, the SFQ(D) fair queuing scheduler, and the Argon quanta-based scheduler on several Flash-based storage devices (including a CompactFlash card in a low-power wimpy node). In particular, FIOS reduces the worst-case slowdown bya factor of 2.3 or more when the read-only SPECweb workload runs together with the write-intensive TPC
Sweet! In terms of battery life, did it improve for you? You made one of the best TW roms and now this great job!
DUHAsianSKILLZ said:
Sweet! In terms of battery life, did it improve for you? You made one of the best TW roms and now this great job!
Click to expand...
Click to collapse
Thank you! I think we have less devs here in Tab S section, so I have to do something here
I couldn't test the batterylife till now, I was testing whole 2 weeks to get the kernel working (got holidays) So I will report you back!
Intelli-Plug speeks for better batterylife, it shuts down 3 cores if they are not needed (screen off = only 1 core working with 200Mhz or something)
Tkkg1994 said:
Thank you! I think we have less devs here in Tab S section, so I have to do something here
I couldn't test the batterylife till now, I was testing whole 2 weeks to get the kernel working (got holidays) So I will report you back!
Intelli-Plug speeks for better batterylife, it shuts down 3 cores if they are not needed (screen off = only 1 core working with 200Mhz or something)
Click to expand...
Click to collapse
Thanks! Ill downgrade tommrow or so back to kitkat and try xnote rom. I can try your kernel when I do that.
DUHAsianSKILLZ said:
Thanks! Ill downgrade tommrow or so back to kitkat and try xnote rom. I can try your kernel when I do that.
Click to expand...
Click to collapse
Always a pleasure to have you as a user!
Not the ironrom
Wrong thread
Mokum020 said:
Thank you for your great work (again)!
Your kernel is running perfect here on T805 with X-Note.
would love to be able to try 2.1/2.2Ghz, 2.1Ghz is no problem for my Tab S with SkyHigh.
View attachment 3174370View attachment 3174371
Click to expand...
Click to collapse
I always make kind of a "stresstest" for the CPU freq. I set min freq to 2.1GHz and max freq to 2.1GHz. Than see what happen. I couldn't get it stable enough for daily use, but if I can, I will enable 2.1GHz for sure
Confirmed working on the T800 with xnote rom.
DUHAsianSKILLZ said:
Confirmed working on the T800 with xnote rom.
Click to expand...
Click to collapse
Thank you for testing
I added a description of governors and I/O schedulers above
To install this with Ironrom, should I do anything with Synapse first to either return settings to default or uninstall? Or should I reflash IronRom, leaving out Synapse in Aroma and then flash the new kernel? I plan on trying Kernel Auditor.
Also, will you be adding this kernel to the aroma options soon (or are you waiting for more testing to come in)?
Hookmt said:
To install this with Ironrom, should I do anything with Synapse first to either return settings to default or uninstall? Or should I reflash IronRom, leaving out Synapse in Aroma and then flash the new kernel? I plan on trying Kernel Auditor.
Also, will you be adding this kernel to the aroma options soon (or are you waiting for more testing to come in)?
Click to expand...
Click to collapse
The kernel doesn' support synapse. You can just uninstall it if you like to and than install your kernel auditor.
Yes it will come to aroma soon, I'm waiting for samsung to release a new base for T800
And yes, testing is always welcome
Can you include some tips for let's say performance settings, battery settings, both battery and performance settings etc. I'm still testing a few things too, but can't figure out the best battery settings in faux.
DUHAsianSKILLZ said:
Can you include some tips for let's say performance settings, battery settings, both battery and performance settings etc. I'm still testing a few things too, but can't figure out the best battery settings in faux.
Click to expand...
Click to collapse
Intelli-plug, KSM enabled, Governor... I would say intellimm is good for battery but a bit slow. Interactive with intelliplug is nice
With Stweaks Support does the Kernel support BLN (blinking Soft Keys)? God, this would be awesome!!
If not, could you create a Custom Kernel with this Feature?
haselchen said:
With Stweaks Support does the Kernel support BLN (blinking Soft Keys)? God, this would be awesome!!
If not, could you create a Custom Kernel with this Feature?
Click to expand...
Click to collapse
If you would have read correctly, you will see that I'm currently adding sTweaks support. And it don't supports it now, but seems like a good idea!
Please realize this idea
Tkkg1994, this is what I call a very promising start.
Detailed walkthrough, FAQ style, and a very interesting feature rich kernel... I'm on CM12 right now, but already eager to try this in the coming days with IronRom, of course.
A Big Thanks from the other side of the world... Porto, Portugal.
Tkkg1994 said:
Intelli-plug, KSM enabled, Governor... I would say intellimm is good for battery but a bit slow. Interactive with intelliplug is nice
Click to expand...
Click to collapse
IntellIplug is nice but sometimes you cant turn the tablet on when it's enabled. I even set the screen off frequency to something above 200mhz. I had to force reboot a couple times. Did you managed to get it work? I even tryed all the profiles including balanced etc and also changing the governer. For now I'll keep it off but battery seems good so far!
Hey guys, I'm back with a new KERNEL for both Variants of the Tab S 8.4 (T700 and T705)!
Some guys probably know me from the IronRom . I decided myselfe to create a custom kernel for our really great Tab s 8.4, I'm getting better and better at this stuff, I don't thought that
It is basically the normal kernel with some modifications for better performance and hopefully also batterylife. It is for the stock kitkat (4.4.2) touchwiz and not for cyanogenmod or something else.
I excuse all devs here visiting my github page, it is such a mess (with the commits)! I know it, but I'm doing this the first time, so hopefully you will forgive me.
The kernel is pretty stable, I just call it a beta version, because I can't test the T700 and T705 version, so if with thisone also all works great -> stable
IF YOU FOLLOW MY STEPS BELOW, YOU WILL MAY LOSE YOUR WARRANTY, KNOX WILL DISPLAY 0x1! I'M NOT RESPONSIBLE FOR ANY DAMAGED DEVICE!
You can try to use the kernel adiutor app, or just the preinstalled sTweaks, but not both at the same time! This will cause problems.
Features of my Kernel::- Built with latest Linaro Toolchain 4.9.3 made by christopher83
- Latest Kernel version 3.4.109, includes all important linux patches, patched it form 3.4.39 up to 3.4.109 (was a lot of work)
- Choose between different CPU governors: Interactive (default), Powersave, Performance, Userspace, Conservative, Intellidemand, Intelliactive, Ondemand, Adaptive, Abyssplug, AbyssplugV2, Badass, DanceDance, ZZmove, Nightmare, Wheatley, Lionheart, Darkness, PegasusQ and Intellimm
- Built with latest ramdisk sources from samsung
- Kernelsource from T805XXU1BOG2
- Underclock to 200MHz and Overclock to 2.0GHz
- GPU works from 100MHz to 733MHz (default)
- I/O schedulers: ROW (Default), CFQ, No-op, Deadline, Test, BFQ, FIOPS, SIO, VR, ZEN, FIFO and SIOplus
- Readahead can be set
- KSM (Kernel Samepage Merging)
- Gentlefairsleeper and ARCH power
- Android Logger
- Init.d Support
- data and cache f2fs support!
- Busybox support
- Full STweaks support
- Charging Control
- Cpufreq voltcontrol
- ZRam and Swap
- Allow ADB-Insecure
- Low Memory Kill
- TCP (Network) control: Cubic (default), Reno, Bic, Westwood, Highspeed, Hybla, HTCP, Vegas, Veno, Scalable, LP, Yeah and Illinois
- SeLinux is set to permissive
- Compiled as small as it could be (just around 6MB)
Download:In the second post
Googy-Max STweaks
Bugs/Problems:-sTweaks can't enable the right GPU over and underclock freqency
-Some other stweaks stuff, you will see
-Didn't tried the voltage table
Instructions:
If you want to install the Kernel, follow this:
1. Install a custom recovery for your tablet, like this one here: TWRP Recovery
2. Follow the instructions on the page above, until you get a working recovery
3. Download the Kernel from below and copy it to your external SD Card
4. Reboot to your recovery by pressing volume up, home button and power button at the same time.
5. Install zip, and select the kernel
6. Wipe cache and dalvik cache (recommand)
7. Reboot
Support:If you like my work, please hit a thanks down on my posts. A thanks is enough!:highfive: If you really really really really really like my work, you can donate something to me, but it is not necessary. I created a paypal account, just in case, someone would give me a small donation. :good:
As I said, you don't have to give me something, but this keeps me motivated to built better roms and keep updating everything. It's your choice, and I'm very thankfull for every donation! No matter how big it is! Thank you so much for supporting me, cheers and have a nice day :fingers-crossed:
Donators for the Kernel:
Credits/Thanks:- Samsung for sources
- @Christopher83 for the compiler
- @UpInTheAir for the work he already did in his own kernel (could use some of his commits on github (opensource) and see what he did when I didn't know what I did wrong). He also inspired me to work on my own stuff and kernel, thank you very much!
- @googy_anas, without him, I would not have a working kernel here, he did so much for me and also for his own kernel! He
let me use everything he already did, I got so much stuff from his page and included it in my kernel. I'm so thankfull for all the support he gave to me! I know a thank you isn't enough, but I wanted to write it here.
- @googy_anas (again ) and @kryten2k35 for the great stweaks app and that I can use your modification in the app (I don't edited it) Thank you so much!
- @faux123 for all the great stuff he did for the kernels
- @Yank555
- @AndreiLux
- @Halaszk87
If you want to take my work and need it somewhere, or do other things with it, please ask me first for the permission. Otherwise you are not allowed to take it! Thank you !
XDA:DevDB Information
Stock Based Kernel for Tab S 8.4, Kernel for the Samsung Galaxy Tab S
Contributors
Tkkg1994, @googy_anas
Source Code: https://github.com/Tkkg1994/IronKernel
Kernel Special Features:
Version Information
Status: Stable
Current Stable Version: V2.5
Stable Release Date: 2015-10-13
Current Beta Version: 1.0
Beta Release Date: 2015-02-20
Created 2015-02-20
Last Updated 2015-10-12
Changelog:
Kitkat
Ironkernel Beta V1.0 20.02.2015:
- Initial Release!
Ironkernel V1.1 26.02.2015:
-Temporarly removed Intelli-Plug
-Added voltcontroll for CPU
-Added Stweaks support and Stweaks app (all credits and stuff goes to @googy_anas and @Kryten2k35
-Hell lot of improvements
-Init.d support and busybox support
-GPU overclock to 733MHz
-CPU overclock to 2.1GHz (sorry, I couldn't get it stable )
-Fast charge control
-for more what I had done, visit here: Commits IronKernel
IronKernel V1.2 01.03.2015:
- Built with latest toolchain (2015.02) by christopher83
- Use frandom from now
- Enable dynamic page writeback with earlysuspend
- Better battery charging control (kernel and stweaks)
- Auto install the right sTweaks version
- Reduce overestimating rq->avg_idle
- Optimize find_busiest_queue()
- Some CPUfreq optimizations
- Dynamic sync control with earlysuspend support
- Lowmemorykiller: implement task's adj rbtree
- Check free memory when tasks switch to background
- Dynamic FSync
- SOO Much more but I don't remember all
- After flashing the kernel, it will be successfull, but then show an error (becaus of mounting partition) don't worry, just reboot. Just ignore it
Changelog V1.3.5 08.03.15:
- Prerelease of V1.3 was on the ironrom
- Script auto-removes all knox containors/apps
- cpufreq: Retain only online cpus in managed_policy->cpus
- cpufreq: make the "scaling_cur_freq" sysfs entry pollable
- cpufreq: Make the "scaling_governor" sysfs node pollable
- cpufreq: Save and restore min and max frequencies
- fix some missing stuff with default governor
- cpufreq: Notify governors when cpus are hot-[un]plugged
- Updated nightmare and zzmoove governors
- net: ipv6: Add a sysctl to make optimistic addresses useful candidates
- fs/proc/task_mmu.c: add user-space support for resetting mm
- net: ipv6: allow choosing optimistic addresses with use_optimistic
- sched/idle: Avoid spurious wakeup IPIs
- cpufreq: Return directly in __cpufreq_get if policy is NULL
- new relation between governors
- ARM: 8226/1: cacheflush: get rid of restarting block
Changelog V1.4 23.03.15:
- It is simply to much to write everything here.. what I did
- Wolfson Control for the sound on our Tab S
- Added voltage control (doesen't work 100%)
- sched: Add an rq migration call-back to sched_class
- sched: Account for blocked load waking back up …
- sched: Normalize tg load contributions against runnable time
- sched: Refactor update_shares_cpu() -> update_blocked_avgs()
- sched/fair: Set se->vruntime directly in place_entity()
- sched: provide per cpu-cgroup option to notify on migrations
- sched: Make sure to not re-read variables after validation
- sched: Add WAKEUP_PREEMPTION feature flag, on by default
And this goes on for like 2 or 3 pages lol So the changelog is tooooooo long.
Lollipop
Changelog V2.0 08.07.15:
- @Richcar confirmed that it works (trust him )
- updated to linux 3.4.108 mainstream
- f2fs update
- add tripndroid scheduler
- add row scheduler
- add and enable UKSM (ultra kernel samepage merging)
- update ramdisk to latest versions
- more things I may forgot
- ONLY for touchwiz lollipop! You MUST have a EO3 base or higher (your rom)
Changelog V2.0.5 16.07.15:
- Fixed "slow" charging (Thanks to AndreiLux and UpInTheAir!)
- Incrased sound so it will be a louder by default
- Some other small ramdisk fixes
- Update to OF1 and OF2 ramdisk
- You have to be on latest samsung based roms (as OEx or OFx) otherwise not booting!
Changelog V2.5 13.10.15:
- Merged latest OG2 source, adapted by OE9 source from T705, fully rebased kernel!
- Update to 5.2 toolchain compiled by myself!
- this kernel is now up-to-date with T800/T805 kernel!
- updated to 3.4.109 linux
- ftrace: Make all inline tags also include notrace
- compiler-gcc4.h: correct verion check for __compiletime_error
- compiler.h: add __visible
- compiler{,-gcc4}.h, bug.h: Remove duplicate macros
- some more optimisations concerning compiler
- msm: cpufreq: Only apply driver limits for scaling_min/max_freq writes
- drivers: cpufreq: Send a uevent when governor changes
- cpufreq: Save user policy min/max instead of policy min/max during hotplug
- cpufreq: Fix broken uevents for cpufreq governor and cpu devices
- cpufreq: Always allow update of user policy
- drivers: cpufreq: Upstream optimizations
- cpufreq: Export user_policy min/max
- cpufreq: Add policy notifiers
- cpufreq: Simplify cpufreq_add_dev()
- some more cpufreq things that I made
- cpufreq_stats: do not remove sysfs files if frequency table is not present
- sched/numa: Rewrite the CONFIG_NUMA sched domain support
- sched/numa: Fix the new NUMA topology bits
- sched/numa: Don't scale the imbalance
- sched/debug: Fix printing large integers on 32-bit platforms
- sched: Remove stale power aware scheduling remnants and dysfunctional knobs
- f2fs: update to latest version
- uksm: disabled by default
- fixed some Random reboots people had
- added pegasusq cpugovernor
- arm/crypto: Add optimized AES and SHA1 routines
- added cifs, nfs, exportfs, cdrom, all ramdisk support (joystick too)
- ARM: 7626/1: arm/crypto: Make asm SHA-1 and AES code Thumb-2 compatible
- ARM: 7723/1: crypto: sha1-armv4-large.S: fix SP handling
- ARM: 8119/1: crypto: sha1: add ARM NEON implementation
- ARM: 8120/1: crypto: sha512: add ARM NEON implementation
- a lot of other crypto optimisations (like 10 patches)
- cpufreq: Move get_cpu_idle_time() to cpufreq.c
- workqueue: set delayed_work->timer function on initialization
- workqueue: don't use WQ_HIGHPRI for unbound workqueues
- workqueue: factor out worker_pool from global_cwq
- workqueue: use @pool instead of @gcwq or @Cpu where applicable
- workqueue: separate out worker_pool flags
- workqueue: introduce NR_WORKER_POOLS and for_each_worker_pool()
- workqueue: reimplement WQ_HIGHPRI using a separate worker_pool
- hashtable: introduce a small and naive hashtable
- workqueue: use new hashtable implementation
- workqueue: drop @bind from create_worker()
- much more workqueue updates, to see them all, please visit here: Github Kernel Updates
Governors and I/O Scheduler:
Original Thread: Governor Explained, all credits go to @stempox
1: OnDemand
2: OndemandX
3: Performance
4: Powersave
5: Conservative
6: Userspace
7: Min Max
8: Interactive
9: InteractiveX
10: Smartass
11: SmartassV2
12: Scary
13: Lagfree
14: Smoothass
15: Brazilianwax
16: SavagedZen
17: Lazy
18: Lionheart
19: LionheartX
20: Intellidemand
21: Hotplug
22: BadAss
23: Wheatley
24: Lulzactive
25: Pegasusq/Pegasusd
26: hotplugx
27: AbissPlug
28: MSM DCVS
29: IntelliActive
30: Adaptive
31: Nightmare
32: ZZmove
1: OnDemand Governor:
This governor has a hair trigger for boosting clockspeed to the maximum speed set by the user. If the CPU load placed by the user abates, the OnDemand governor will slowly step back down through the kernel's frequency steppings until it settles at the lowest possible frequency, or the user executes another task to demand a ramp.
OnDemand has excellent interface fluidity because of its high-frequency bias, but it can also have a relatively negative effect on battery life versus other governors. OnDemand is commonly chosen by smartphone manufacturers because it is well-tested, reliable, and virtually guarantees the smoothest possible performance for the phone. This is so because users are vastly more likely to ***** about performance than they are the few hours of extra battery life another governor could have granted them.
This final fact is important to know before you read about the Interactive governor: OnDemand scales its clockspeed in a work queue context. In other words, once the task that triggered the clockspeed ramp is finished, OnDemand will attempt to move the clockspeed back to minimum. If the user executes another task that triggers OnDemand's ramp, the clockspeed will bounce from minimum to maximum. This can happen especially frequently if the user is multi-tasking. This, too, has negative implications for battery life.
2: OndemandX:
Basically an ondemand with suspend/wake profiles. This governor is supposed to be a battery friendly ondemand. When screen is off, max frequency is capped at 500 mhz. Even though ondemand is the default governor in many kernel and is considered safe/stable, the support for ondemand/ondemandX depends on CPU capability to do fast frequency switching which are very low latency frequency transitions. I have read somewhere that the performance of ondemand/ondemandx were significantly varying for different i/o schedulers. This is not true for most of the other governors. I personally feel ondemand/ondemandx goes best with SIO I/O scheduler.
3: Performance Governor:
This locks the phone's CPU at maximum frequency. While this may sound like an ugly idea, there is growing evidence to suggest that running a phone at its maximum frequency at all times will allow a faster race-to-idle. Race-to-idle is the process by which a phone completes a given task, such as syncing email, and returns the CPU to the extremely efficient low-power state. This still requires extensive testing, and a kernel that properly implements a given CPU's C-states (low power states).
4: Powersave Governor:
The opposite of the Performance governor, the Powersave governor locks the CPU frequency at the lowest frequency set by the user.
5:Conservative Governor:
This biases the phone to prefer the lowest possible clockspeed as often as possible. In other words, a larger and more persistent load must be placed on the CPU before the conservative governor will be prompted to raise the CPU clockspeed. Depending on how the developer has implemented this governor, and the minimum clockspeed chosen by the user, the conservative governor can introduce choppy performance. On the other hand, it can be good for battery life.
The Conservative Governor is also frequently described as a "slow OnDemand," if that helps to give you a more complete picture of its functionality.
6: Userspace Governor:
This governor, exceptionally rare for the world of mobile devices, allows any program executed by the user to set the CPU's operating frequency. This governor is more common amongst servers or desktop PCs where an application (like a power profile app) needs privileges to set the CPU clockspeed.
7: Min Max
well this governor makes use of only min & maximum frequency based on workload... no intermediate frequencies are used.
8: Interactive Governor:
Much like the OnDemand governor, the Interactive governor dynamically scales CPU clockspeed in response to the workload placed on the CPU by the user. This is where the similarities end. Interactive is significantly more responsive than OnDemand, because it's faster at scaling to maximum frequency.
Unlike OnDemand, which you'll recall scales clockspeed in the context of a work queue, Interactive scales the clockspeed over the course of a timer set arbitrarily by the kernel developer. In other words, if an application demands a ramp to maximum clockspeed (by placing 100% load on the CPU), a user can execute another task before the governor starts reducing CPU frequency. This can eliminate the frequency bouncing discussed in the OnDemand section. Because of this timer, Interactive is also better prepared to utilize intermediate clockspeeds that fall between the minimum and maximum CPU frequencies. This is another pro-battery life benefit of Interactive.
However, because Interactive is permitted to spend more time at maximum frequency than OnDemand (for device performance reasons), the battery-saving benefits discussed above are effectively negated. Long story short, Interactive offers better performance than OnDemand (some say the best performance of any governor) and negligibly different battery life.
Interactive also makes the assumption that a user turning the screen on will shortly be followed by the user interacting with some application on their device. Because of this, screen on triggers a ramp to maximum clockspeed, followed by the timer behavior described above.
9: InteractiveX Governor:
Created by kernel developer "Imoseyon," the InteractiveX governor is based heavily on the Interactive governor, enhanced with tuned timer parameters to better balance battery vs. performance. The InteractiveX governor's defining feature, however, is that it locks the CPU frequency to the user's lowest defined speed when the screen is off.
10: Smartass
Is based on the concept of the interactive governor.
I have always agreed that in theory the way interactive works – by taking over the idle loop – is very attractive. I have never managed to tweak it so it would behave decently in real life. Smartass is a complete rewrite of the code plus more. I think its a success. Performance is on par with the “old” minmax and I think smartass is a bit more responsive. Battery life is hard to quantify precisely but it does spend much more time at the lower frequencies.
Smartass will also cap the max frequency when sleeping to 352Mhz (or if your min frequency is higher than 352 – why?! – it will cap it to your min frequency). Lets take for example the 528/176 kernel, it will sleep at 352/176. No need for sleep profiles any more!"
11: SmartassV2:
Version 2 of the original smartass governor from Erasmux. Another favorite for many a people. The governor aim for an "ideal frequency", and ramp up more aggressively towards this freq and less aggressive after. It uses different ideal frequencies for screen on and screen off, namely awake_ideal_freq and sleep_ideal_freq. This governor scales down CPU very fast (to hit sleep_ideal_freq soon) while screen is off and scales up rapidly to awake_ideal_freq (500 mhz for GS2 by default) when screen is on. There's no upper limit for frequency while screen is off (unlike Smartass). So the entire frequency range is available for the governor to use during screen-on and screen-off state. The motto of this governor is a balance between performance and battery.
12: Scary
A new governor wrote based on conservative with some smartass features, it scales accordingly to conservatives laws. So it will start from the bottom, take a load sample, if it's above the upthreshold, ramp up only one speed at a time, and ramp down one at a time. It will automatically cap the off screen speeds to 245Mhz, and if your min freq is higher than 245mhz, it will reset the min to 120mhz while screen is off and restore it upon screen awakening, and still scale accordingly to conservatives laws. So it spends most of its time at lower frequencies. The goal of this is to get the best battery life with decent performance. It will give the same performance as conservative right now, it will get tweaked over time.
13: Lagfree:
Lagfree is similar to ondemand. Main difference is it's optimization to become more battery friendly. Frequency is gracefully decreased and increased, unlike ondemand which jumps to 100% too often. Lagfree does not skip any frequency step while scaling up or down. Remember that if there's a requirement for sudden burst of power, lagfree can not satisfy that since it has to raise cpu through each higher frequency step from current. Some users report that video playback using lagfree stutters a little.
14: Smoothass:
The same as the Smartass “governor” But MUCH more aggressive & across the board this one has a better battery life that is about a third better than stock KERNEL
15: Brazilianwax:
Similar to smartassV2. More aggressive ramping, so more performance, less battery
16: SavagedZen:
Another smartassV2 based governor. Achieves good balance between performance & battery as compared to brazilianwax.
17: Lazy:
This governor from Ezekeel is basically an ondemand with an additional parameter min_time_state to specify the minimum time CPU stays on a frequency before scaling up/down. The Idea here is to eliminate any instabilities caused by fast frequency switching by ondemand. Lazy governor polls more often than ondemand, but changes frequency only after completing min_time_state on a step overriding sampling interval. Lazy also has a screenoff_maxfreq parameter which when enabled will cause the governor to always select the maximum frequency while the screen is off.
18: Lionheart:
Lionheart is a conservative-based governor which is based on samsung's update3 source.
The tunables (such as the thresholds and sampling rate) were changed so the governor behaves more like the performance one, at the cost of battery as the scaling is very aggressive.
19: LionheartX
LionheartX is based on Lionheart but has a few changes on the tunables and features a suspend profile based on Smartass governor.
20: Intellidemand:
Intellidemand aka Intelligent Ondemand from Faux is yet another governor that's based on ondemand. Unlike what some users believe, this governor is not the replacement for OC Daemon (Having different governors for sleep and awake). The original intellidemand behaves differently according to GPU usage. When GPU is really busy (gaming, maps, benchmarking, etc) intellidemand behaves like ondemand. When GPU is 'idling' (or moderately busy), intellidemand limits max frequency to a step depending on frequencies available in your device/kernel for saving battery. This is called browsing mode. We can see some 'traces' of interactive governor here. Frequency scale-up decision is made based on idling time of CPU. Lower idling time (<20%) causes CPU to scale-up from current frequency. Frequency scale-down happens at steps=5% of max frequency. (This parameter is tunable only in conservative, among the popular governors)
To sum up, this is an intelligent ondemand that enters browsing mode to limit max frequency when GPU is idling, and (exits browsing mode) behaves like ondemand when GPU is busy; to deliver performance for gaming and such. Intellidemand does not jump to highest frequency when screen is off.
21: Hotplug Governor:
The Hotplug governor performs very similarly to the OnDemand governor, with the added benefit of being more precise about how it steps down through the kernel's frequency table as the governor measures the user's CPU load. However, the Hotplug governor's defining feature is its ability to turn unused CPU cores off during periods of low CPU utilization. This is known as "hotplugging."
22: BadAss Governor:
Badass removes all of this "fast peaking" to the max frequency. On a typical system the cpu won't go above 918Mhz and therefore stay cool and will use less power. To trigger a frequency increase, the system must run a bit @ 918Mhz with high load, then the frequency is bumped to 1188Mhz. If that is still not enough the governor gives you full throttle. (this transition should not take longer than 1-2 seconds, depending on the load your system is experiencing)
Badass will also take the gpu load into consideration. If the gpu is moderately busy it will bypass the above check and clock the cpu with 1188Mhz. If the gpu is crushed under load, badass will lift the restrictions to the cpu.
23: Wheatley:
Building on the classic 'ondemand' governor is implemented Wheatley governor. The governor has two additional parameters:
target_residency - The minimum average residency in µs which is considered acceptable for a proper efficient usage of the C4 state. Default is 10000 = 10ms.
allowed_misses - The number sampling intervals in a row the average residency is allowed to be lower than target_residency before the governor reduces the frequency. This ensures that the governor is not too aggressive in scaling down the frequency and reduces it just because some background process was temporarily causing a larger number of wakeups. The default is 5.
Wheatley works as planned and does not hinder the proper C4 usage for task where the C4 can be used properly .
For internet browsing the time spend in C4 has increased by 10% points and the average residency has increased by about 1ms. I guess these differences are mostly due to the different browsing behaviour (I spend the last time more multi-tabbing). But at least we can say that Wheatley does not interfere with the proper use of the C4 state during 'light' tasks. For music playback with screen off the time spend in C4 is practically unchanged, however the average residency is reduced from around 30ms to around 18ms, but this is still more than acceptable.
So the results show that Wheatley works as intended and ensures that the C4 state is used whenever the task allows a proper efficient usage of the C4 state. For more demanding tasks which cause a large number of wakeups and prevent the efficient usage of the C4 state, the governor resorts to the next best power saving mechanism and scales down the frequency. So with the new highly-flexible Wheatley governor one can have the best of both worlds.
Obviously, this governor is only available on multi-core devices.
24: Lulzactive:
Lulzactive:
This new find from Tegrak is based on Interactive & Smartass governors and is one of the favorites.
Old Version: When workload is greater than or equal to 60%, the governor scales up CPU to next higher step. When workload is less than 60%, governor scales down CPU to next lower step. When screen is off, frequency is locked to global scaling minimum frequency.
New Version: Three more user configurable parameters: inc_cpu_load, pump_up_step, pump_down_step. Unlike older version, this one gives more control for the user. We can set the threshold at which governor decides to scale up/down. We can also set number of frequency steps to be skipped while polling up and down.
When workload greater than or equal to inc_cpu_load, governor scales CPU pump_up_step steps up. When workload is less than inc_cpu_load, governor scales CPU down pump_down_step steps down.
Example:
Consider
inc_cpu_load=70
pump_up_step=2
pump_down_step=1
If current frequency=200, Every up_sampling_time Us if cpu load >= 70%, cpu is scaled up 2 steps - to 800.
If current frequency =1200, Every down_sampling_time Us if cpu load < 70%, cpu is scaled down 1 step - to 1000.
25: Pegasusq/Pegasusd
The Pegasus-q / d is a multi-core based on the Ondemand governor and governor with integrated hot-plugging.
Ongoing processes in the queue, we know that multiple processes can run simultaneously on. These processes are active in an array, which is a field called "Run Queue" queue that is ongoing, with their priority values arranged (priority will be used by the task scheduler, which then decides which process to run next).
To ensure that each process has its fair share of resources, each running for a certain period and will eventually stop and then again placed in the queue until it is your turn again. If a program is terminated, so that others can run the program with the highest priority in the current queue is executed.
26: hotplugx
It 'a Hotplug modified and optimized for the suspension in off-screen
27: AbissPlug
It 'a Governor derived hotplug, it works the same way, but with the changes in savings for a better battery.
28: MSM DCVS
a very efficient and wide range of Dynamic Clock and
Voltage Scaling (DCVS) which addresses usage models from
active standby to mid and high level processing requirements.
A Krait CPU can smoothly scale from low power, low
leakage mode to blazingly fast performance.
Believe it's a governor that is mfg'd by qualcomm to utilize new on chip features.
MSM is the prefix for the SOC (MSM8960) and DCVS is Dynamic Clock and Voltage Scaling. Makes sense, MSM-DCVS
29: IntelliActive
Based off Google's Interactive governor with the following enhancements:
1. self-boost capability from input drivers (no need for PowerHAL assist)
2. two phase scheduling (idle/busy phases to prevent from jumping directly to max freq
3. Checks for offline cpus and short circuits some unnecessary checks to improve code execution paths
30: Adaptive
This driver adds a dynamic cpufreq policy governor
designed for latency-sensitive workloads and also for demanding
performance.
This governor attempts to reduce the latency of clock
increases so that the system is more responsive to
interactive workloads in loweset steady-state but to
to reduce power consumption in middle operation level level up
will be done in step by step to prohibit system from going to
max operation level.
31: Nightmare
A PegasusQ modified, less aggressive and more stable. A good compromise between performance and battery.
In addition to the SoD is a prevention because it usually does not hotplug.
32: ZZmove
ZZmove Governor optimized for low power consumption with the screen off, with particular attention to the limitation of consumption applications in the background with the screen off, such as listening to music. It has three settings: battery saver, balanced and performance. In addition to a performance boost, there is also the governor zzmove optimized.
I/O Scheduler: Thread:I/O Scheduler explained
The Scheduler is an algorithm that, given a set of requests for access to a resource, establishing a temporal order for the execution of such requests, favoring those that meet certain criteria in order to optimize access to that resource.
The difference between the various scheduler is the focus on certain criteria rather than on others.
The choice of a given scheduler does not produce visible changes so as to the choice of the governor, but still provides some improvements.
As usual schedulers are personally tested to find one that best suits your needs.
Deadline
It aims to provide a deadline, a deadline for all requests in order to avoid undesirable phenomena such as the "starvation" or the eternal waiting for some requests that occurs when one or more background processes are left indefinitely in the queue the ready, because there is always at least one of the highest priority ready process.
V (r)
The next request is performed according to the distance from the last request. In the network running good opinions about this scheduler.
No-op
Push all requests in a single queue simply by their arrival order, grouping together those contiguous.
SIO
E 'the scheduler simpler, does not make any type of sort, is intended only for the purpose of obtaining a low-latency, ie to reduce the amount of time that elapses between the instant at which the request is generated and that in which the request is satisfied.
CFQ
Order requests of different processes in queues for each queue type and assigns a specific interval of time whose duration depends on the priorities assigned to processes. Can be considered the Ondemand the scheduler, the scheduler is in fact more balanced, doing its job in an honest manner.
BFQ
It 's based on CFQ but, instead of the intervals of time, assigns a part of the bandwidth of the disc to each process running in a proportional manner.
Anticipatory
Order requests based on criteria predictive, that puts the demands paused for a short period of time in anticipation that more of this to come to aggregate them.
ADAPTIVE ANTICIPATORY SCHEDULER
For the anticipatory scheduler, we scale up the anticipation timeout (antic expire) using the latency scaling factor over time. When the virtual disk latencies are low a small scaling of the timeout is sucient to prevent deceptive idleness, whereas when the latencies are high a larger scaling of the timeout value may be required to achieve the same. Note that such dynamic setting of the timeout value ensures that we attain a good trade-o between throughput (lost due to idling) and deceptive idleness mitigation. Setting a high value for the scaling factor (increasing idling time) only happens when the disk service latencies themselves are higher. This may not necessarily cause a signicant loss in throughput, because submitting a request from another process instead of idling is not going to improve throughput if the virtual disk itself does not get any faster than it is at the current period. A higher anticipation timeout might also be capable of absorbing process scheduling eects inside the VM. The results for the adaptive anticipatory scheduler are shown in Figure 2. The read time with our modied implementation (third bar in the dierent scheduler combinations) shows that it is possible to mitigate the eects of deceptive idleness by adapting the timeout. An interesting related observation is that the level to which the improve- ment is possible varies for dierent Domain-0 schedulers; noop - 39%, anticipatory - 67% and cfq - 36%. This again points to the fact that the I/O scheduler used in Domain-0 is important for the VM's ability in enforcing I/O scheduling guarantees. Dierent Domain-0 I/O schedulers likely have a dierent service latency footprint inside the VMs, contributing to dierent levels of improvement.
ROW
Row stands for READ Over WRITE which is the main requests dispatch policy of this algorithm. The ROW IO scheduler was developed with the mobile devices needs in mind. In mobile devices we favor user experience upon everything else, thus we want to give READ IO requests as much priority as possible. In mobile devices we won't have as much parallel threads as on desktops. Usually it's a single thread or at most 2 simultaneous working threads for read & write. Favoring READ requests over WRITEs decreases the READ latency greatly.
The main idea of the ROW scheduling policy is: If there are READ requests in pipe - dispatch them but don't starve the WRITE requests too much. Bellow you'll find a small comparison of ROW to existing schedulers. The test that was run for these measurements is parallel read and write.
FIOS
Flash-based solid-state drives (SSDs) have the potential to eliminate the I/O bottlenecks in data-intensive applications However the large performance discrepancy between Flash reads and writes introduces challenges for fair resource usage. Further, existing fair queuing and quanta-based I/O schedulers poorly manage the I/O anticipation for Flash I/O fairness and efficiency. Some also suppress the I/O parallelism which causes substantial performance degradation on Flash. This paper develops FIOS, a new Flash I/O scheduler that attains fairness and high efficiency at the same time. FIOS employs a fair I/O time-slice management with mechanisms for read preference, parallelism, and fairness-oriented I/O anticipation. Evaluation demonstrates that FIOS achieves substantially better fairness and efficiency compared to the Linux CFQ scheduler, the SFQ(D) fair queuing scheduler, and the Argon quanta-based scheduler on several Flash-based storage devices (including a CompactFlash card in a low-power wimpy node). In particular, FIOS reduces the worst-case slowdown bya factor of 2.3 or more when the read-only SPECweb workload runs together with the write-intensive TPC
Can't wait to try this out on my t700
You might want to amend your OP. If you study the source code a little more and try understand things. You'll find there are no (actual) A7 100 MHz. A7 cores freq are doubled 100-650 (become 200-1300) MHz. A15 cores 800-1900+. Samsung have done it this way for IKS to work easily.
Some CPU control apps will just read the table but not able to differentiate between the A7 and A15 cores, and just display what's read from the frequency table.
You've made a good start, but 99% over those governors aren't suitable and/or optimized for Exynos. A "shotgun" approach isn't always the best way, but hey, this is your toy.
UpInTheAir said:
You might want to amend your OP. If you study the source code a little more and try understand things. You'll find there are no (actual) A7 100 MHz. A7 cores freq are doubled 100-650 (become 200-1300) MHz. A15 cores 800-1900+. Samsung have done it this way for IKS to work easily.
Some CPU control apps will just read the table but not able to differentiate between the A7 and A15 cores, and just display what's read from the frequency table.
You've made a good start, but 99% over those governors aren't suitable and/or optimized for Exynos. A "shotgun" approach isn't always the best way, but hey, this is your toy.
Click to expand...
Click to collapse
Now I understand that a little bit more. Because I added first a 100MHz support and added all stuff to get it work and than, it displayed me 50MHz and I thought, what the heck is going wrong here?
So I removed it again. Thank you for helping out here.
Suitable are they, but optimized not at the moment. You know, otherwise I wont have work left
And that's also why I call it a beta version at the moment.
Tkkg1994 said:
Now I understand that a little bit more. Because I added first a 100MHz support and added all stuff to get it work and than, it displayed me 50MHz and I thought, what the heck is going wrong here?
So I removed it again. Thank you for helping out here.
Suitable are they, but optimized not at the moment. You know, otherwise I wont have work left
And that's also why I call it a beta version at the moment.
Click to expand...
Click to collapse
No, a lot are not suitable, as they are written for krait SoC (4 main cores), just like intelli-plug etc. I found they were more of a hassle and eroded kernel stability, hence I never committed the changes for release. You might find otherwise, so no harm to try. Can be fun, and also a headache too
Snapdragon 810 will be using big.LITTLE architecture same as Exynos, so hopefully faux will port some of his work over. Although it will be HMP, maybe we can adapt to our IKS kernel.
UpInTheAir said:
No, a lot are not suitable, as they are written for krait SoC (4 main cores), just like intelli-plug etc. I found they were more of a hassle and eroded kernel stability, hence I never committed the changes for release. You might find otherwise, so no harm to try. Can be fun, and also a headache too
Snapdragon 810 will be using big.LITTLE architecture same as Exynos, so hopefully faux will port some of his work over. Although it will be HMP, maybe we can adapt to our IKS kernel.
Click to expand...
Click to collapse
Nobody says that we can't port it to 8 cores you know, it is a lot of work for sure, but not impossible.
I barely had problems with the governors, more with intelliplug.
But I think it is good that we don't have the same opinion.
Otherwise we would have 2 similar kernels here.
Tkkg1994 said:
Nobody says that we can't port it to 8 cores you know, it is a lot of work for sure, but not impossible.
I barely had problems with the governors, more with intelliplug.
But I think it is good that we don't have the same opinion.
Otherwise we would have 2 similar kernels here.
Click to expand...
Click to collapse
I don't think you understand me yet. We use IKS and 4 cores at once big.LITTLE . NOT HMP (all cores running). If you study the governors and what exactly the frequency/cores are actually doing in real time, you will find out and learn from it ... Just because something compiles and are able to switch between variables, does not make it compatible.
I never said or implied that anything was impossible, but you need to re-write (not adapt) a lot of code. In effect, create a "new" governor. This is fact, not my opinion
Best of luck with your project, keep at it !
UpInTheAir said:
I don't think you understand me yet. We use IKS and 4 cores at once big.LITTLE . NOT HMP (all cores running). If you study the governors and what exactly the frequency/cores are actually doing in real time, you will find out and learn from it ... Just because something compiles and are able to switch between variables, does not make it compatible.
I never said or implied that anything was impossible, but you need to re-write (not adapt) a lot of code. In effect, create a "new" governor. This is fact, not my opinion
Best of luck with your project, keep at it !
Click to expand...
Click to collapse
I read the wiki article
I think our Exynos5 5420 use HMP and can use all cores together if it uses it?
I was talking about the intelli-plug stuff not the governors. I hope samsung will release a S6 with exynos (only) and than we will get more support.
If you want to talk with me (and yes I like to) than PM?
Tkkg1994 said:
I read the wiki article
I think our Exynos5 5420 use HMP and can use all cores together if it uses it?
I was talking about the intelli-plug stuff not the governors. I hope samsung will release a S6 with exynos (only) and than we will get more support.
If you want to talk with me (and yes I like to) than PM?
Click to expand...
Click to collapse
Keep reading and learning Particularly what IKS is and does. Please don't take this the wrong way, this is relevant and you really need to learn how the basics of our 5420 kernel actually work.
There have been test HMP for Exynos 5420, BUT, no Android powered Exynos 5420 is ever capable of HMP. AndreiLux has explained why in various posts.
HMP kernels (such as I'm using with my Note Edge Skyhigh kernel) is completely different, but some things might be adapted with little work.
I just don't have the time to answer or clarify every single question (I don't pretend to always know), even by PM. It's just a matter of reading, learning, and trial by many errors.
UpInTheAir said:
Keep reading and learning Particularly what IKS is and does. Please don't take this the wrong way, this is relevant and you really need to learn how the basics of our 5420 kernel actually work.
There have been test HMP for Exynos 5420, BUT, no Android powered Exynos 5420 is ever capable of HMP. AndreiLux has explained why in various posts.
HMP kernels (such as I'm using with my Note Edge Skyhigh kernel) is completely different, but some things might be adapted with little work.
I just don't have the time to answer or clarify every single question (I don't pretend to always know), even by PM. It's just a matter of reading, learning, and trial by many errors.
Click to expand...
Click to collapse
I'm doing this the first time, so hopefully you and the others will understand that. I hope you can excuse me I have to learn many things I know that.
See you soon!
Changelog V1.1:
-Temporarly removed Intelli-Plug
-Added voltcontroll for CPU
-Added Stweaks support and Stweaks app (all credits and stuff goes to @googy_anas and @Kryten2k35
-Hell lot of improvements
-GPU overclock to 733MHz
-CPU overclock to 2.1GHz (sorry, I couldn't get it stable )
-for more what I had done, visit here: Commits IronKernel
Tkkg1994 said:
-Temporarly removed Intelli-Plug
-Added voltcontroll for CPU
-Added Stweaks support and Stweaks app (all credits and stuff goes to @googy_anas and @Kryten2k35
-Hell lot of improvements
-GPU overclock to 733MHz
-CPU overclock to 2.1GHz (sorry, I couldn't get it stable )
-for more what I had done, visit here: Commits IronKernel
Click to expand...
Click to collapse
Kernel update is awesome I love the GPU OC seems stable also went to 2GHZ CPU OC no issues I would go to 2.1GHZ but I think it may get unstable
TAPATALKED WITH MY XPE R IA Z
My Z3 app Ports to all devices
danny19901 said:
Kernel update is awesome I love the GPU OC seems stable also went to 2GHZ CPU OC no issues I would go to 2.1GHZ but I think it may get unstable
TAPATALKED WITH MY XPE R IA Z
My Z3 app Ports to all devices
Click to expand...
Click to collapse
Better let it at 2.0 GHz. Best for stability! Great you enjoy it
danny19901 said:
Kernel update is awesome I love the GPU OC seems stable also went to 2GHZ CPU OC no issues I would go to 2.1GHZ but I think it may get unstable
TAPATALKED WITH MY XPE R IA Z
My Z3 app Ports to all devices
Click to expand...
Click to collapse
N/A
fishdrop said:
N/A
Click to expand...
Click to collapse
Just putting N/A doesn't help much if you need help or something
New changelog:
IronKernel V1.2 01.03.2015:
- Built with latest toolchain (2015.02) by christopher83
- Use frandom from now
- Enable dynamic page writeback with earlysuspend
- Better battery charging control (kernel and stweaks)
- Auto install the right sTweaks version
- Reduce overestimating rq->avg_idle
- Optimize find_busiest_queue()
- Some CPUfreq optimizations
- Dynamic sync control with earlysuspend support
- Lowmemorykiller: implement task's adj rbtree
- Check free memory when tasks switch to background
- Dynamic FSync
- SOO Much more but I don't remember all
- After flashing the kernel, it will be successfull, but then show an error (becaus of mounting partition) don't worry, just reboot. Just ignore it
THANKYOU !!! Why is it that most other developers can't use common sense and say right up front that their work will kill Knox.
hillg001 said:
THANKYOU !!! Why is it that most other developers can't use common sense and say right up front that their work will kill Knox.
Click to expand...
Click to collapse
This won't actually trip Knox counter...
By installing a custom recovery (pre-requisite to install kernel.zip) will already trip the counter, and not within the scope of most Developers concern. Wouldn't the user already have tripped the counter prior to flashing the kernel? Think about it. .. Having the warning in OP doesn't hurt though