[ZTE Axon 7 ROMs, Kernels, Recoveries, & Other Deve] SaintZ93:
The Schwifty Kernel (Yeahhh, Get Schwifty)

Hello guys welcome to the Schwifty Kernel! If you watch the show "Rick and Morty" you will understand why I named it this ;) if you don't understand well either youtube it or just don't worry and enjoy the sh*t out the kernel anyways hehe. Alright lets get Schwifty, here's all the info about the kernel in a way that will help you decide how you want to set up your phone! The second post will contain changelogs and third post, well not sure yet. But enjoy!!​

Basic Specifications/Information

:

Based On Axon 7 LoS 16.1 Kernel Source

Updated to the latest linux kernel source (3.18.126)

Built with Custom CrossTool-NG Toolchain (GCC: 8.2.0)

Allow 5-10 to settle in after booting up for better usage

Take the time to read all the information to get an understanding on the kernel (Will help with less bug reports)

If you report a bug please search before posting and give all information about your issue (Such as rom, kernel version, kernel setup... ect)

I will edit the page with dates when there is something new added such as govenors, schedulers ect...

I/O Scheduler Information - I/O

:

NOOP - Inserts all the incoming I/O requests to a First In First Out queue and implements request merging. Best used with storage devices that does not depend on mechanical movement to access data (yes, like our flash drives). Advantage here is that flash drives does not require reordering of multiple I/O requests unlike in normal hard drives.

DEADLINE - The goal of the Deadline scheduler is to attempt to guarantee a start service time for a request. It does that by imposing a deadline on all I/O operations to prevent starvation of requests. It also maintains two deadline queues, in addition to the sorted queues (both read and write). Deadline queues are basically sorted by their deadline (the expiration time), while the sorted queues are sorted by the sector number. Before serving the next request, the Deadline scheduler decides which queue to use. Read queues are given a higher priority, because processes usually block on read operations. Next, the Deadline scheduler checks if the first request in the deadline queue has expired. Otherwise, the scheduler serves a batch of requests from the sorted queue. In both cases, the scheduler also serves a batch of requests following the chosen request in the sorted queue.

BFQ - Instead of time slices allocation by CFQ, BFQ assigns budgets. Disk is granted to an active process until it's budget (number of sectors) expires. BFQ assigns high budgets to non-read tasks. Budget assigned to a process varies over time as a function of it's behavior.

ZEN & ZEN v2 - Based on the Noop, Deadline and SIO I/O schedulers. It's an FCFS (First come, first serve) based algorithm, but it's not strictly FIFO. ZEN does not do any sorting. It uses deadlines for fairness, and treats synchronous requests with priority over asynchronous ones.

MAPLE(8/30) - is based on the Zen and Simple I/O schedulers. It uses ZEN's first-come-first-serve style algorithm with separate read/write requests and improved former/latter request handling from SIO. Maple is biased towards handling asynchronous requests before synchronous, and read requests before write. While this can have negative aspects on write intensive tasks like file copying, it slightly improves UI responsiveness. When the device is asleep, maple increases the expiry time of requests so that it can handle them more slowly, causing less overhead.

Governor Information - CPU

:

Interactive - Interactive scales the clockspeed over the course of a timer set by the kernel developer (or user). In other words, if an application demands a ramp to maximum clockspeed (by placing 100% load on the CPU), a user can execute another task before the governor starts reducing CPU frequency. Because of this timer, Interactive is also better prepared to utilize intermediate clockspeeds that fall between the minimum and maximum CPU frequencies. It is significantly more responsive than OnDemand, because it's faster at scaling to maximum frequency. Interactive also makes the assumption that a user turning the screen on will shortly be followed by the user interacting with some application on their device. Because of this, screen on triggers a ramp to maximum clockspeed, followed by the timer behavior described above. Interactive is the default governor of choice for today's smartphone and tablet manufacturers.

Ondemand - Ondemand is one of the original and oldest governors available on the linux kernel. When the load placed on your CPU reaches the set threshold, the governor will quickly ramp up to the maximum CPU frequency. It has excellent fluidity because of this high-frequency bias, but it can also have a relatively negative effect on battery life versus other governors. OnDemand was commonly chosen by smartphone manufacturers in the past because it is well-tested and reliable, but it is outdated now and is being replaced by Google's Interactive governor.

Performance - Sets the frequency at the maximum available frequency. This governor always returns UINT_MAX as frequency so that the DEVFREQ framework returns the highest frequency available at any time.

Powersave - Sets the frequency at the minimum available frequency. This governor always returns 0 as frequency so that the DEVFREQ framework returns the lowest frequency available at any time.

Userspace - Sets the frequency at the user specified one. This governor returns the user configured frequency if there has been an input to /sys/devices/.../power/devfreq_set_freq. Otherwise, the governor does not change the frequnecy given at the initialization.

GPU Governors

:

Adreno Idler - It is an idling algorithm, an efficient workaround for msm-adreno-tz's overheads. Main goal is to lower the power consumptions while maintaining high-performance. Since msm-adreno-tz tends to *not* use the lowest frequency even on idle, Adreno idler replaces msm-adreno-tz's algorithm when it comes to calculating idle frequency(mostly by ondemand's method). The higher frequencies are not touched with this algorithm, so high-demanding games will (most likely) not suffer from worsened performance.

Simple - An open-source alternative to Qualcomm's closed-sourced governors. Developed by Faux123, it is highly customisable which will allow more fine-grained control over how the GPU scales up and down.

simple_ondemand[/b] - As the name implies, it is a simpler version of the CPU governor ondemand. simple_ondemand will ramp up the frequency when a load is detected. It has a good balance between performance and battery savings.

msm-adreno-tz - The default GPU governor used by Qualcomm for their adreno GPUs. It is based on the ondemand governor but is biased towards performance, therefore it should give better performance in games but less battery life.

Performance - As the name suggests, this keeps your GPU running at the max frequency. This is a governor if you want the best possible experience in games but you don't care about your battery life.

Powersave - Like the CPU governor, this keeps your GPU running at the lowest possible frequency. Best battery life, extreme lag in games.

Userspace - This governor basically allows the user is able to set a desired frequency for the GPU to run at.

cpubw_hwmon - A hardware monitor based governor that attempts to determine bandwidth (BW) needed by CPU and other hardware. Because it samples bandwidth using polling intervals, it has been made to be biased towards performance to compensate for the possible slower response times during heavy loads.

MSM Cpufreq - The MSM CPUfreq governor determines the CPU to DDR bandwidth vote based on the current CPU frequency of all the active CPUs. In other words, this governor scales based on CPU usage which could mean more performance.

Other Information

:

Moved Core Control To Kernel - Moved core control from out-of-tree module into the kernel proper. Core control monitors load on CPUs and controls how many CPUs are available for the system to use at any point in time. This can help save power. Core control can be configured through sysfs interface.

Moved Core Control Trace Events To Scheduler

Added A Knob To Disable The core_ctl (Core Control) - The CPU hotplug tests does not work with core_ctl compiled statically into kernel. Provide an interface to disable the hotplug by core_ctl.

Updated the performance is cpufreq

Lots of UPSTREAM changes to cpuidle and schedulers

Some under and overclocks with how the phone idles and returns

Added a State Notifyier

Added CAD Project

Imported Boeffla Wakelock Blocker v1.1.0

Updated Kcal Support

Fixed Various Issues

Low Persistence Fixed For DayDream

Selinux Switcher Between Permissive & Enforcing (Please install the Magisk SELinux Manager)

And a whole lot of other sh*t, view the github to see all the changes

Credit

:

[MENTION=5027381]OrdenKrieger[/MENTION]

[MENTION=4911249]Unjustified Dev[/MENTION]

[MENTION=6977124]Skrem339[/MENTION]

Tester

:

[MENTION=4490213]kingracer[/MENTION]

[MENTION=5168296]KevinX8[/MENTION]

[MENTION=5586933]Masterjuggler[/MENTION]

[MENTION=7799420]Choose an username...[/MENTION]

[MENTION=633903]docentore[/MENTION]

[MENTION=4493018]Infy_AsiX[/MENTION]

Disclaimer: I do not and will not take any responsibility towards anything that happens to your phone after flashing.

If you would like to donate a beer or a blunt feel free, its not obligated though! Each donation is appreciate by being added to OP!

​

XDA:DevDB Information

[KERNEL][OREO][AOSP] Schwifty Kernel | Custom | 6/8/17 |, Kernel for the ZTE Axon 7

Contributors

SaintZ93

Source Code: https://github.com/SaintZ13/schwifty_oreo_axon7

Kernel Special Features:

Version Information

Status: Stable

Current Stable Version: v1

Stable Release Date: 2018-06-24

Created 2018-06-25

Last Updated 2018-06-24