Congratulations! I certainly hope this doesn't mean we'll be seeing TOO much less of you as you are a huge asset to both the XDA community and more specifically to the developer community here, but if it does that would be more than understandable, obviously . Also, as a local, I understand that this position is quite the opportunity- you definitely had some competition. I feel the need to say an extra word of congratulations for that, as I am sure those unfamiliar with said headquarters would likely not understand just how big of a break this really is for a developer. Anyway, I appreciate all you've contributed to this device and I'm very glad to see you achieve the recognition (and pay!) you deserve for your skills. :good:
Thanks. Yea I had a few offers and through some weeks I'd have 3-4 interviews a day so it was a pretty busy process. I'll still be here though, SW is definitely one of the best opportunities in Cleveland I think.
Anyone running this with Android M preview two? I want to switch from Chroma and Zen to JDX and Zen, just wondering if this kernel is working for the second preview.
Sorry to but into your thread, but is there a port of this kernel to the OnePlus One? Or would you happen to know of a OnePlus kernel that supports BFS and F2FS? Private messages welcome (don't wanna take up too much space in your thread). Any information appreciates. Thanks!
Sorry to but into your thread, but is there a port of this kernel to the OnePlus One? Or would you happen to know of a OnePlus kernel that supports BFS and F2FS? Private messages welcome (don't wanna take up too much space in your thread). Any information appreciates. Thanks!
Sorry but there is not. Oneplus One uses 3.4.x release of the linux kernel, while the nexus 6 uses 3.10.x. The difference you notice is probably nothing, but the port/work for it here is not directly compatible with the 3.4 kernel (I'd have to do it separately for that one).
F2FS I suspect would be no large obstacle though.
I am on the waiting list for the Oneplus two (like #3 million in line), and I'll 100% buy the new nexus later this year. So if I can ever get an invite for OP2 there will assuredly be a zen kernel there The OP1 however not at this point.
Sorry but there is not. Oneplus One uses 3.4.x release of the linux kernel, while the nexus 6 uses 3.10.x. The difference you notice is probably nothing, but the port/work for it here is not directly compatible with the 3.4 kernel (I'd have to do it separately for that one).
F2FS I suspect would be no large obstacle though.
I am on the waiting list for the Oneplus two (like #3 million in line), and I'll 100% buy the new nexus later this year. So if I can ever get an invite for OP2 there will assuredly be a zen kernel there The OP1 however not at this point.
Good to hear that Zen will be making it's way towards the new Nexus If rumor is true and two new Nexus are released, disregarding price, would you opt towards the smaller one or the bigger one?
Good to hear that Zen will be making it's way towards the new Nexus If rumor is true and two new Nexus are released, disregarding price, would you opt towards the smaller one or the bigger one?
Sorry but there is not. Oneplus One uses 3.4.x release of the linux kernel, while the nexus 6 uses 3.10.x. The difference you notice is probably nothing, but the port/work for it here is not directly compatible with the 3.4 kernel (I'd have to do it separately for that one).
F2FS I suspect would be no large obstacle though.
I am on the waiting list for the Oneplus two (like #3 million in line), and I'll 100% buy the new nexus later this year. So if I can ever get an invite for OP2 there will assuredly be a zen kernel there The OP1 however not at this point.
I've never been one to chase wake locks or tune services. I leave everything on all the time, its easy enough to charge... Outlets are everywhere.
On stock or elite I got typically 3.5hr screen on, never over 4. Doing nothing other then flashing this kernel has taken me to over 5 hr screen on in the same usage conditions. Its been more stable as well with out giving anything up.
I've never been one to chase wake locks or tune services. I leave everything on all the time, its easy enough to charge... Outlets are everywhere.
On stock or elite I got typically 3.5hr screen on, never over 4. Doing nothing other then flashing this kernel has taken me to over 5 hr screen on in the same usage conditions. Its been more stable as well with out giving anything up.
I am unsure what all the files are, but custom kernels often add files to at least the system partition, such as init.d settings... Generally the recommendation is to not flash one customer kernel over another.
If your on stock, or at least what is stock for your rom, you should be fine to just flash the kernel, no wipes or special moves needed.
If you have been using a different custom kernel, it seems to be the general recommendation (not just for this kernel) to dirty flash your rom to get back to "stock" wrt your kernel, and then flash.
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.
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).
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.
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:
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)
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.
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
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
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
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.
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).
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.
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:
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)
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.
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
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
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
I just wanted to toss this out there an say i'm proud of @bbedward! Today, he Graduates from the University of Toledo with his Software Engineering Degree (Computer Science & Engineering) with a Bright Future! He already has options at Oracle and GE as soon as he steps foot back in his hometown of Cleveland!
I honestly feel like his big brother with all the BS'n we've done over the past few years. He's taught me a lot (even though the punk is younger lol) and I'm pretty sure I've given him so good life morals to go by haha. Join me in Congratulating @bbedward for not only his awesome kernels and tons of XDA Community involvement/help through the years, but for generally being a cool dude. We'll surely look forward to what he has in store next for the tech community.