It's been a while since the last shamu update. I did builds for the other devices and tested some things for shamu in the mean time. There's always something to do on one of the devices ;-)
Changelog:
-updated BFQ
-merged some ext4 patches from linux upstream
-merged some caf kgsl patches
-merged various other patches for several subsystems to improve battery life and efficiency
-added adreno idler
-prevent bcl driver to kick out cores in some cases
hC-b1-M
hC-b1-mako-M
hC-b7-ZEN
hC-b7-mako
Have fun! (=
hells
Banner
Mittwoch, 24. Juni 2015
Dienstag, 23. Juni 2015
Nexus 5: b17-L / b3-M
Samstag, 20. Juni 2015
Nexus 4: b80
Some people mentioned scrolling issues on chrome. I've investigated it a little and the whole thing seems very contradictory to me. Anyway, I looked around and saw a dev reverting some gpu patches to fix this issue, so I did the same. Please let me know if its better now.
Changelog:
-updated BFQ
-reverted gpu patches to fix chrome issues (need feedback on that one!)
-some little fs fixes
-hellsCode from @Maxr1998
AOSP
CM
Have fun! (=
hells
Changelog:
-updated BFQ
-reverted gpu patches to fix chrome issues (need feedback on that one!)
-some little fs fixes
-hellsCode from @Maxr1998
AOSP
CM
Have fun! (=
hells
Sonntag, 14. Juni 2015
Nexus 5: b16-L / b2-M
Since M-preview sources on shamu were also working on Lollipop and improved idle drain and snappiness, I've also tried to merge the M-preview stuff into our Lollipop kernel. The kernel runs more than 24 hours on several devices and seems to run quite well. I've updated BFQ I/O sched and merged some little fixes for other subsystems on both releases (-L and -M). I still do two builds, since the -M kernel needs Selinux to be disabled to allow root, and the Lollipop kernel doesn't need that.
Changelog:
Lollipop:
-merged M-preview source
-updated BFQ
-merged little fixes here and there
M-preview:
-updated BFQ
-merged little fixes here and there
hC-b16-L
hC-b2-M
Have fun! (=
hells
Changelog:
Lollipop:
-merged M-preview source
-updated BFQ
-merged little fixes here and there
M-preview:
-updated BFQ
-merged little fixes here and there
hC-b16-L
hC-b2-M
Have fun! (=
hells
Donnerstag, 11. Juni 2015
Nexus 6: ZEN or mako?
It seems to be the question of the week. I'll try to explain the differences in this post and how they can affect battery life.
ZEN uses zen decision hotplug. ZEN only onlines all cores on screen on, it also takes thermal events into account and wont online any core back, if you're under 15% battery, or currently have a thermal event, because of heat. So in the end it isn't a "real" hotplug driver, because it doesnt have any code for active hot plugging in it. That means you cant change its behavior.
mako uses mako hotplug. The mako kernel also comes with an all cores online setup, but you can change it to dual core on light tasks and quadcore for heavy tasks, if you higher the "load_threshold" from "0" to "80" for example.
So does that mean ZEN is for performance and mako for battery? There's no "real" answer to this question. You have to think about some points here:
Every time a core gets kicked in, there have some calculations to be made, which needs battery. Onlining a core also needs some battery every time. You're using your device and cores are getting kicked in and out, because you have some more idle phase and some more heavy load phase. It can also happen that the hotplug thinks its an idle phase right now, offlines cores and the governor has to higher the frequencies of the left cores to handle the load. After some time all cores are coming back and the frequency falls again. In the end it would've been more efficient to have all cores online during that period, because the load could've been handled with lower frequencies between all cores. Remember: All four cores online on a lower frequency is always better than having two cores online in high frequencies.
Remember also that even if all cores are online, it doesnt mean a core cant enter a battery saving idle state if it doesnt have anything to do. Online doesnt mean the core is active the whole time, it just doesnt get kicked out, which in the end is best for low latencies. The higher the idle state, the more time it needs to get active again. But its always faster than getting kicked out.
There's much misinformation about that setup in general. All cores online all the time can save some battery, because there are no calculations and onlining/offlining, which is a battery draining factor. In the end it depends on your usage, which setup is better for you. In some cases active hotplugging is the better choice, in some cases its better to run all cores without any active hotplug. YOU have to test, which suits YOU better.
UPDATE 09/12/15
Since I rebased my kernel, we are now able to switch between mako and ZEN in one kernel, by disabling the one and enabling the other.
ZEN uses zen decision hotplug. ZEN only onlines all cores on screen on, it also takes thermal events into account and wont online any core back, if you're under 15% battery, or currently have a thermal event, because of heat. So in the end it isn't a "real" hotplug driver, because it doesnt have any code for active hot plugging in it. That means you cant change its behavior.
mako uses mako hotplug. The mako kernel also comes with an all cores online setup, but you can change it to dual core on light tasks and quadcore for heavy tasks, if you higher the "load_threshold" from "0" to "80" for example.
So does that mean ZEN is for performance and mako for battery? There's no "real" answer to this question. You have to think about some points here:
Every time a core gets kicked in, there have some calculations to be made, which needs battery. Onlining a core also needs some battery every time. You're using your device and cores are getting kicked in and out, because you have some more idle phase and some more heavy load phase. It can also happen that the hotplug thinks its an idle phase right now, offlines cores and the governor has to higher the frequencies of the left cores to handle the load. After some time all cores are coming back and the frequency falls again. In the end it would've been more efficient to have all cores online during that period, because the load could've been handled with lower frequencies between all cores. Remember: All four cores online on a lower frequency is always better than having two cores online in high frequencies.
Remember also that even if all cores are online, it doesnt mean a core cant enter a battery saving idle state if it doesnt have anything to do. Online doesnt mean the core is active the whole time, it just doesnt get kicked out, which in the end is best for low latencies. The higher the idle state, the more time it needs to get active again. But its always faster than getting kicked out.
There's much misinformation about that setup in general. All cores online all the time can save some battery, because there are no calculations and onlining/offlining, which is a battery draining factor. In the end it depends on your usage, which setup is better for you. In some cases active hotplugging is the better choice, in some cases its better to run all cores without any active hotplug. YOU have to test, which suits YOU better.
UPDATE 09/12/15
Since I rebased my kernel, we are now able to switch between mako and ZEN in one kernel, by disabling the one and enabling the other.
Dienstag, 9. Juni 2015
Nexus 6: b7-t2 (Lollipop)
I've played around with some "M-preview" stuff and saw a nice improvement in interactivity and idle drain, so I decided to use the whole "M-preview" sources for Lollipop now. This release is basically b1-t2-M, without the SELinux hack to get root working on "M" and a little change in the anykernel template to use the correct offsets for the generated boot.img. I did a little idle test during the night and here's what I got:
Not bad, huh? ;) No airplane mode cheat or other tricks were used to achieve that. I'm using an unofficial SlimLP build by fraz14.
Changelog:
-based upon the rebased M-preview-sources test kernel
-reverted the SELinux hack to get root working on M
-added mako_hotplug build
Have fun! (=
hells
Montag, 8. Juni 2015
Nexus 6: b1-t2-M
I've played around with the M sources and added some little fixes for it. I've also made an "M" build with mako_hotplug.
Changelog:
-added some fixes for several subsystems (audio, video, gpu and mdss)
-added a mako_hotplug build
hC-b1-t2-M
hC-b1-t2-mako-M
Have fun! (=
hells
Changelog:
-added some fixes for several subsystems (audio, video, gpu and mdss)
-added a mako_hotplug build
hC-b1-t2-M
hC-b1-t2-mako-M
Have fun! (=
hells
Nexus 4: b79
I didn't make anything new for mako for quite some time now. It seems b78 was as stable as the stable ones before. The problems I had between b73 and b78 were not related to the kernel as it seems. I don't blame anyone for thinking it could be a kernel related problem, because most of the time a SOD happens, its the kernel. I've added francos input listener and francos conservative back, because some people like it more than the conservative we had before. And with francos input listener the min_freq doesn't get changed, so no more "why my min freq is changing" questions anymore, yaaay ;)
Changelog:
-added back francos input listener
-added back francos conservative
-added input boost logic to hellsactive
hC-b79-L
hC-b79-CM
Have fun! (=
hells
Changelog:
-added back francos input listener
-added back francos conservative
-added input boost logic to hellsactive
hC-b79-L
hC-b79-CM
Have fun! (=
hells
Nexus 6: b1-t1-M
I did a complete rebase upon the Android "M" sources. I had to remove a few commits to boot without issues, but it shouldn't affect the kernel and user experience in any way :) Since I trained rebases a lot in the past, it was not that time consuming like it was in the beginning. This "M" kernel currently only has zen-decision without active hotplugging. I have plans to make a mako_hotplug "M" release in the next few days.
Changelog:
-rebased upon Android "M" sources
hC-b1-t1-M
Have fun! (=
hells
Changelog:
-rebased upon Android "M" sources
hC-b1-t1-M
Have fun! (=
hells
Nexus 6: b6
I've added some more mainline and upstream fixes for several subsystems. I'm very happy with the performance, idle drain and screen on drain on this kernel version. I got some reports about bad battery life, but I think it depends on the configuration and usage. I never stated I make a kernel for everybody. If it suits your need I'm more than happy, if it doesn't run nice, or causes battery drain you may need to look for a kernel that suits you better :)
Short explanation about the two kernel:
hC-b6 is shipped with mako_hotplug from franco and runs quadcore mode per default. You can change that behavior, if you higher the "load threshold" from "0" to "80" for example.
hC-b6-ZEN is shipped with zen-decision from bbedward. Its runs quadcore mode per default and doesn't give you the ability to change that behavior.
Changelog:
-compiled with UBERTC 5.1.1
-bcmdhd: wifi: updates from google bcmdhd repo
-suspend/power/wakeup commits from google common 3.10 repo
-various sched, cgroup, mm, und workqueue patches from upstream / Linux 4.0
-writeback fixes von Linux Mainline
-power efficient workqueues - Some non performance oriented tasks will choose an active core instead waking up and idle core.
-slub/slab allocators synced with Linux 3.18
-merged lollipop 5.1.1 kernel sourcen
-some anykernel specific changes, simplyfied and fixed a thermal issue.
hC-b6
hC-b6-ZEN
Have fun! (=
hells
Short explanation about the two kernel:
hC-b6 is shipped with mako_hotplug from franco and runs quadcore mode per default. You can change that behavior, if you higher the "load threshold" from "0" to "80" for example.
hC-b6-ZEN is shipped with zen-decision from bbedward. Its runs quadcore mode per default and doesn't give you the ability to change that behavior.
Changelog:
-compiled with UBERTC 5.1.1
-bcmdhd: wifi: updates from google bcmdhd repo
-suspend/power/wakeup commits from google common 3.10 repo
-various sched, cgroup, mm, und workqueue patches from upstream / Linux 4.0
-writeback fixes von Linux Mainline
-power efficient workqueues - Some non performance oriented tasks will choose an active core instead waking up and idle core.
-slub/slab allocators synced with Linux 3.18
-merged lollipop 5.1.1 kernel sourcen
-some anykernel specific changes, simplyfied and fixed a thermal issue.
hC-b6
hC-b6-ZEN
Have fun! (=
hells
Nexus 5: b1-M
I merged the "M" sources and made a quick build. Its runs since a few days and seems to be stable.
Changelog:
-merged "M" sourcen
hC-b1-M
Have fun! (=
hells
Changelog:
-merged "M" sourcen
hC-b1-M
Have fun! (=
hells
Nexus 5: b15
I merged the 5.1.1 sources and added the input boost logic to hellsactive to work with the input listener. I think we're on a very good base for hammerhead.
Changelog:
-merged 5.1.1 sources
-added boost ability to hellsactive
b15-L
Have fun! (=
hells
Changelog:
-merged 5.1.1 sources
-added boost ability to hellsactive
b15-L
Have fun! (=
hells
Nexus 4: b78
Sonntag, 7. Juni 2015
Welcome to my blog!
Hi guys,
Since there are many places where you can follow me, but none of them are really overseenable (or what do you call it, when people are asking me where to download the kernel IN the download section in my G+ community?) for some reasons.
So lets try it with a little blog for my work (=
hells
Abonnieren
Posts (Atom)