Related
This thread is regarding discussion about Doomlord UC kernel for our device. This thread is specially for general chit chat, opinions, Q and A related to his kernel so that main thread of Doomlord kernel in developement section will have less crowd of unnecessary questions & posts.
So I request senior members to help noobs here. Also if necessary Doomlord will also answer ur important querries here.
Important :-Kernel is working universally perfectly with EVERY firmwares without any problems.
Current version :- v14 (21st MAY 2012)
Original Thread for updates
http://forum.xda-developers.com/showthread.php?t=1357747
http://forum.xda-developers.com/showpost.php?p=26353627&postcount=1659
Thank you.
Regards,
Vishal
Well now that kernel development is in full swing, could we look into fixing the notification bug? I don't know much about android development, but I read someone say it could be kernel related... That I feel is the biggest bug facing our beloved phone on gb!
manrock111 said:
@doomlord finally you got our device, this device has seen lots of bad times and always neglected by senior members or devs. I know lots of your work involve sony ericsson devices,qualcomm devices .
So how do you feel about our device? It's cost only 17k and you know now how it is.
What do you think of it compare to others.
Sent from my GT-I9003 using Tapatalk
Click to expand...
Click to collapse
Sent from my GT-I9003 using Tapatalk
I've just loaded UC v2 on my DXKP9 SL with ext4 and it works fine.
bigeyes0x0 said:
I've just loaded UC v2 on my DXKP9 SL and it works fine.
Click to expand...
Click to collapse
can u tell us which governer & scheduler will be best for battery & performance?
I'm not an expert in android governer and i/o scheduler but I've been using smartassv2 and vr with better performance than stock with a slightly higher battery drain than original settings when actively used. When idle I have about the same battery drain as default.
vishal24387 said:
can u tell us which governer & scheduler will be best for battery & performance?
Click to expand...
Click to collapse
I've used smartassv2 (proposed by XDA_Bam) and Scary and interactive (proposed by Doomlord). I'm using my phone mostly as audioplayer (ie almost always audioplayer is working). For me is more better smartassv2. Because with other I have lags while changing pages in the applications menu or changing screens in the Go launcher Ex.
Also I'm using BFQ as IO scheduler, because I know it's the best for not too many concurrent processes reading/writing to disk. Also usually it doesn't have too big sense for mobile devices, because we don't have a lot applications working with hdd/sd card
can anyone tell me which governer and i/o should i choose for best performance while playing hd games (i dont care about the battery drain). actually i downloaded shadowgun non tegra but it gets a bit laggy when too many enemies appear on screen, i tried setting performance governer but its the same.
nail16 said:
can anyone tell me which governer and i/o should i choose for best performance while playing hd games (i dont care about the battery drain). actually i downloaded shadowgun non tegra but it gets a bit laggy when too many enemies appear on screen, i tried setting performance governer but its the same.
Click to expand...
Click to collapse
1. You have to close all other application and services
2. The performance governor just put CPU to the max frequency, that's why it's the best for gaming
3. If it's still laggy you need or overclocked kernel (we don't have it yet) or make lower settings in the game (or in the Chainfire 3D)
@nail16: You need to OC or a new phone, that game is just too heavy for this phone.
After doing some research on available i/o scheduler I say simple i/o (sio) is the best from theory considering we're accessing a random access device. For quantitative conclusion someone needs to bench.
EDIT: @vishal, can you include a list of firmware versions that work with current UC kernel in your OP? For now I think we have XXKPM, XXKPQ and mine DXKP9. Also I think "[UC Kernel] Q & A" is a better title (the shorter it is the better), please change it if you feel appropriate.
Also here is very good benchmark of the IO schedulers
But remember that it was 2009, now it's 2011 and some things can be changed/optimized
what are the benefits of running custom kernel other than governer and i/o?, sorry noob question
falex007 said:
Also here is very good benchmark of the IO schedulers
But remember that it was 2009, now it's 2011 and some things can be changed/optimized
Click to expand...
Click to collapse
I dare say those benchs are not enough to evaluate those i/o schedulers. e.g. In read_test.c, you see that the program will read chunk of 1MB one by one which is a very rare case that our phone would do in day to day usage. We need a better benchmark methodology to reach a conclusive answer.
What is TinyRCU? Link
---------- Post added at 05:40 PM ---------- Previous post was at 05:37 PM ----------
nail16 said:
what are the benefits of running custom kernel other than governer and i/o?, sorry noob question
Click to expand...
Click to collapse
On the kernel page, you saw lots of line saying added in v1, added in v2.
All those are not present in the vanilla kerel by samsung.
U can check each in google to see what it means and what good it brings the mobile.
Also read these links to understand more:
Fugumod Kernel
Steam Kernel
There are lots more.
Thanks ganesh, you are very noob friendly.
bigeyes0x0 said:
I dare say those benchs are not enough to evaluate those i/o schedulers. e.g. In read_test.c, you see that the program will read chunk of 1MB one by one which is a very rare case that our phone would do in day to day usage. We need a better benchmark methodology to reach a conclusive answer.
Click to expand...
Click to collapse
How many applications do you start every day that hard works with hard disk? Do you think IO scheduler can be bottleneck for usual usage of our device? I don't think so. Only games during load of new level, gallery (during making thumbnails) and launcher (during loading icons) work hard with "hard disk"
Updated op.
I was looking into fs benchmarks for debian linux.
Found that JFS was the least CUP intensive off all.
Would it be the same on Android?
falex007 said:
How many applications do you start every day that hard works with hard disk? Do you think IO scheduler can be bottleneck for usual usage of our device? I don't think so. Only games during load of new level, gallery (during making thumbnails) and launcher (during loading icons) work hard with "hard disk"
Click to expand...
Click to collapse
No, I actually don't really care as long as my phone feel smooth, that's why I don't go out and do a benchmark myself to ultimately find an answer. My point simply was that benchmark method in your link is inadequate. Finding faults in other ppl's works is one thing I do at my job after all.
bigeyes0x0 said:
No, I actually don't really care as long as my phone feel smooth, that's why I don't go out and do a benchmark myself to ultimately find an answer. My point simply was that benchmark method in your link is inadequate. Finding faults in other ppl's works is one thing I do at my job after all.
Click to expand...
Click to collapse
What these benchmarks do is to guide us to use the appropriate one for our use.
As Doom says we can switch the IO Scheculer/Governor on the fly.
So where is the problem in doing so.
WildKernel
As some of you may know, I've been working on a custom kernel for ICS/JB and its about done (for a first release).
Also I was previously planning on a beta testing for a selected few, but I released I won't have enough time to be hosting testing sessions, so how about this. The kernel is know free to use for the public, but all I ask is that your report and compare. I'd like to see if there's improvement or loss between the A6 kernel and this (battery, performance, etc.). Also please report anything good and bad so that I know what to keep and what not to keep for a final release. This also helps me push out fixes faster when presented with lots of information.
Current kernel features include: (If feature begins with a * then check below for more information)
Universal kernel compatible with all AOSP (NOT SENSE) ICS & JB roms
rebased to CAF (custom) Linux 3.0.39 kernel
Optimized Built in Low-memory killer w/ Fugeswap (as seen in the v6 Supercharger)
Optimized ram usage/handling (Swap & Zram)
Increased Wi-fi connectivity range
*Low & High power Wi-fi scaling steps
*Badass Governor
Lazy Governor
Imported Snapdragon optimizations used by the Sensation (Thanks Romanbb)
Lagfree Governor
Fast charging for unknowns and when plugged in to computers
HIGHLY Tweaked for the perfect battery life and performance
Bluetooth code from CAF
V(R), simple, deadline, noop, and CFQ I/O schedulers
*Ondemand & Intelli(gent)demand Governor
Stable Undervolting of the CPU
increased SDcard readahead speed
Tweaked Flashlight
Added more clock steps to the GPU for compatibility with low power browsing and GPU OC @ 320 mhz
Please wipe cache and dalvik cache
I dont suggest using SetCPU as it may cause bugs such as reboots, use CM or AOKP's built in cpu speed feature
Download Universal flasher for ICS and JBhttp://www.mediafire.com/download.php?q9bhv68k8dvai13
(Flashable for S-ON coming tomorrow when I have time)
You may find my source hosted @ Github
More information:
Badass Governor: This governor has built in profiling (like used in SetCPU but not as battery & Ram consuming). This is also the default and highly recommended governor. This governor features a 3 phase system CPU profiling system. This will change your CPU speed based on usage. This saves a lot of power as your speed doesn't just keep at one clock no matter how much your using you phone. A similiar profiling system is also used for the GPU and such.
Ondemand and Intellidemand Governor: Intellidemand is based off the Ondemand governor but features a 2 phase CPU profiling system with some added tweaks. Ondemand also now has early suspend support for low power browsing to save battery.
Wi-fi Low and High power scaling steps: This is a feature that will determine whether to use High or low power voltages on the Wi-fi chip to save battery. eg: Wi-fi will be turned to low power when idle or screen off. Wifi will be turned to high power when actively in use or in progress of a download. Take note that high power wi-fi voltage isn't necessarily "High" power but more of just "Stock HTC" power.
View all public kernel releases
Changelog:
Code:
[B]Sep 3 - ver003[/B]
1. Bluetooth updates upstream
2. Downgrade to linux Kernel v3.0.39 with custom libs to *really* fix lag
3. Badass back to default governor as the most stable
4. More LMK tweaks
[B]Sep 2 - ver002[/B]
1. Implemented USB forced fast charge v3.1
2. Downgrade to linux Kernel v3.0.40 to fix lag
3. Ondemand tweaks, early suspend updates, and is now default governor because of balance of stababilty, battery, and speed.
4. LMK tweaks
5. Updates to bluetooth from CAF (more battery saving and stable)
6. Updates to scheds from faux
7. mpdec ready but disabled until stabalized
8. A lot of improvements since ver001
Thanks:
TeamDS
Strapped365
faux123
Tamcore
cretin45
showp1984
RomanBB
and any others I may have missed
reserved for James (He'll be supplying statistics such as battery reports, cpu logs, benchmarks etc.)
Post statistics and they will be copied here
Nice
Hastily spouted for your befuddlement
Awesome. Hope this fixes the battery drain problem from the A6 kernel.
Sweet. Will test tonight.
Il test this but not until Saturday morning will I have solid feedback
I'm going to have to use both Ankers plus my stock battery for tomorrow as I have school, then a football game, then a roadtrip so I will definitely take shots and post back with great contrasts I'm sure
Thanks XMC
::Respect::
---------- Post added at 10:02 PM ---------- Previous post was at 09:31 PM ----------
CRUD! I got to my PC, downloaded it and read its not in Boot.img format! IM S-ON D:
Sorry wild, can't get it booting. Been trying forever. I'll redownload again when I get home.
P.s: it boots, but it goes right into a reboot after I hit homescreen. I don't think I can use alogcat to pull one, so I'll have to wait till I get back to my computer. Perhaps a dmesg a well.
You also plan on making something for sense ROMs?
If not would you mind if I grab your patches and implement it to a more enhanced virtuous kernel?
Riyal said:
You also plan on making something for sense ROMs?
If not would you mind if I grab your patches and implement it to a more enhanced virtuous kernel?
Click to expand...
Click to collapse
Hey maybe even if xmc your planning on doing a sense one... Maybe if no offense allow Riyal access to those things as you might learn from his enhancements to a sense kernal and such... Also additional development for DS
:what:
::Respect::
well im on my computer. the error (though im no expert) seems to be here
if you need the full logcat let me know and i'll try grab it again. that's the error going on right when the homescreen gets laggy on boot, right before it reboots.
i don't know if this is important to you, but this is what i get in logcat right before reboot
I'm sure i followed directions. I hope I'm not doing something wrong.
Edit: yep. Definitely not an expert. So it stopped rebooting after I unchecked "set on boot" under performance. Will be reporting back.
CoNsPiRiSiZe said:
Il test this but not until Saturday morning will I have solid feedback
I'm going to have to use both Ankers plus my stock battery for tomorrow as I have school, then a football game, then a roadtrip so I will definitely take shots and post back with great contrasts I'm sure
Thanks XMC
::Respect::
---------- Post added at 10:02 PM ---------- Previous post was at 09:31 PM ----------
CRUD! I got to my PC, downloaded it and read its not in Boot.img format! IM S-ON D:
Click to expand...
Click to collapse
I flashable for S-ONs will come soon sorry
Riyal said:
You also plan on making something for sense ROMs?
If not would you mind if I grab your patches and implement it to a more enhanced virtuous kernel?
Click to expand...
Click to collapse
to be honest I hate sense and I doubt I'll be developing anytthing for it anytime soon.
Riyal, i'm open source so feel free to do whatever you wish. If you need help with me pointing out specific commits lemme know
ekoee said:
well im on my computer. the error (though im no expert) seems to be here
if you need the full logcat let me know and i'll try grab it again. that's the error going on right when the homescreen gets laggy on boot, right before it reboots.
i don't know if this is important to you, but this is what i get in logcat right before reboot
I'm sure i followed directions. I hope I'm not doing something wrong.
Edit: yep. Definitely not an expert. So it stopped rebooting after I unchecked "set on boot" under performance. Will be reporting back.
Click to expand...
Click to collapse
are you using setcpu?
No, I'm running cm 9.1.0. Under settings > performance > cpu settings or whatever it is, if you have set on boot checked, the phone runs funny. I unchecked it in a desperate attempt to figure out what's going on, and it's been pretty stable ever since.
xmc wildchild22 said:
reserved for James
Click to expand...
Click to collapse
LMAO! :laugh: You GO James!!! :good:
CoNsPiRiSiZe said:
CRUD! I got to my PC, downloaded it and read its not in Boot.img format! IM S-ON D:
Click to expand...
Click to collapse
Can't we just extract the zImage from the universal kernel flasher, rename it boot.img, and flash? I thought they were analogous...
Edit: I tried it. Didn't work. "Boot Magic check failed". Guess I was thinking of Samsung devices. Bummer, I really wanted to try this.
Ok after a 10 minute self lesson on kernel kitchen I managed to compile a boot.img. Booted right up but I had nofrills with an "apply on boot" setting which screwed me over. Severe lag. I managed to access that app in slow motion and deselect the apply on boot nonsense. Now we are in business
Don't forget to uncheck all governor apply on boot settings before flashing! Also, on first boot go to a view CPU frequency place on your phone so you can wait until the phone settles before rebooting/doing stuff. Takes a little longer than you would expect.
So far the performance seems good, I'll report back on battery life later.
Edit: 3 consecutive reboots during 3 consecutive calls. Switching back to 3.0.30 (A5) for now. Since I didn't flash this officially I'd take this experience with a grain of salt but it is similar to what ekoee is reporting so IDK.
Hi xmc! Not that I question the knowledge of the senior htc community developers here but this battery issue I am facing with ROMs like virtuous is already nagging me out.
Now compiled yours and shocked that it also has the battery bug.(The not going to 100% bug)
So I decided to really look up the battery driver carefully awhile ago and noticed something strange in it. I noticed this days ago and thought this was ok but thought I would stand up and ask today.
In
arch/arm/mach-msm/htc_battery_8x60.c
htc_batt_get_battery_info
Could you tell me why calculation of battery is like this?
htc_batt_update->batt_current = htc_batt_info.rep.batt_current - htc_batt_info.rep.batt_discharg_current;
Click to expand...
Click to collapse
instead of this?
htc_batt_update->batt_current = htc_batt_info.rep.batt_current;
Click to expand...
Click to collapse
Seems like the batt_discharg_current is making my battery report less than the real value so I'd like to know why is the calculation like that?
I'm sorry for asking but I think you're the only developer on doubleshot who is approachable enough for me to ask to.
Riyal said:
Hi xmc! Not that I question the knowledge of the senior htc community developers here but this battery issue I am facing with ROMs like virtuous is already nagging me out.
Now compiled yours and shocked that it also has the battery bug.(The not going to 100% bug)
So I decided to really look up the battery driver carefully awhile ago and noticed something strange in it. I noticed this days ago and thought this was ok but thought I would stand up and ask today.
In
arch/arm/mach-msm/htc_battery_8x60.c
htc_batt_get_battery_info
Could you tell me why calculation of battery is like this?
instead of this?
Seems like the batt_discharg_current is making my battery report less than the real value so I'd like to know why is the calculation like that?
I'm sorry for asking but I think you're the only developer on doubleshot who is approachable enough for me to ask to.
Click to expand...
Click to collapse
I'll take a look once I get home. Lol and just to be clear, i'm not the only dev for the DS. We got Blue6IX, jeffakajeff, strapped365, tbalden, Riyal , kornyone, and nbetcher. (Dont kick my a$$ if I skipped your name )
Flashed this with a fresh install of your JB ROM. Phone is really laggy when waking from screen off for a few seconds but then its ok. I'll look more in to this but thats what I'm seeing so far.
Flashing over CM 9.1 now, will test it out and report back with results. Really hope this takes care of the battery drain issue in 9.1.
xmc wildchild22 said:
I'll take a look once I get home. Lol and just to be clear, i'm not the only dev for the DS. We got Blue6IX, jeffakajeff, strapped365, tbalden, Riyal , kornyone, and nbetcher. (Dont kick my a$$ if I skipped your name )
Click to expand...
Click to collapse
Lol! If I were a dev here I wouldn't have asked you this woot now I'm an ass kicker :highfive:
Team Fah-Q Presents...
Scorched Kernel for Blaze ICS v1.0.29
Built with the Linaro Toolchain v4.7, the purpose of this kernel is to fix bugs, add features, add performance, and hopefully save some battery where possible. However, battery life will most likely not be as good as stock, since the device is overclocked and DVFS (dynamic frequency and voltage scaling) is turned off. I have done my very best to squeeze every ounce of battery life out of this device.
It includes a brand new CPU Governor called Scorched, developed by me and based on the lagfree governor. It focuses on saving power and reducing the usage of the higher CPU frequencies unless necessary, while still keeping responsiveness and performance intact.
The kernel should work with any ROM that is derived from the stock Samsung ICS release IMM76D.LH5, however I recommend using it with the Tweaked ROM, as that is what I develop it against.
This is a kernel several months in the making. Hope you like it
It is STRONGLY advised to do a full nandroid backup in CWM before installing the kernel,
as the installer will overwrite kernel modules in /system/lib/modules. You've officially been warned
NOTE: This thread is reserved for bug reports, logcats, and other development related discussion. General discussion, questions, etc should be posted in this threadKernel Features
IO Schedulers:
zen (NEW)
vr (NEW)
sio (NEW)
deadline
cfq
noop
CPU Governors:
scorched (NEW)
lagfree (NEW)
interactive (NEW)
ondemand
conservative
userspace
powersave
performance
Other Features:
Overclocked to 1.72 GHz
Voltage control support
Support for init.d scripts, added automatically during installation of the kernel.
ZRAM support with Google Snappy compression, with a default size of 64 MB.
Other tweaks and fixes, too minor to note. Check the Google Code site if you're interested.
Credits/Thanks
withere2 - Endless testing, testing, ideas, more testing, scripting support, more testing. Did I mention testing?
erikmm - Pulling me into kernel development
showp-1984 - Lots of initial help getting off the ground with kernel development
faux123 - Some source code from his Samsung GS2 github repo
Changelog and Downloads
Changelog and Downloads
2012-12-21 - Version 1.0.29 - tfq-scorched-kernel-ics-1.0.29-signed.zip
ADB now runs as root. Not as easy as you might think to do it properly...
2012-12-17 - Version 1.0.22 - tfq-scorched-kernel-ics-1.0.22-signed.zip
Initial public release of kernel
Resolved issue with battery life. Standby time should be almost double that of version 1.0.20
The source code for this kernel can be found on Google Code:
http://code.google.com/p/scorched-kernel-t769-ics/
All previous release versions of the kernel can be found on the Scorched Google Code site
http://code.google.com/p/scorched-kernel-t769-ics/downloads/list
FAQ
FAQ
What is the Scorched CPU Governor?
The Scorched CPU governor is rather similar to the lagfree governor both in its source code and its purpose. The difference is that while lagfree seeks to give performance-on-demand by increasing immediately to the maximum CPU frequency, Scorched jumps immediately to a mid-point frequency and then gracefully increases or decreases the CPU frequency as required. This provides both performance-on-demand as well as extended battery life.
multi core support
is there anyway of changing it to were we have multi core support ( in regards to offlining 2nd 3rd etc cores ) to save battery by chance cause some other kernels ive tested have that capability if i knew how to do so myself ( im slowly learning with massive reprocussions lol ) but would that be possible at all
awesome finally some scorchness for the blaze
merwin said:
Changelog and Downloads
2012-12-17 - Version 1.0.22 - tfq-scorched-kernel-ics-1.0.22-signed.zip
Initial public release of kernel
Resolved issue with battery life. Standby time should be almost double that of version 1.0.20
The source code for this kernel can be found on Google Code:
http://code.google.com/p/scorched-kernel-t769-ics/
All previous release versions of the kernel can be found on the Scorched Google Code site
http://code.google.com/p/scorched-kernel-t769-ics/downloads/list
Click to expand...
Click to collapse
Many thanks for your hard work.
However I've been using this kernel for a couple of days now with tweaked 2.1, and deleted battery stats but my battery life is really poor.
I've left the system essentially in standby for several full charge cycles but I only get 10 hours with next to no use, if lucky.
With stock kernel and Blz3r v3 and with heavy usage I would easily get 14 hours.
I'm still going to keep on using it and characterizing it and hope it gets better.
Sent from my SGH-T769 using xda app-developers app
theshowman said:
Many thanks for your hard work.
However I've been using this kernel for a couple of days now with tweaked 2.1, and deleted battery stats but my battery life is really poor.
I've left the system essentially in standby for several full charge cycles but I only get 10 hours with next to no use, if lucky.
With stock kernel and Blz3r v3 and with heavy usage I would easily get 14 hours.
I'm still going to keep on using it and characterizing it and hope it gets better.
Sent from my SGH-T769 using xda app-developers app
Click to expand...
Click to collapse
Not sure what to tell you. I've attached an image with my stats on it. That's 7 hours, mostly standby, dropping 30%, with wifi calling, exchange sync, gmail sync all on.
And this is more of a general Q&A thread topic also
soldier1184 said:
is there anyway of changing it to were we have multi core support ( in regards to offlining 2nd 3rd etc cores ) to save battery by chance cause some other kernels ive tested have that capability if i knew how to do so myself ( im slowly learning with massive reprocussions lol ) but would that be possible at all
Click to expand...
Click to collapse
Please ask this in the general questions thread.
Using just CPU0
soldier1184 said:
is there anyway of changing it to were we have multi core support ( in regards to offlining 2nd 3rd etc cores ) to save battery by chance cause some other kernels ive tested have that capability if i knew how to do so myself ( im slowly learning with massive reprocussions lol ) but would that be possible at all
Click to expand...
Click to collapse
This app will let you use 1 core, both or link them together as one:
PC Link: https://play.google.com/store/apps/...sMSwyLDEsInJzLnBlZGphYXBwcy5LZXJuZWxUdW5lciJd
nickmcminn60 said:
This app will let you use 1 core, both or link them together as one:
PC Link: https://play.google.com/store/apps/...sMSwyLDEsInJzLnBlZGphYXBwcy5LZXJuZWxUdW5lciJd
Click to expand...
Click to collapse
In my own testing, I have found that it is often worse to turn off a core completely, than to aim for a lower clock speed on both active cores. My theory is that the increase of speed with multithreading speeds up processing over the single corr, thus staying at a higher frequency for less time.
Just a personal observation.
I'm New
I'm sorry if i sound like an idiot, but Does this work on the stock ICS rom? I'm rooted btw
and does it support undervolting?
Thank you, Very stable and responsive kernel. Only issue I've had after installing the kernel is that when I try to send an app from play.google.com to my phone it doesn't show up. I can still install from within the phone itself just not website to phone, not sure if it's related to this Kernel or not but started after flashed it.
Again I'm not 100% positive that it's related so will need to do some more testing...
techclan said:
Thank you, Very stable and responsive kernel. Only issue I've had after installing the kernel is that when I try to send an app from play.google.com to my phone it doesn't show up. I can still install from within the phone itself just not website to phone, not sure if it's related to this Kernel or not but started after flashed it.
Again I'm not 100% positive that it's related so will need to do some more testing...
Click to expand...
Click to collapse
Looks like the problem with the apps not getting pushed to the devide was a stuck process, my "smooth calendar" was at 83% cpu utlization and app pushes were being halted.
Android ICS 4.0.4 UVLH5 + Scorched Kernel ICS v1.0.29
techclan said:
Android ICS 4.0.4 UVLH5 + Scorched Kernel ICS v1.0.29
Click to expand...
Click to collapse
That's about right for the benchmark. I'm considering going a slightly different route with the kernel that may reduce performance a bit but should up battery life significantly.
Sick 2 year old at home so I've had limited time to play, unfortunately.
merwin said:
That's about right for the benchmark. I'm considering going a slightly different route with the kernel that may reduce performance a bit but should up battery life significantly.
Sick 2 year old at home so I've had limited time to play, unfortunately.
Click to expand...
Click to collapse
Hope your 2 year old gets well soon. Yes sacrificing a bit of performance to up the battery is definitelyitly worth it. Also seems like your scorched will outilizelize 384 and above, not sure how much battery can be saved but basic call functions and such can perfectly work on 192Mhz
roms
does this work on pacman rom 4.1.2 for the blaze please respond quickly my current kernel is random rebooting and this worked when i was on stock rom
No its for ICS
Sent from my SGH-T769 using xda premium
Welcome to decimalman's kernel playground!
As the name suggests, dkp is a hodgepodge of features and tweaks that I wanted to play with. It should get excellent battery life without feeling sluggish. It doesn't come with its own tuner app, so pick your favorite. Personally, I like Trickster MOD and Kernel Adiutor, so I go out of my way to make things work in them. Most other apps should work, too.
Features:
Overclocking up to 2.1 GHz, but you'll need to increase your voltages to get there (if you can get there at all)
Underclocking down to 54 MHz, with stability improvements
Undervolting compatible with most apps
Fast charge without unplugging first
Glorious animations for the notification and softkey LEDs
Well-integrated erandom means you don't need CrossBreeder or Seeder (recent AOSP builds use ISAAC instead)
freelunch and tierservative governors for optimal battery life without sacrificing responsiveness
Automatic mpdecision and auto-hotplug are only enabled when needed
Adjustable minimum voltage for stability on finicky processors
Optimized UKSM to free up some extra memory
Code optimizations for size and speed
Compiler optimizations (-O3, LTO, and more) because faster is better
Donors: Thanks, everyone! Your generosity is much appreciated. :good:
drpenguino, 0xScott, vmancini3 (twice! :good, Ch4m3l30n, rompnit, Mystique, ryandubbz, techdog, ElwOOd_CbGp, ScOULaris, ZipAddict
Remember:
Nandroid!
last_kmsg and/or logcat or it didn't happen.
Other kernels have their own threads or forums. Discuss them there.
Image dumps (settings, battery life, whatever) belong inside [HIDE][/HIDE] (that's HIDE, if you're on the mobile app) tags.
Be silly. We're here to have fun.
Installation:
Reboot to recovery. I recommend that one recovery...you know, the one that flashes zips? I forget what it's called.
Flash dkp. Optionally, rename and flash dkp-vmin-XXX.zip (see below).
Reboot.
Undervolting:
Undervolting on dkp is more complex than other kernels. Some processors get unstable at lower voltages, so (like the stock kernel) dkp keeps the processor voltage above 1150 mV by default. I refer to this limit as the minimum voltage. In order to undervolt, you'll need to lower the minimum voltage: if you use Trickster MOD or Kernel Adiutor, just disable "Override Minimum Voltage", otherwise rename dkp-vmin-XXX.zip to e.g. dkp-vmin-600.zip (which would apply a 600 mV minimum voltage) and flash it. If this causes instability (crashes, audio/video glitches, etc.), try using dkp-vmin-XXX.zip to apply a higher minimum voltage (somewhere between 950 and 1050 mV seems to work well for most people).
Downloads:
MediaFire:
All Downloads
dkp-vmin-XXX.zip
Solidfiles (Make sure you have an adblocker!):
All Downloads
dkp-vmin-XXX.zip
Source: I'm always happy to see my code used, so cherry-pick away. I'll even put together feature patches if you ask nicely.
Bugs:
Let me know.
Stable changelog:
3/3/13: Initial release for d2spr. Didn't get around to making threads for other carriers.
4/8/13 (3.0):
FauxSound support
Strip more useless stuff
A few bonus optimizations
4/8/13 (3.4):
Port everything except erandom from 3.0
Enhance cpufreq for easier configuration
4/24/13 (3.4):
Bugfixes: better support for tuner apps, fixed potential SOD bugs, automatic mpdecision fixups, etc.
Lots of CM/CAF/Linux updates
Working AssWax governor
Trinity colors support
sio, zen I/O schedulers
erandom is back!
Built with a super-fancy Linaro GCC 4.8.1-dev compiler toolchain for maximum -O3 goodness
Probably lots more, but there's hundreds of commits to sort through...
5/29/13 (3.4):
Bugfixes: better overclocking support, better hwrng support, etc.
Updates: new CM updates, Linux 3.4.47, updated FauxSound driver, added invisiblek's new panel colors interface
Automatic auto-hotplug
New optimizations, including link-time optimization and an updated GNU+Linaro GCC 4.8.1-dev toolchain
6/14/13 (3.4):
Bugfixes: fix several critical bugs in the 5/29 release.
9/7/13 (3.4):
Fixes for OC, UV, auto-hotplug.
A few new optimizations.
Synced up with CM.
9/20/13 (TW):
Ported everything from AOSP to TW.
9/20/13 (4.3):
Merged 4.3 from CM into the existing 4.2 code.
Current experimental branches:
Nothing interesting at the moment.
Goodies:
dkp doesn't come with its own splash screen. However, the dkp installer (i.e. the install zip) is smarter than you think, and can apply a custom splash screen for you. Here's how:
Create a folder on your internal storage named "dkp"
Copy a PNG image into the directory, and rename it "splash.png". Alternatively, copy an RLE image (i.e. from a flashable custom splash screen zip) and rename it "splash.rle". Ideally, the image should be roughly 1280x720 to begin with, since it won't be resized.
The image will be used as your splash screen whenever you flash dkp. Reflash to apply initially.
mikedavis120 has put together a how-to video that covers tweaking dkp for optimal battery life. If you're new to dkp, take a look! He also put together a zipped collection of apps that will come in handy while tuning dkp. It also includes a flashable zip, "dkp-debug_v1.zip". After flashing it, running
Code:
su
dkp
from a terminal emulator will collect lots of useful debug information that will make it much easier for me to track down the issue you're having. :good: mikedavis120 recommends installing SuperSU (included in the zip) instead of what's included in you ROM.
sysfs:
It's possible to adjust all the settings available in dkp without using apps. Because they show up as files, settings can be adjusted with file managers, terminal emulators, adb and initscripts. Here's the most interesting files inside sysfs:
/sys/devices/platform/mipi_samsung_oled.513/lcd/panel/panel_colors (not available on newer AOSP builds): display tint (0 = very red, 2 = default, 4 = trinity colors)
/sys/class/misc/gammacontrol (only available on newer AOSP builds): various color controls. See this post for details on enabling Trinity colors on builds that use these controls.
/sys/devices/system/cpu/cpu<N>/cpufreq/UV_mV_table: voltage table
/sys/devices/system/cpu/cpu<N>/cpufreq/scaling_...: scaling_governor is the governor, scaling_min_freq and scaling_max_freq are the minimum and maximum frequencies, scaling_available_governors and scaling_available_frequencies show the available governors and frequencies
/sys/kernel/dkp/force_fast_charge: fast charge
/sys/kernel/dkp/link_core_settings: when linked (the default), frequency settings and some governors are automatically copied to the other core
/sys/kernel/dkp/vmin: minimum processor voltage in mV
/sys/kernel/mm/uksm/run: activate UKSM
auto-hotplug tuners:
These show up in the governor settings for any governor that doesn't do its own hotplugging. They only take effect when using auto-hotplug, so you'll probably need to disable mpdecision in Trickster.
hotplug_intpulse: when set to 1, automatically turns core 2 on whenever the screen/buttons/whatever is pressed. Default is 0.
hotplug_sampling_periods: number of samples to use for average number of running tasks. Default is 15.
hotplug_sampling_rate: number of 'jiffies' (currently 1 jiffy = 10 ms) between each sample of running tasks. Default is 20 (0.2 sec).
hotplug_enable_one_threshold: the average number of running tasks required to turn core 2 on, multiplied by 100. Default is 125 (1.25 tasks on average).
hotplug_disable_one_threshold: the average number of running tasks required to keep core 2 on, multiplied by 100. Default is 250 (2.5 tasks on average).
freelunch/nanolunch tuners:
freelunch and nanolunch aren't materially based on other governors, so their configuration is quite different than other governors. There's lots of tuners, since I haven't really decided on an ideal tuning. I encourage experimentation! I'll explain a bit of how these governors work before actually listing the tuners.
Generally speaking, there are two modes: in "normal" mode, sampling is done occasionally and frequency is generally increased slowly; in "interactive" mode, sampling is done much more quickly, and frequency increases much more quickly. "Interactive" mode ends after several samples of very low usage. The idea of a "hispeed" frequency is used in lots of governors, and it refers to the frequency that the CPU will jump to when more CPU usage is needed; generally, it's a generous estimate of how much CPU will be needed. Here, the hispeed frequency is adjusted on-the-fly, increasing when more CPU is needed and gradually decreasing when the CPU is idle. In "interactive" mode, the hispeed frequency is kept fairly high so that everything will feel snappy.
Hotplugging is taken care of in the least complicated (and in my opinion, most reasonable) way possible: if core 1 is using lots of CPU, and there are several tasks running (in other words, if it's likely that core 2 will have something to do), core 2 is turned on; if either core isn't doing much except using power, core 2 is turned off.
sampling_rate: the usual
hotplug_up_cycles: number of consecutive heavily-loaded samples before core 2 is turned on
hotplug_down_cycles: number of consecutive lightly-loaded samples before core 2 is turned off
hotplug_up_load: number of running tasks required to bring core 2 online
hotplug_up_usage: number of used CPU cycles (in thousands per second) required to bring core 2 online
hotplug_down_usage: number of used CPU cycles (in thousands per second) required on both cores to keep core 2 online
overestimate_khz: number of CPU cycles to overshoot usage by in "normal" mode
hispeed_thresh: if CPU usage is within this many cycles (in thousands per second) of the maximum frequency, frequency will be increased to the hispeed frequency. Generally, hispeed is pretty low in "normal" mode, and fairly high in "interactive" mode.
hispeed_decrease: when the CPU is sitting idle, the hispeed frequency is decreased by this amount each sample (this isn't ideal, but it works)
interaction_hispeed: the initial hispeed frequency when switching to "interactive" mode
interaction_return_cycles: number of consecutive lightly-loaded samples before returning to "normal" mode
interaction_return_usage: number of used CPU cycles (in thousands per second) required to stay in "interactive" mode
interaction_panic (nanolunch only): when set to 1, allows aggressively jumping past the current hispeed frequency under some circumstances
interaction_sampling_rate/overestimate_khz: equivalent to the "normal" versions of the tuners, these take effect in "interactive" mode
This looks great - especially excited about your custom governor! Thanks!!
Sent from my SCH-I535 using xda app-developers app
Glad we have another kernel dev. But do you plan on releasing a tw kernel? I run tw 98% of the time and would love to try it out. Thanks for your work regardless
PsiPhiDan said:
This looks great - especially excited about your custom governor! Thanks!!
Sent from my SCH-I535 using xda app-developers app
Click to expand...
Click to collapse
freelunch is absurdly simple, but does its job well. Let me know what you think. Happy flashing!
aypeeootrek said:
Glad we have another kernel dev. But do you plan on releasing a tw kernel? I run tw 98% of the time and would love to try it out. Thanks for your work regardless
Click to expand...
Click to collapse
I don't run TW, so I don't have any plans to release a TW kernel. If there's enough interest, I suppose I could get to work on one though.
Interesting. Looks cool man, will check it out
Sent from my SCH-I535 using Tapatalk 2
I'm excited to give this a shot!
Sent from my SCH-I535 using xda app-developers app
flashaholic commencing flash!
Anyone using trickster mod with this kernel?
Sent from my SCH-I535 using Tapatalk 2
Love this kernel! Freelunch is amazing
Sent from my SCH-I535 using xda premium
This kernel run pretty good!!
Sent from my SCH-I535 using xda app-developers app
masri1987 said:
Anyone using trickster mod with this kernel?
Sent from my SCH-I535 using Tapatalk 2
Click to expand...
Click to collapse
It's the recommended tuner app, and plenty of people are using it (mostly on Sprint and AT&T). It shows some options that are completely bogus (like GPU governor), but I've added a few extras that only Trickster supports.
Thanks for the encouraging feedback, everyone! It's much appreciated. :good:
Kudos on this kernel. It has been perfect for me so far.
Running good on my d2usc! What scheduler do you recommend?
Sent from my SCH-R530U using Tapatalk 2
New 3.4 experimental builds are going up!
governors is building now, and has sio and zen. It'll eventually have a few new governors, but I haven't gotten everything ported yet.
gcc480 is up now, and is a test to make sure GCC 4.8.0 isn't causing any crazy bugs. It's also got sio and zen.
Edit: I forgot about you, trvbone. I don't have a preferred scheduler. I usually just use sio. I've never had a positive experience with ROW, but that might just be bad luck on my part.
More edit: I'm building a 3.0 kernel with trinity colors support and GCC 4.8.0 now. It should be up shortly.
decimalman said:
New 3.4 experimental builds are going up!
governors is building now, and has sio and zen. It'll eventually have a few new governors, but I haven't gotten everything ported yet.
gcc480 is up now, and is a test to make sure GCC 4.8.0 isn't causing any crazy bugs. It's also got sio and zen.
Edit: I forgot about you, trvbone. I don't have a preferred scheduler. I usually just use sio. I've never had a positive experience with ROW, but that might just be bad luck on my part.
Click to expand...
Click to collapse
I'm no noob when it comes to kernel lingo, but I'm not sure what the dif is here between the kernels listed as governors and gcc480. Are these two different kernels? I'm not aware of what gcc480 is I guess. Sorry until recently I was a dedicated lean kernel user and don't know all of the terminology since lk was pretty plain Jane.
I'm not a huge fan of row, but that's what I'm using right now cause it's quick just a little sketchy sometimes.
Sent from my SCH-R530U using Tapatalk 2
trvbone said:
I'm no noob when it comes to kernel lingo, but I'm not sure what the dif is here between the kernels listed as governors and gcc480. Are these two different kernels? I'm not aware of what gcc480 is I guess. Sorry until recently I was a dedicated lean kernel user and don't know all of the terminology since lk was pretty plain Jane.
I'm not a huge fan of row, but that's what I'm using right now cause it's quick just a little sketchy sometimes.
Sent from my SCH-R530U using Tapatalk 2
Click to expand...
Click to collapse
I have a tendency to describe things in the least understandable way possible. Sorry about that.
Hopefully, there's no noticeable differences between the two builds. I think the gcc480 build might benchmark a bit better, but I haven't really compared. The only actual difference is which compiler I used to build the kernel, which probably doesn't matter for 99% of users.
The governors build is built with the same ol' Linaro nightly toolchains that I've been using, so I expect it to be pretty stable.
The gcc480 build uses a newer, fancier compiler: GCC 4.8.0. I've found at least one new bug with the new compiler (it's fixed in the uploaded builds, don't worry ). I'm not ready to call the gcc480 build stable since it's gotten so little testing, but it's been running great for me all day. I'd love to hear feedback from anyone who flashes it.
Eventually, most other kernels will switch to GCC 4.8.0 (probably once Linaro releases a full-featured build). I think gideonx (of BMS fame) is planning to switch sometime soon, and I would expect ktoonsez to switch pretty soon too.
decimalman said:
I have a tendency to describe things in the least understandable way possible. Sorry about that.
Hopefully, there's no noticeable differences between the two builds. I think the gcc480 build might benchmark a bit better, but I haven't really compared. The only actual difference is which compiler I used to build the kernel, which probably doesn't matter for 99% of users.
The governors build is built with the same ol' Linaro nightly toolchains that I've been using, so I expect it to be pretty stable.
The gcc480 build uses a newer, fancier compiler: GCC 4.8.0. I've found at least one new bug with the new compiler (it's fixed in the uploaded builds, don't worry ). I'm not ready to call the gcc480 build stable since it's gotten so little testing, but it's been running great for me all day. I'd love to hear feedback from anyone who flashes it.
Eventually, most other kernels will switch to GCC 4.8.0 (probably once Linaro releases a full-featured build). I think gideonx (of BMS fame) is planning to switch sometime soon, and I would expect ktoonsez to switch pretty soon too.
Click to expand...
Click to collapse
Thanks for the expl I'll flash tomorrow morning and give it a whirl! Great job BTW. This is now my daily driver!
Sent from my SCH-R530U using Tapatalk 2
decimalman said:
I have a tendency to describe things in the least understandable way possible. Sorry about that.
Hopefully, there's no noticeable differences between the two builds. I think the gcc480 build might benchmark a bit better, but I haven't really compared. The only actual difference is which compiler I used to build the kernel, which probably doesn't matter for 99% of users.
The governors build is built with the same ol' Linaro nightly toolchains that I've been using, so I expect it to be pretty stable.
The gcc480 build uses a newer, fancier compiler: GCC 4.8.0. I've found at least one new bug with the new compiler (it's fixed in the uploaded builds, don't worry ). I'm not ready to call the gcc480 build stable since it's gotten so little testing, but it's been running great for me all day. I'd love to hear feedback from anyone who flashes it.
Eventually, most other kernels will switch to GCC 4.8.0 (probably once Linaro releases a full-featured build). I think gideonx (of BMS fame) is planning to switch sometime soon, and I would expect ktoonsez to switch pretty soon too.
Click to expand...
Click to collapse
Giving it a go now. Do you have any test methods you use to test the stability of a kernel other than the everyday use approach? Thanks for the support, looks sweet:good::good::good:
[url=https://postimages.org/]
[/URL]
This is a home of new re branded yarpiin kernel for Lineage OS based roms.
Would like to thank to all devs that work has been used to create this kernel.
SO WE STARTING A LIST:
all CREDITS goes to:
@Grarak
@Mahdi786
@Lord Boeffla
@franciscofranco
@ Despair Factor
@ak
@ZaneZam
@varun.chitre15
@flar2
@arter97
@TheCrazyLex
@Sultanxda
@eng.stk
@neobuddy89
@Tkkg1994
@frap129
@jcadduono
@savoca
@yank-lu.555
@Dorimanx
@acuicultor
@Alucard24
@bbedward
@nathanchance
@Maxwen
@mostafaz
@joshuous
@faux123
@rainforce279
@Paranoid Android Team
and all others devs that make our lives easier.
Special thanx for @urgali , @Sungfive and @Duncan1982 for testing .
@Cybertron™ for new thread and signature images.
@Saber for his superb thread with all detailed kernel stuff.
Short Feature list:
Basic Governors plus:
Darkness, Nightmare, Alucard, Impulse, Blu Active
Overclocked both clusters
Adjustable thermal driver
Power Efficient Workqueues
State Notifier Driver
I/o schedulers: fiops, sio, zen, maple
Adrenoboost
Adreno Idler
Simple gpu algorithm
Backlight dimmer
Kacal control
Power Suspend driver
USB Fast Charge
Eagle DTS driver
Built in Busybox
Uses a simple free and user friendly application called Synapse by @AndreiLux for configuration purposes(slightly adding more functionality)
Synapse is included in zip and flashed by default as a system app.
Synapse is based on new UKM - Lite version. It does contain less settings than standard version for less advanced users. For those who wish to use full power of Synapse additional UKM zip have to be flashed after Kernel.
UKM Full flashable zip download link
https://www.androidfilehost.com/?w=files&flid=154993
Flashing instructions
1. Flash in recovery no black magic
3. If missing tunables for governors set SElinux to permissive
Compatibility list:
LOS Kernel have been tested with official Lineage OS 15.1
PA Test Kernel works with AOSPA and its based on Paranoid Android Kernel Source and all credits belong to Paranoid Android Team.
And Finaly Download Link:
WHITE WOLF LOS 15.1
https://www.androidfilehost.com/?w=files&flid=253747]
WHITE WOLF AOSPA test kernel (Paranoid Android )
https://www.androidfilehost.com/?w=files&flid=186508
LOS Source
https://github.com/yarpiin/White-Wolf-OP3-LOS
PA Source
https://github.com/yarpiin/White-Wolf-OP3-PA
If You like my work buy me a beer https://www.paypal.me/yarpiin
XDA:DevDB Information
White Wolf Kernel, Kernel for the OnePlus 3
Contributors
yarpiin
Source Code: https://github.com/yarpiin
Kernel Special Features:
Version Information
Status: Stable
Current Stable Version: WHITE.WOLF.OP3.XXX
Stable Release Date: 2017-05-30
Created 2016-12-22
Last Updated 2018-11-30
WHITE.WOLF.OP3.LOS.15.1 - Changelog
https://github.com/yarpiin/White-Wolf-OP3-LOS/blob/master/changelog.txt
WHITE.WOLF.OP3.PA - Changelog
[url]https://github.com/yarpiin/White-Wolf-OP3-PA/blob/nougat-mr2/changelog.txt[/URL]
Hall Of Fame
This is a list of people who contributed donations to this project or helped in it
Helpers
- @urgali
- @Sungfive
- @Duncan1982
- @Cybertron™ - Thread and signature images
Donators
- @urgali
- @A Sad Napkin
- @real76
- Unknown memeber named Amir
- @ctakah27
- SB
Thank you a lot !!!
Signature Image Link
thanks!
I am downloading
Thanks man 5 stars from me
Thanks ! Wait for OxygenOS Version
Gesendet von meinem ONEPLUS A3003 mit Tapatalk
Wow awesome thx. Running very nice with my suicide squad rom. Awesome fast and smooth. Your kernel has potential keep it up
Flashed to XenonHD.
Very smooth!
Great kernel.
Keep it up.
I build a kernel and thanks for posting source I see a few govs I will add to my list
Sent from my ONEPLUS A3000 using XDA-Developers mobile app
ZeNiXxX said:
Wow awesome thx. Running very nice with my suicide squad rom. Awesome fast and smooth. Your kernel has potential keep it up
Click to expand...
Click to collapse
I'm bout flash on same.rom, lol
Uhh, something to play with on Nougat!
Good stuff
@yarpiin Have You plans to implement OC?
rafciowis1999 said:
@yarpiin Have You plans to implement OC?
Click to expand...
Click to collapse
Hi sorry but no or maybe no :silly: i was thinkin about it but im not a big fan of OC i can OC my PC ( actually higly OCed ) but not mobile chip i think we have enough of cpu power but maybe in future i will change my mind - just for now dont see any strong reason to do it
Sent from my ONEPLUS A3003 using XDA Labs
yarpiin said:
Hi sorry but no or maybe no :silly: i was thinkin about it but im not a big fan of OC i can OC my PC ( actually higly OCed ) but not mobile chip i think we have enough of cpu power but maybe in future i will change my mind - just for now dont see any strong reason to do it
Click to expand...
Click to collapse
Good reason.
I think OC will be good but not as default.
Backporting i/o schedulers and governors from newest linux will be great too (mostly cfq, deadline and interactive).
Only request would be sound controls if possible to add from ex kernel or wherever...? Running alacurd and hotplug and it's buttery smooth and awesome battery! Good job with this bro
---------- Post added at 12:33 AM ---------- Previous post was at 12:33 AM ----------
Will have any chance to make profiles for synapse?
yarpiin said:
Hi sorry but no or maybe no :silly: i was thinkin about it but im not a big fan of OC i can OC my PC ( actually higly OCed ) but not mobile chip i think we have enough of cpu power but maybe in future i will change my mind - just for now dont see any strong reason to do it
Sent from my ONEPLUS A3003 using XDA Labs
Click to expand...
Click to collapse
The only OC that is useful for this phone is upping the big cores to 2.26ghz and the little to 1.72ghz. The voltage stays the same so you get a minor speed bump but power draw is identical. This in turn gives slightly better battery life because the phone can go back to idle slightly quicker. Anything higher starts causing the phone to thermal throttle much quicker, well in my case that is.
Also, I see you have implemented hotplugging, as mentioned in many different kernel threads for multiple devices that use big.LITTLE (OP3, S6, etc.) This is uncessary and causes more battery drain while also reducing performance because these cores were designed to go idle when not in use consuming nearly zero energy. Hotplugging makes these cores jump between on and off all the time and lower and higher frequencies because of the way big.LITTLE works which causes massive microstutter and also much higher battery drain.
In the good old S6 days a couple devs tried to implement it but it never worked no matter what they tried. Sultan, one our devs here, makes an amazing custom kernel/ROM combination. He had implemented hotplugging when he first released the kernel but it turned out to not fully work properly and caused extra battery drain and microstutters. He removed it and it fixed all the issues.
Edit: haven't used the kernel yet because cm14.1 is a bugfest so this is just speculation, you could have added a little magic and it performs super well.
yung40oz84 said:
I'm bout flash on same.rom, lol
Click to expand...
Click to collapse
Suicide squad rom?
crzykiller said:
The only OC that is useful for this phone is upping the big cores to 2.26ghz and the little to 1.72ghz. The voltage stays the same so you get a minor speed bump but power draw is identical. This in turn gives slightly better battery life because the phone can go back to idle slightly quicker. Anything higher starts causing the phone to thermal throttle much quicker, well in my case that is.
Also, I see you have implemented hotplugging, as mentioned in many different kernel threads for multiple devices that use big.LITTLE (OP3, S6, etc.) This is uncessary and causes more battery drain while also reducing performance because these cores were designed to go idle when not in use consuming nearly zero energy. Hotplugging makes these cores jump between on and off all the time and lower and higher frequencies because of the way big.LITTLE works which causes massive microstutter and also much higher battery drain.
In the good old S6 days a couple devs tried to implement it but it never worked no matter what they tried. Sultan, one our devs here, makes an amazing custom kernel/ROM combination. He had implemented hotplugging when he first released the kernel but it turned out to not fully work properly and caused extra battery drain and microstutters. He removed it and it fixed all the issues.
Edit: haven't used the kernel yet because cm14.1 is a bugfest so this is just speculation, you could have added a little magic and it performs super well.
Click to expand...
Click to collapse
I don't believe the hotplug theory, I've used it with and without hotplug on this device and the 6P and when using hotplug it clearly saved battery, by a good shot too! You dint have to use it, that's why u can enable/disable, but I'm sure it saves battery as I've tested with it enabled and disabled two devices with the big.LITTLE setup. And honestly, besides one other kernel that is not in these threads, this is the best kernel I've used to date for the OP3, on CM that is, not stock. I've ran ex, boeffla, all CM kernels and as I mentioned one other not located in these threads and that one and this are damn good, they each have their benefits, and the hotplug def saved battery as I've already passed my regular SOT at 40 percent left. Of course I will test without, but with my previous tests on the 6P the hotplug continuously saved battery. Sometimes it mate cause stutter or slowness, but I have not noticed that on the OP3 as of yet, it hasn't slowed a thing down, and there are 2 hotplug options in this kernel, and the hotplug in the 6P was msm which is not one that's in this kernel. This has two other options, alacurd and autosmp.
OC - as i said if there are solid reasons then yes might think about it . But from theory higher frequency equals higher temp and faster thermal throttling
Hotplugging - never heard about theory that make hotplugging causing more battery drain than keeping all clusters/cores online it is a bit non sense for me. Anyway stock Qualcomm kernels are hotplugged using msm performance and core ctl . As i dont like them they been replaced by custom made hotplugging drivers that are optional you can activate and deactivate driver as you wish
CM14.1 - I was on official and now on RR and havent noticed any major bugs neither small ones , they are solid enough to be a daily drivers
Sent from my ONEPLUS A3003 using XDA Labs