[ZEN-KERNEL] 3.10-zen1 "Dollar Drink Night" (April 19) - Nexus 9 Original Android Development

{
"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"
}
The buck stops here
Project Background
This kernel makes things BETTER. Without tons and tons of over exaggerated fluff
"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 TEGRA/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, nor is there a need for strict NICE values.
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
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/Tegra 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
support for tegra yield notifiers
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
USB Fastcharge Support
Fsync SysFS Interface
Overclocking support to 2.5GHz
FIOPS + BFQ in addition to the stock ROW, CFQ, Deadline, No-op I/O schedulers
Several misc upstream updates/fixes.
zRam support
@osm0sis AnyKernel2
---------
Releases
Wipe /cache before flashing for best results
DIRTY FLASH ROM FIRST!
If you have any issues or if you are coming from another custom kernel.
DIRTY FLASH ROM FIRST IF COMING FROM ANOTHER CUSTOM KERNEL
3.10-zen1 "Dollar Drink Night"
First Release/Features:
BFS CPU Scheduler by Con Kolivas. Backport from v461 and Alfred Chen's -gc branch ported to android/tegra 3.10 by me
BFQ + FIOPS I/O Schedulers in addition to CFQ (default), ROW, Deadline
Interactive governor sync'd up with ZenKernel_Shamu
EXT4 from v3.10.y
Several misc. memory leak, race condition fixes, etc. picked from v3.10.y
CPU overclocking up to 2.5GHz
Wake gestures from @flar2
MM+VM Changes from upstream v3.10.y
2A Charging Support
Fsync toggle support
3.10-zen1 AnyKernel Zip (Use for any ROM)
Legacy Releases
3.10-zen0 "Warranty Voided"
Changes:
This is just experimental
Make sure it works
Changes
3.10-zen0 AnyKernel Zip (Use for any ROM)
Thanks guys, and enjoy. Feedback is always appreciated.
XDA:DevDB Information
Zen Kernel, Kernel for the Nexus 9
Contributors
bbedward
Source Code: https://github.com/bbedward/ZenKernel_Flounder
Kernel Special Features:
Version Information
Status: Beta
Current Stable Version: 1
Beta Release Date: 2015-04-19
Created 2015-04-19
Last Updated 2015-04-19

---

this is untested + experimental.
I fixed a BFS suspend issue in my first test kernel and resolved f2fs issues.
This is here because somebody suggested it to me as the general section is not a good place to be.

---

AnyKernel zip uploaded

---

Love your kernel on the nexus 6. And I'm sure I'll love it on the n9!
Thanks man!

---

omvir said:
Love your kernel on the nexus 6. And I'm sure I'll love it on the n9!
Thanks man!
Click to expand...
Click to collapse
Thanks, if I didn't think -Zen was the best option then it wouldn't exist

---

I wanted to try this but I guess I'll have to wait till the official 5.1 is out. I'm still running stock ROM with a custom kernel so that puts me on 5.0.1.

---

time_shock said:
I wanted to try this but I guess I'll have to wait till the official 5.1 is out. I'm still running stock ROM with a custom kernel so that puts me on 5.0.1.
Click to expand...
Click to collapse
Doesn't matter, this is on stock 5.0 base. I use AnyKernel so it's probably compatible with 5.1 too

---

bbedward said:
Doesn't matter, this is on stock 5.0 base. I use AnyKernel so it's probably compatible with 5.1 too
Click to expand...
Click to collapse
I see why you thought this I just copy pasted my n6 thread
Made some changes.

---

bbedward said:
Doesn't matter, this is on stock 5.0 base. I use AnyKernel so it's probably compatible with 5.1 too
Click to expand...
Click to collapse
I bootlooped on AICP....went back to Fire and Ice.
Sent from my Nexus 9 using Tapatalk

---

So in daily usage, what effect should I notice after flashing this kernel? I read lots of your QA and such but still unsure.

---

Phantom Pt. II said:
So in daily usage, what effect should I notice after flashing this kernel? I read lots of your QA and such but still unsure.
Click to expand...
Click to collapse
I'm not even sure this 0 build works I may have to package an entire ramdisk and quit trying AnyKernel because of all the different 5.1 and 5.0 stuff going on here.
But the point is to add things that matter and things that make a difference. You probably don't care about having 3 alternative random number generators built in the kernel, or about having slightly more optimized memcpy/memmove operations. Not that those things aren't necessarily good, but what's the difference you'll notice with and without those - nothing on the other hand maybe you care about real performance and battery improvements, fast USB charging ,upstream stability, etc, etc.
This is where Zen comes in. Cut out everything except what matters. BFS helps me make a real difference in the performance and battery department.
How does it benefit performance? Well the stock scheduler has lots of overhead with 1 run queue per CPU, huge balancing algorithms, huge fairness calculation algorithms, many tunables. Stuff that's probably pretty essential if you have 64+ logical CPUs where you need to have the separate runqueues to avoid contention issues that come from such a setup. BFS chooses 1 run queue shared by all the CPUs. By design it is able to be fair without big balancing algorithms, interactive without focusing on countless priority calculations, and perhaps most importantly if you run 4 jobs on 4 CPUs it will keep those CPUs busy with a consistent load. On the stock scheduler they may tell you to run -8 or so jobs on a 4 CPU system to keep things busy.
You see a focus on a power-aware CPU scheduler lately as well. What they are doing to achieve that is keep jobs on the left most CPU cores keeping the other ones idle more. On BFS, these power aware things are not applicable because it requires no such load balancer. BFS uses sticky tasks to keep jobs on a CPU which aids in allowing other CPUs to idle more frequently. So when you see 1 CPU get busy 1 CPU will scale in the CPU frequency driver rather than unnecessarily scaling multiple CPUs after balancing.
Anyway, why doesn't google use it if it's so good - because it isn't mainline essentially. It will never go mainline unless they add a pluggable CPU scheduler interface (not in the foreseeable future) because it isn't applicable for a wide variety of systems (specialized for light-NUMA desktop type workloads). Google has had it in an experimental android branch before, but going so far away from mainline takes away a big aspect of support that you get from staying mainline (you get a bug and you can't rely on mainline support)
Why have no other kernels implemented it if it's so good? (They have now, since I brought it here and on the N6) probably because they didn't think it was worth the time to bring back the newest implementation to 3.10 or they didn't have the know how (the official 3.10 -Ck BFS patch is quite old, and broken with suspending - which is why I started the back port/sync process to begin with) so maybe others tried it and gave up.
Anyway the difference between a non-zen nexus 6 and a zen nexus 6 is a noticeable one. It's the only one I believe makes a noticeable performance difference (without over clocking or ramping up frequency scaling). Many claim it makes a noticeable battery difference too, without sacrificing touch boost or killing frequency scaling (in other words, it isn't making lag for better battery life)
Anyway enough rambling. Its coming here to the nexus 9 because I want to continue to support 2014+ nexus devices with my kernels and perhaps one or two other flag ships (I touched the S6 but there's one kernel per variant, their default config is incomplete, typical Samsung mess)
Also there will be a 100% free and open source GPL zen app. Which I think has a brilliant framework and a lot of potential. But that's limited by my time currently.

---

Let me understand this?
OK, bfs seem to be really smooth but what I'm trying to understand is that bfs is like i/o scheduler right?

---

AllanJacques said:
Let me understand this?
OK, bfs seem to be really smooth but what I'm trying to understand is that bfs is like i/o scheduler right?
Click to expand...
Click to collapse
No.
1.) I/O scheduler handles how requests to the disks (EMMC/Sdcard in this case) are served (order served first, etc.)
2.) The requests to get disk time are all coming from the CPU. (From the tasks getting CPU time)
3.) The CPU scheduler handles when, for how long, and how to serve the tasks that want CPU time. All factors considered such as keeping things fair between all the CPU cores, tasks that will do blocking due to an I/O wait or synchronization locking.
--BFS (Brain F*** Scheduler) is the CPU scheduler in (3). It is the only well-known replacement to the stock kernel's CFS (completely fair scheduler). I'm sure there have been others since CFS, but I haven't really heard about any. Some one and dones mostly.
What you are thinking of are the I/O schedulers which are completely separate, and only related to how requests to the EMMC/Disk are served. You and many are confusing BFS (Brain F*** Scheduler, CPU/Process scheduler) and BFQ (Budget Fair Queueing, I/O, disk scheduler)
See (both BFS and CFS are preemptive schedulers):
http://en.wikipedia.org/wiki/Scheduling_(computing)#Short-term_scheduling
http://ck.wikia.com/wiki/BFS

---

Got it!
One last question, BFS rr_interval can be tweaked? What does it do?

---

AllanJacques said:
Got it!
One last question, BFS rr_interval can be tweaked? What does it do?
Click to expand...
Click to collapse
You have millions and millions of tasks/processes going through the CPU in seconds.
Each task is waiting in line to be scheduled.
When BFS schedules said task, it is allowed to run for a maximum of RR_INTERVAL.
So by default at 6 (ms), a task cannot run for more than 6ms at a time. If it will take longer than that it will be "preempted" by another task, and will have to go back in the queue and wait until it is scheduled again (given a deadline).
If you raise it to 300, for example, a task will be allowed to be running for up to 300ms at a time. (Maybe a task has to wait for for disk time, which may take 100ms or something, etc.)
It is said that the lower value would mean lower latencies seen by the user, and a higher value would see higher thoroughput. 6 is default because it is determined the human eye can't detect jitters below 7ms. You can try lowering it/raising it. See what works best.

---

I used to always get battery drain on brain f kernels back in the day when it first came out. I look forward to any improvements since then.

---

dictionary said:
I used to always get battery drain on brain f kernels back in the day when it first came out. I look forward to any improvements since then.
Click to expand...
Click to collapse
The old implementations never sync'd up very well with mainline suspend/wake stuff. Since ~3.12 or so they have - and the one on this kernel (and the N6 kernel) do as well :good:

---

bbedward said:
The old implementations never sync'd up very well with mainline suspend/wake stuff. Since ~3.12 or so they have - and the one on this kernel (and the N6 kernel) do as well :good:
Click to expand...
Click to collapse
That makes me happy. Will report findings. Thanks again

---

Working well on CM 12.1 unofficial!
I know this isn't the kernels fault, its googles fault but the interactive governor tunables suck! Do you have any suggestions ? Can you work your magic? Currently its kind of stuttery!

---

omvir said:
Working well on CM 12.1 unofficial!
I know this isn't the kernels fault, its googles fault but the interactive governor tunables suck! Do you have any suggestions ? Can you work your magic? Currently its kind of stuttery!
Click to expand...
Click to collapse
I will sync it up with the same interactive of zen on the N6. Looks like the tegra version of interactive is a bit older.