[LG V20 ROMs, Kernels, Recoveries, & Other Developm] 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 LS997ZV7 OpenSource (Thanks LG)

NO Static Screen

Install Includes Root

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

:

FIOPS - This new I/O scheduler is designed around the following assumptions about Flash-based storage devices: no I/O seek time, read and write I/O cost is usually different from rotating media, time to make a request depends upon the request size, and high through-put and higher IOPS with low-latency. FIOPS (Fair IOPS) ioscheduler tries to fix the gaps in CFQ. It's IOPS based, so it only targets for drive without I/O seek. It's quite similar like CFQ, but the dispatch decision is made according to IOPS instead of slice.

SIO - Simple I/O aims to keep minimum overhead to achieve low latency to serve I/O requests. No priority queue concepts, but only basic merging. SIO is a mix between noop & deadline. No reordering or sorting of requests.

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.

BFQIO - Enable hierarchical scheduling in BFQ, using the cgroups filesystem interface. The name of the subsystem will be bfqio.

ZEN - ZEN is 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. Other than that, it's pretty much the same as Noop blended with VR features.

MAPLE - Maple 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.

Blu_active - A new cpu governor developed by eng.stk (featured in his Code_Blue kernels) based on interactive with upstream caf patches and ondemand governor bits too. This governor is mainly focused on performance like the other things the developer creates but it is also well balanced for gaming and general usage.

ElementalX - ElementalX is basically a multiphase Ondemand governor that aims to achieve the best balance between battery life and performance. By default, it is more conservative than Ondemand as it does not ramp up often for most phone activities. If there is a graphics load detected, the governor will switch to a two-phase Ondemand behaviour where different max frequencies are used depending on the load increase. ElementalX comes with input boost enabled by default lowering the sampling rate and increasing the frequency to improve responsiveness.

Nightmare - A PegasusQ modified, less aggressive and more stable. A good compromise between performance and battery. In addition to the SoD is a prevention because it usually does not hotplug.

Darkness - It's based on nightmare but more simple and fast, basic configs but very complex structure. It is an updated version of the nightmare gov, so far it is quite stable in tests.

Chill (NEW 5/15) - Use the CPUFreq governor 'chill' as default. This allows you to get a full dynamic frequency capable system by simply loading your cpufreq low-level hardware driver. A conservative based governor that aims to provide more aggressive battery savings while screen is off.

Dance Dance - Based on conservative with some smartass features, it scales accordingly to conservatives laws. So it will start from the bottom, take a load sample, if it's above the upthreshold, ramp up only one speed at a time, and ramp down one at a time. It will automatically cap the off screen speeds to 245Mhz, and if your min freq is higher than 245mhz, it will reset the min to 120mhz while screen is off and restore it upon screen awakening, and still scale accordingly to conservatives laws. So it spends most of its time at lower frequencies. The goal of this is to get the best battery life with decent performance. It is a performance focused governor but also blends with some battery savings.

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.

Enabled LZ4 Compression & Added ExFAT Filesystem

Fixed Various Issues

And a whole lot of other sh*t

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

XDA:DevDB Information

Swifty Kernel | Custom Stock | 6/24/18 |, Kernel for the LG V20

Contributors

SaintZ93

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

Kernel Special Features:

Version Information

Status: Stable

Current Stable Version: Release V3

Stable Release Date: 2017-06-08

Created 2017-06-08

Last Updated 2017-06-08