[ZEN-KERNEL] 3.10-zen21 "Cheap and Easy" (May 20) - Nexus 6 Original Android Development

Pushbullet: https://www.pushbullet.com/channel?tag=zen
{
"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"
}
But you say I'm just a friend
Project Background
First of all. I like the nexus 6. Actually, I really really like the nexus 6. I think the device from factory performs quite marvelously, especially since the 5.1 update. Because of this, I am actually pretty content with running the stock kernel. "But BB...What about INTelligentSuperBOOSTXX5MillionPOINT5MegaBlast?!?!?!? Can you add this!?". While I appreciate all the great and free work that several great individuals do for the community. I personally don't see the need to alter any of these MSM/Board drivers a whole lot - not on these latest generation of devices. Things run pretty well I think.
"Why don't you just run the stock kernel then you sick low-life waste of space?"
Because, I still think improvements can be made.
I think there's a lot of good intentions out there to make improvements in the kernel-space, BUT:
I've observed a variety of things that were prevalent a couple of years ago and that are still prevalent today. (1) A lot of small things are changed - and advertised as a huge improvement, (2) some tunables are adjusted and advertised as a huge change/improvement but end up being a regression because they were never tested, or (3) some code is merged that causes regressions and it turns out that self-inflicted bugs are being chased around.
Zen is an attempt at improving the stock kernel. That's it.
Project Summary
The Zen kernel has always been oriented at improving the experience for desktop mobile users as much as possible. This iteration of the series is no different. The goal is simple: Improve the experience.
BFS CPU Scheduler
BFS is an alternative CPU scheduler to the stock kernel's CFS. BFS features a simple single-runqueue O earliest virtual deadline first design. There is no need for excessive balancing to achieve fariness on multiple runqueues - fairness is ensured by deadlines.
The goal of the Brain **** Scheduler, referred to as BFS from here on, is to completely do away with the complex designs of the past for the cpu process scheduler and instead implement one that is very simple in basic design. The main focus of BFS is to achieve excellent desktop interactivity and responsiveness without heuristics and tuning knobs that are difficult to understand, impossible to model and predict the effect of, and when tuned to one workload cause massive detriment to another.
Click to expand...
Click to collapse
BFS is tweaked towards human perception. It is not a real-time scheduler (like the SCHED_DEADLINE policy/scheduling in 3.14+) nor does it use runtimes+red/black trees to figure out fairness. It uses deadlines with the 6ms rr_interval based on the fact that humans cannot detect jitters until >= 7ms.
Anyway, not going to get into it much but you may find more information in post 2, or throughout this thread (I explained a bit more details about it around page 4).
Also, check these out:
BFS FAQ
BFS Wikia
Android/MSM 3.10 BFS Port
What is different about this and the 3.10-ck1 bfs v440 patch available on ck.kolivas.org
Backport fixes and features (not SMT NICE) from up to bfs v460ish
Some of Alfred Chen's upstream synchronization and refactoring of BFS methods (linux-3.18/19-gc branch)
My own syncing with mainline as well as backporting
What does this mean
Suspend/Wake issues that were killer on bfs v440 for 3.10 are not present in this port - these issues have been resolved.
You should NEVER report any issue related to this kernel upstream. Not android, linux, or BFS related. Do not report any issues anywhere but here.
"How about the performance?"
This kernel is all about interactivity by default.
The default rr_interval is set to 6. The logic is the human eye cannot detect jitter until about 7ms. Try lowering it if you want to increase interactivity. Try increasing it to achieve higher thoroughput.
-------------------------
Zen/Shamu Features
BFS CPU Scheduler
@flar2 Wake Gestures
@savoca KCAL Screen Color Control
@imoseyon Vibration SysFS interface
USB Fastcharge Support
Fsync SysFS Interface
Overclocking support
Flar2 userspace CPU voltage control
f2fs support and latest f2fs: f2fs/dev (even with ZenyKernel zip)
FIOPS + BFQ + SIO in addition to the stock ROW, CFQ, Deadline, No-op I/O schedulers
Several misc. CAF/msm + upstream updates/fixes.
Forced encryption disabled. (Even With ZenyKernel zip)
Added init.d support (ZenyKernel is up to your existing ROM/kernel)
selinux adjustments for viper4android and other things (ZenyKernel is up to your existing ROM/kernel)
Compatible with most ROMs, use ZenyKernel zip if there's compatibility issues.
Added zRam support
MPDecision disabled by default, replaced by touchboost listener + ZenDecision 2.0
ZenyKernel based on @osm0sis AnyKernel2 to use for roms who break compatibility with stock ramdisk
I work based on real results from user experience, not numbers. I don't claim anything as a big deal if it isn't one. Zen is a no-nonsense, well-tested kernel making real improvements to interactivity in the kernel space.
---------
Releases
All of these builds are for android 5.1 and above, unless otherwise noted
Wipe /cache before flashing for best results
Versions
- Recovery Zip: Kernel+Ramdisk: Use this on a stock/stock-like rom, or on a rom without support for things like viper4android or init.d support. Flash in recovery.
- Boot.IMG: Kernel+Ramdisk: Same as recovery zip, except in the raw boot.img form. Can be flashed in fastboot, flashify, etc.
- ZenyKernel Zip: Kernel Only (+ no force encryption +f2fs support +zen settings): Will use the exact same ramdisk you already have. If you have issues with the other full versions, then dirty flash your rom and this on top of it.
3.10-zen21 "Cheap and Easy"
Changes:
Compile with GCC 5.1
Several bcmdhd/wifi driver updates
Misc. CAF updates
Fix come cores sticking to performance governor
3.10-zen21 Recovery Zip Download
3.10-zen21 boot.img (install via fastboot/twrp IMG) Download
3.10-zen21 ZenyKernel Zip (Use on top of ROM dirty flash if issues with the above two)
Legacy Releases
3.10-zen20_rev2 "Grad Party"
Changes:
Disable MPDecision by default
ZenDecision 2 - Driver to ensure all cores are online when they are supposed to be online (tunables in /sys/kernel/zen_decision)
TouchBoost generic interface from franco, but modified for globalization
CPU-BOOST: Strip all existing input_boost functionality, use the existing parameters for the new touchboost interface
Slub: Update to newer upstream version of the mem. allocator ported by @XileForce
OC: Add 3.09GHz support (requires v2 of zen_max_freq zip)
msm_hsic wakelock slider...
f2fs: numerous upstream updates
conservative: add franco's twostep counter functionality
conservative: adjust default settings
interactive: adjust default settings
ondemand: Update frequency decision making from upstream
ondemand: Adjust defaults to be less aggressive
BFQ default I/O scheduler - based on significant interactivity improvement benchmarks on solid state and emmc memory.
rev1 fixes issue setting bat_threshold_ignore in ZenDecision
rev2 fixes issues with f2fs
3.10-zen20 Recovery Zip Download
3.10-zen20 boot.img (install via fastboot/twrp IMG) Download
3.10-zen20 ZenyKernel Zip (Use on top of ROM dirty flash if issues with the above two)
3.10-zen19 "Show Stopper"
Changes:
Revert to MPDecision by default. I don't have the time to fully implement a replacement ATM
BFS: Sync try_to_wakeup_* and ttwu_*
BFS: Replace resched_task with resched_curr
BFS: add soft_affined flag
BFS: sync context_switch and finish_task_switch
F2FS: Numerous upstream updates
MSM/KGSL: CAF Fixes/Updates
MSM/MDSS: CAF Fixes/Updates
MSM/mmc: CAF Fixes/Updates
MSM/vidc: CAF Fixes/Updates
MSM/QoS: CAF Fixes/Updates
Misc general upstream updates
Wake Gestures: Disable haptic by default
3.10-zen19 Recovery Zip Download
3.10-zen19 boot.img (install via fastboot/twrp IMG) Download
3.10-zen19 ZenyKernel Zip (Use on top of ROM dirty flash if issues with the above two)
3.10-zen18 "Think Twice"
Changes:
Disable MPDecision by default
Delegate MPDecision's input boosting (raising min_freq) to cpu-boost
Default cpu-boost touch boost set to 2s @ 1.497GHz, configurable in user space
ARM Updates
Some BFS updates
Fair Queue packet scheduler (Queue discipline)
Heavy-Hitter Filter Qdisc
PIE AQM Qdisc
I/O Scheduler: Change default deadline scheduler settings
I/O Scheduler: Add simple I/O scheduler v0.3 (user request - default remains CFQ)
ARM/Crypto: optimized SHA-256/224 (faster encryption performance)
Kcal updates
F2FS updates from upstream
Standard ramdisk support for CM12.1 and friends
The net schedulers are probably useless to the average user, but harmless. A couple people who like to play with network stuff may want to play around with them by using the "tc" command. If you aren't sure you don't need to do anything :silly:
3.10-zen18 Recovery Zip Download
3.10-zen18 boot.img (install via fastboot/twrp IMG) Download
3.10-zen18 ZenyKernel Zip (Use on top of ROM dirty flash if issues with the above two)
3.10-zen17 "Epidemic"
Changes:
Fix GPU frequency displaying low power modes
MDSS/Panel: misc. updates
MM: Misc upstream updates
CPUFreq: General CPUFreq driver updates/fixes
CPUFreq/Interactive: Numerous updates
BCMDHD: Reduce packet timeout, supposed to reduce wlan_rx wakelock
MSM/Power: quickwakeup driver from motorola + implementation
MSM/PM: Replace BUG_ON usage with correct solutions
AnyKernel: Remove device check, some devices that identified as something besides "shamu" had issues flashing.
3.10-zen17 Recovery Zip Download
3.10-zen17 boot.img (install via fastboot/twrp IMG) Download
3.10-zen17 AnyKernel Zip (Use for CM 12.1 or other roms that change ramdisk/sepolicy things)
3.10-zen16 "Yippee Ki-Yay"
Changes:
Revert ext4/3.18 backport which caused periodic lockups.
Merge up ext4 from v3.10.74 in lieu of the above
Add faux sound support
Adaptive LMK default
msm: vid coder possible null pointer fix from CAF
msm: mdss/panel fixes from CAF
kmemleak reporting improvements from upstream
3.10-zen16 Recovery Zip Download
3.10-zen16 boot.img (install via fastboot/twrp IMG) Download
3.10-zen16 AnyKernel Zip (Use for CM 12.1 or other roms that change ramdisk/sepolicy things)
3.10-zen15 "Unbroken"
Changes:
All the great changes of zen14 except without the BFS LLC cpumask selection - was an issue causer
Updated kcal (I forgot to merge into 14)
3.10-zen15 Recovery Zip Download
3.10-zen15 boot.img (install via fastboot/twrp IMG) Download
3.10-zen14 "Flight School"
Changes:
BFS: Full cpumask LLC cpu selection from -gc
BFS: Some trivial cleanups and fixes
Sched/BFS: Brought in the scheduler attr stuff from v3.14
rtmutex: deadlock detect fixes from upstream, prio. boost support for __setscheduler
Everything: Dozens and dozens of relevant i2c/usb/pinctrl/others race condition fixes, memory leak, deadlock fixes, etc. from upstream v3.10.y (without pulling it all I cherry picked relevant stuff)
VMA cache from upstream
ARM fixes from v3.10.y
Asynchronous I/O updates and unnecessary plug I/O removed for SSDs
Just dumped all my KGSL changes and sync'd with newest stuff from leankernel because i was too lazy to bisect and determine what was causing random page faults (they may still be there, they are on stock kernel too)
MSM: Updated sound soc
CM12.1 and friends AnyKernel zip added
3.10-zen14 Recovery Zip Download
3.10-zen14 boot.img (install via fastboot/twrp IMG) Download
3.10-zen14 AnyKernel Zip (Use for CM 12.1 or other roms that change ramdisk/sepolicy things)
3.10-zen12 "On top of the World"
Changes:
BFS: Sync up some tick accounting from upstream
LEDS: Merge in 13 or so patches. Fixes bugs such as concurrency issues as well as adds some features
MDSS: Merge in over a dozen patches, refactorizations, and bug fixes
Crypto: Update NEON/AES module
3.10-zen12 Recovery Zip Download
3.10-zen12 boot.img (install via fastboot/twrp IMG) Download
3.10-zen11 "Too Fast, Too Furious"
Changes:
Fix a bug in modem that I created
BFS: Add grq lock for priodl (alfred chen -gc)
BFS: Fix a potential bug but probably not in __schedule
Proc/MMU: Merged a bug fix and cleanup patchset.
3.10-zen11 Recovery Zip Download
3.10-zen11 boot.img (install via fastboot/twrp IMG) Download
3.10-zen10 "Interstellar"
Changes:
Reverted the red/black tree change to LowMemKiller. I observed some issues with it, perhaps I was missing fixes for it. Certainly the RBTree selection is much faster than the previous iterative method. But how much do we really care about the performance of LMK with 3GB ram?
Upstream CFQ bug fixes
(1) SMP: Added wake_up_all_idle_cpus function
(2) BFS: Added wake_up_if_idle function
(3) CPUIdle: Use wake_up_all_idle_cpus instead of old kick_all method. Should result in reduced cpuidle latency/better performance
Adreno: revert to stock wake-up latency of 490, from 101.
3.10-zen10 Recovery Zip Download
3.10-zen10 boot.img (install via fastboot/twrp IMG) Download
3.10-zen9 "Sunshine and Whiskey"
Changes:
Completely rebased my entire tree. Based on stock/msm tree again.
Pulled in all VM/MM updates from linux-3.10.y
Updated f2fs to latest f2fs/dev.git (Up to "f2fs: do not recover wrong data index")
Fix a KGSL bug that would result in page faults
Updated MSM V4L2 video driver (msm: vidc)
Misc. updates throughout the kernel and MSM to resolve potential memory leaks
Built a new compiler from latest linaro, building with that now instead of my antique one.
3.10-zen9 Recovery Zip Download
3.10-zen9 boot.img (install via fastboot/twrp IMG) Download
3.10-zen8 "Notorious Z"
Changes:
Repair self-inflicted wounds
KGSL+Adreno fixes
Buy food for phil the cat
Buy coffee
Pick up jacket from dry cleaner
3.10-zen8 Recovery Zip Download
3.10-zen8 boot.img (install via fastboot) Download
3.10-zen7 "Space Bound"
Changes:
BFS: fix hotplug bug related to affinity set/get
block: Add FIOPS I/O scheduler
ARM: numerous upstream updates/fixes
MSM: usb/bam numerous fixes
MSM: mdss numerous fixes
MSM: kgsl numerous fixes
MSM: camera numerous fixes
3.10-zen7 Recovery Zip Download
3.10-zen7 boot.img (install via fastboot) Download
3.10-zen6 "Morning After"
Changes:
qcom-cpufreq allow a boot parameter to specify max_freq, which determines how to populate the frequency table. By default it is the stock 2.6GHz. If you use the aroma zip at the end of this post you can choose up to 3.03GHz. This kernel code/method is from @flar2 I only made minor/trivial changes to it and hacked up the aroma so people can change the boot parameter easily..
Changed f2fs mount options again, for more stability
3.10-zen6 Recovery Zip Download
3.10-zen6 boot.img (install via fastboot) Download
3.10-zen5_rev1 "Day Drinking Sunday = Rough Monday"
Changes:
Added kexec-hardboot support for multirom
Adjusted f2fs default mount options (nobarrier on /data) (inline_dentry, extent_cache on /data and /cache). Zen4 f2fs was acting really slow, this fixes it
Build f2fs with security labels for selinux
Added BFQ v7r7
Added 2.95GHz and 3.03GHz overclock steps
BFS: refactor sched_init_smp
BFS: cleanup/remove unused above_background_load function
3.10-zen5 Recovery Zip Download
3.10-zen5 boot.img (install via fastboot) Download
3.10-zen4 "Bottoms Up"
Changes:
Merged v3.10.73 from linux-stable/linux-3.10.y
Overclock to 2.9GHz
Userspace voltage control from flar2
f2fs support and latest f2fs/linux-3.10 merged
ext4 3.18 backport, from ext4/backport-for-3.10
BFS rr_interval set back to default of 6
Several CAF KGSL/MDSS Fixes/Improvements
I/O Deadline some tweaks
3.10-zen4 Recovery Zip Download
3.10-zen4 boot.img (install via fastboot) Download
3.10-zen4 boot.img (use for f2fs, has security labels for selinux - Zen4 forgot to include it)
3.10-zen3 "Walking Tall"
Changes:
Fixed issue with KCAL app caused by zen2 ramdisk changes
Reverted culprits of random OOPs' and PANIC issues
Added vibration sysfs interface (same one as leanKernel)
Support for frequency mitigation (from imoseyon). If you just want to change the battery throttling I suggest you see post #2 instead though
1 misc. change
Internal changes that make me feel good inside
3.10-zen3 Recovery Zip Download
3.10-zen3 boot.img (install via fastboot) Download
3.10-zen2 "Where is the love?"
Changes:
Synced up some ramdisk stuff from imoseyon for other rom/CM compatibility
Added a fix from v3.10.51 to fix random oops' caused by my compiler
3.10-zen2 Recovery Zip Download
3.10-zen2 boot.img (install via fastboot) Download
3.10-zen1 "Dollar Drink Night"
3.10-zen1 Recovery Zip Download
3.10-zen1 boot.img (install via fastboot) Download
ZenDecision (zen20+)
You can still turn on MPDecision without any ill effects if desired
As of 5.1+ MPDecision is somehow responsible for at least the following:
Raise MIN_FREQ to 1497MHz for 3 seconds on touch events
Ensure CPUs come online after certain events, like thermal events (due to low battery for example)
User configurability is sacrificed when it is enabled. For example: changing minimum CPU frequency is not possible, nor is changing the touchboost frequency or duration possible. Simply disabling MPDecision results in the permanent disabling of CPUs in certain situations (until the user either reboots, or manually turns them on again).
ZenDecision is a simple "handler" for to keep CPUs online by the following logic:
When screen comes on, make sure all CPUs are online if current battery level is above bat_threshold_ignore
Simple, not a complete replacement for MPDecision. Just a handler for the event of cores never coming back online. Touchboosting is now configurable through the standard cpu-boost module parameters.
ZenDecision tunables (/sys/kernel/zen_decision/):
enabled (0=disabled, 1=enabled): Enable/Disable the driver from doing any work
wake_wait_time (0-60000 ms, 1000 by default): How long to wait to execute CPU_UP work after screen comes online.
bat_threshold_ignore(1-100, 0=disabled, 15 by default): The battery percentage to ignore CPU_UP operations. If current battery level is below this level, then the driver is essentially disabled.
How to enable overclocking (zen6+)
If your device is unstable at the overclocked frequencies, it is a hardware limitation with your device. Do not report it as a bug
To enable overclocking on zen6 or newer, you will need to use the recovery zip/aroma below.
You choose the max frequency you want, it pulls the boot.img from the device, adds a boot parameter specifying the OC frequency.
If you are not on zen6 or newer it will have no affect.
This does not install a kernel, you still have to install the kernel from one of the links above
Zen Overclock Enable v2
3.09GHz step only supported on zen20+
Thanks guys, and enjoy. Feedback is always appreciated.
XDA:DevDB Information
Zen Kernel, Kernel for the Nexus 6
Contributors
bbedward, purian23
Source Code: https://github.com/bbedward/ZenKernel_Shamu/
Kernel Special Features: Android/MSM BFS Port, kcal, gestures, cool stuff
Version Information
Status: Stable
Current Stable Version: 21
Stable Release Date: 2015-05-20
Created 2015-03-24
Last Updated 2015-05-20

---

FAQs:
Based on 5.1 Stock Kernel - It should work on all AOSP & CM ROMS
Disabled forced encryption - Meaning if your encrypted you'll stay that way, if you aren't, you'll stay that way
CPU Interactive Governor - Conservative/OnDemand/Userspace/Powersave/Performance Available
CFQ I/O - Deadline/Noop/Bfq/Row/FIOPS Available
Overclocking now available up to 3GHz - Must use Aroma OC Zip above.
F2FS Support - Find out how to enable this here!
KCal Colors by Savoca
Full Wake Gestures by flar2
Double Tap to Wake / Sweep to Sleep / Sweep to Wake
New stock setting - 5.1 throttles at 40% and again at 20% battery life - See the dev's details below on how to change this
@bbedward Regarding 40-20% Battery Throttle
Typically in the old days (which is the last time I was around) this type of thing would be in a cpufreq kernel driver using methods from the battery driver, and possibly allowing configurability through a basic sysfs interface. However, this is not the old days.
I inquired to my good friend imoseyon (I say good friend, he'd probably say "friend? you mean that crazy guy who i talked to once and now he keeps asking if I want to hang out?")
It appears that this battery change goes through the msm_thermal driver through a userspace process. The sad news is that there isn't a way to differentiate between thermal-related calls and these battery-related calls at the kernel level.
BUT,
this specific behavior can be disabled in the userspace (just not in the kernel space) - You will need root access (or you could make this change through twrp)
I will point you to this file (Which you should make a backup of before making any changes to it):
Code:
/system/etc/thermal-engine-shamu.conf
You can either edit it in something like root explorer, or pull it down through adb like this:
Code:
# adb pull /system/etc/thermal-engine-shamu.conf
Open it in your editor of choice (on windows I suggest you use something that supports unix line endings, like notepad++)
Point yourself to BAT-SOC-CPUFREQ near the top of the file
Code:
[BAT-SOC-CPUFREQ]
algo_type monitor
sensor soc
sampling 5000
thresholds 60 80
thresholds_clr 59 79
actions cpu cpu
action_info 2265600 1728000
Interpreting this is pretty straight forward:
- sampling 5000 : I guess how often (probably in ms) that it compares battery % to thresholds and thresholds_clr
- thresholds 60 80: defines two thresholds in which to take actions
- thresholds_clr 59 79: defines two thresholds in which to clear actions
- actions cpu cpu: the action to take (like a method) when thresholds are met
- action_info 2265600 1728000: action parameters that are apparently used to change scaling_max_freq
Read from thresholds down like a column
The bit that tells it to reduce frequency to 2.26Ghz at 40% and back to 2.6 at 41% is this:
Code:
thresholds 60
thresholds_clr 59
actions cpu
action_info 2265600
Where thresholds 60 refers to 40% battery by apparently % discharged (100-60 = 40%). Similarly thresholds_clr 59 (100 - 59 = 41%)
Anyway lets you say you want to throttle to 2.26GHz at 20% and at 21%+ you want to be back to normal scaling_max_freq (2.6Ghz stock) You should change it to look like this:
Code:
[BAT-SOC-CPUFREQ]
algo_type monitor
sensor soc
sampling 5000
thresholds 80
thresholds_clr 79
actions cpu
action_info 2265600
Save the file thermal-engine-shamu.conf and push back to device (or in root explorer you are already there)
Code:
# adb remount rw /system
# adb push thermal-engine-shamu.conf /system/etc/
# adb remount ro /system
Changes will probably take effect after you restart the thermal-engine service (if not, then do a reboot).
Code:
# adb shell stop thermal-engine
# adb shell start thermal-engine
Also notice the exact same applies for GPU frequency throttling and HOTPLUGGING due to battery
On stock 5.1 - Here is everything that happens and can be understood from the default thermal-engine-shamu.conf (related to battery):
CPU is throttled to scaling_max_freq 2.26GHz @ 40% battery
CPU is throttled to scaling_max_freq 1.7GHz @ 20% battery
GPU is throttled to 500MHz @ 45% battery
GPU is throttled to 389MHz @ 10% battery
GPU is throttled to 300MHz @ 5% battery
CPU3 (core #4) is removed (hot-unplugged) @ 15% Battery
CPU2 (Core #3) is removed (hot-unplugged) @ 8% Battery
Hotplug and GPU throttle behavior can be changed in the same thermal-engine-shamu.conf on the subsequent lines. (Exact same logic as described above, but actions/methods are different OFC)
Code:
[BAT-SOC-HOTPLUG]
algo_type monitor
sensor soc
sampling 5000
thresholds 85 92
thresholds_clr 84 91
actions hotplug_3 hotplug_2
action_info 1 1
[BAT-SOC-GPU]
algo_type monitor
sensor soc
sampling 5000
thresholds 55 90 95
thresholds_clr 54 89 94
actions gpu gpu gpu
action_info 500000000 389000000 300000000
So this is actually quite an easy thing to adjust. I know that franco/imoseyon have taken further actions to (and are currently working on):
Prevent this sort of userspace changes from going through msm_thermal driver, by rewriting the driver to only deal with thermal stuff (basically - and probably as it should do to begin with). Apparently this is a little problematic because QC/Moto/Goog have used this driver and its ioctl to funnel other important stuff through (that isn't thermal-related but is still important)
To lock specific msm_thermal userspace processes from making changes to cpufreq
But there are other factors in play there that complicate things.
Disabling the specific behavior of throttling CPU+GPU and disabling hotplugging at certain battery percentages is extremely easy through that configuration file.
Edit: More Knowledge Added - 4/7/15
Each row represents an array essentially, but if you specify something like 3 values for thresholds you need to specify 3 threshold_clr and 3 actions and 3 action parameters.
It's hard for me to say how the thermal engine behaves if you specify something wrong. Ideally you would assume that the parser is smart enough to handle things done incorrectly - and that the service itself is smart enough to have fallback for critical things if they are missing (I don't trust QC enough to assume that's the case), but it's impossible to say without guessing unless we saw the thermal-engine source (this is the service that's in the userspace - not in the kernel). Remember this is a qualcomm piece of software, and because /system is always mounted read-only in android (unless you access it with root access or through a custom recovery) they possibly didn't spend a lot of time working out error handling with respect to user error - because it's not something a user would ordinarily change.
Other Stuff:
Moto is cheap: (and so is everyone else). When it comes to a power supply there's more to it than just a battery - there's regulators, surge-protecting capacitors, protecting diodes, current sensors, etc. Each component in the device doesn't care about these things - they just draw a certain current. The cheapness comes in to play in that Motorola or any manufacturer is not going to bother building a power supply that's more than needed. In the case of the nexus 6 it appears that what they have is "just enough"
Battery efficiency degrades as it discharges. This certainly varies from battery to battery, but the faster the battery is discharging - the less ability it has to provide the required charge to power the device
Recall that there was a huge slurry of random reboot issues reported after the Nexus 6 launch. Something that occured apparently entirely at random, that didn't result from any sort of kernel panic - apparently simply the battery couldn't supply current demanded, so some current-limiting protection or a diode went into reverse bias and just cut the power (I can't say exactly because I didn't design the device).
The issue of unexplained random-rebooting seems to be almost entirely resolved in 5.1. The likely reason: the addition to the thermal-config-shamu file that restricts the maximum frequency, at 40% battery, to ~2.2GHz.
In short, it doesn't matter where you change this behavior. Changing the configuration file that directly communicates to the kernel ioctl is just as good as any kernel solution. The problem with a kernel solution is it goes through the same userspace process as thermal-related throttling. There are ways to block it in the kernel, but it is not configurable and not adjustable. It's more of an on/off type of thing.
Every device is different (different manufacturing tolerances). The majority of users probably had no issues with reboots or supply issues when they didn't have any throttling (until ~20%) on 5.0. But for the ones that did the only thing they could be told was to RMA their device.
I personally think google did the throttle at 40% to make up for a crummy power supply, rather than to gain an extra few minutes of battery life.
Also, there is no active hotplugging on 5.1 (Except for at something like 15% battery and while the device is sleeping - but not ACTIVE hotplugging). This could also be part of the reason why they added the 40% throttle, because when the cores are online all the time there's going to be more active draw from the power supply.
Interested in building ZenKernel?
Using GIT Differently
You don't need permission to fork, build, modify zen. Nor do you need permission to bundle it in your rom.
BUT, there has been some confusion in the way I handle my git tree I thought I would help explain here.
I handle all of my kernel-related GIT affairs very differently from anybody else you've seen, probably:
Everything is based off of stock msm/android-msm-shamu-3.10-lollipop-mr1 (Or newer revs as they come available)
When there is a major revision update to the base (android-msm-shamu-3.10-lollipop-mr2 or something), I will avoid rebasing the branch and create a new branch each (so there will be a BFS and a BFS_mr2 or something)
Every change from the stock kernel lives on it's own,independent branch. There's BFS, kcal, fsync, f2fs/ext4_upstream, kexec-hardboot, usb_fastcharge, etc, etc.)
I merge all these independent branches into the master branch, which is how I come up with the "Zen-Kernel" that includes all of them (git merge BFS; git merge kcal; git merge wake_gestures_ex, etc, etc.)
This means forking zen is not traditional, but it's a good thing!
What do I do if I want to pull something from Zen kernel into my tree?:
Add the ZenKernel_Shamu remote to your local tree (git remote add zen https://github.com/bbedward/ZenKernel_Shamu.git)
Fetch the newest zen changes (git fetch zen)
Pull the change you want, for example to pull BFS into your local tree: git pull zen BFS
Whenever you want to pull an update, git fetch zen; git pull zen BFS
These branches are all based on the STOCK msm/android-msm-shamu tree. So if you pull in BFS or kcal you will not get anything new except BFS or kcal. No other unwanted things will be pulled. Some branches depend on each other (ext4_upstream depends on mm_upstream for example), so if you pull in ext4_upstream you will also get the contents of mm_upstream, and so forth.
What do I do if I want to fork the entire zen kernel exactly as it is?
Well you can do it the old way as you always have. But I change some other stuff for internal purposes you may want to change (in the zen branch), such as the ZEN_INFO_SYSFS_INTERFACE is probably irrelevant to you and ZEN_INFO_VERSION_CODE only represents an integer value with the extra version "-zen" statically defined in the Makefile. You may want to change these things or revert them and just append something in the CONFIG_LOCALVERSION such as "-MyKernel_5.1" or something.

---

Oh my goodness gracious..... Zen Kernel. Oh boy, oh boy......

---

And we're back!!!

---

I have an untested bfs port for the msm/3.4 tree as well. It is in process of getting tested on the nexus 5. Anybody interested I will send it to you.

---

This looks tasty, cant wait to see how it performs!

---

Sounds like a plan send it much alohas

---

if @purian23 is contributing, then i have to try out this kernel

---

simms22 said:
if @purian23 is contributing, then i have to try out this kernel
Click to expand...
Click to collapse
Haha thanks dude, all the credit goes to @bbedward! We've been buddy's since our GNex adventures! I'm doing a little bit of testing here and kept bugging him until he caved to build again lol

---

Zen Kernel was my favorite kernel on the GNEX. Ah.. The good old days

---

Ahhh.. BFS.. Reminds me of early kernel flashin days

---

whojabacod said:
Ahhh.. BFS.. Reminds me of early kernel flashin days
Click to expand...
Click to collapse
Give it a try, interactivity feels very good especially doing things like browsing content heavy desktop websites.
In the old days, and present day with 3.10-ck there seemed to be suspend/wake issues that kept everybody away - probably rightfully so. I'm quite happy with the way this version is working though.

---

Running g good so far.

---

bbedward said:
Give it a try, interactivity feels very good especially doing things like browsing content heavy desktop websites.
In the old days, and present day with 3.10-ck there seemed to be suspend/wake issues that kept everybody away - probably rightfully so. I'm quite happy with the way this version is working though.
Click to expand...
Click to collapse
Thanks for bringing this kernel to the Nexus 6, do I need to wipe anything before flashing your kernel? I am on a custom kernel. Thanks

---

Damon13 said:
Thanks for bringing this kernel to the Nexus 6, do I need to wipe anything before flashing your kernel? I am on a custom kernel. Thanks
Click to expand...
Click to collapse
I flashed without wiping anything. But the dev recommends wiping cache.

---

pantmunu said:
I flashed without wiping anything. But the dev recommends wiping cache.
Click to expand...
Click to collapse
Thanks i completely missed that, by the way is the kernel running 4 cores like stock. Thanks in advanced

---

Damon13 said:
Thanks i completely missed that, by the way is the kernel running 4 cores like stock. Thanks in advanced
Click to expand...
Click to collapse
Yes it is.

---

Gland to see you here I flashed your kernel over benzo rom and got system fc keep popping up any ideas tied to get a log but could not

---

jaythenut said:
Gland to see you here I flashed your kernel over benzo rom and got system fc keep popping up any ideas tied to get a log but could not
Click to expand...
Click to collapse
Flashed this on terminus. No problem here. Try dirty flashing benzo ..let it reboot and flash the kernel. Might help.

---

jaythenut said:
Gland to see you here I flashed your kernel over benzo rom and got system fc keep popping up any ideas tied to get a log but could not
Click to expand...
Click to collapse
Stock kernel might not work on cyanogen mod? Maybe it relies on some ramdisk changes I'll have to look into it.