[Xiaomi Redmi 3s Guides, News, & Discussion] Avinash.007:
This thread is all about kernel things. I will be trying to provide a brief explanation regarding most of the features & options available in custom kernels. There are two custom kernel which are maintained for our device.

Disclaimer: I in no way claiming that information available in this thread is 100% correct.​

Brief History about these custom kernels.

1. Chimera Kernel by rupanshji

This is a custom kernel based on Nichcream & Team Reloaded’s kernel source code with features added by the developer. This kernel has spectrum support. Talking about updates, Chimera is not updated frequently.

Source Code | Thread

Download link: Google Drive | Older Builds

2. Jasper Kernel by Pawan.S 5277!

This is a custom kernel based on msm-3.18 kernel source code with features and patches added by the developer. Jasper is updated whenever a new CAF tag is available (as mentioned in OP & what I have noticed).

Source Code | Thread

Download link: AndroidFileHost | MediaFire

3. Spicy Kernel by DyWN

Temporarily discontinued.

Kernel Managers

EX Kernel Manager

Kernel Auditor

Features and Options available in at-least one of the custom kernels mentioned above are mentioned below along with a brief description about them.

GOVERNORS

1. Alucard: This govenor is based on ondemand but has been heavily tweaked to bring better battery life and performance. It has been known to be battery friendly without sacrificing much performance.

2. Blu_active: A 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.

3. Clarity: Basically this from interactive CAF with additional tunables and tweaks. such as: Remove boost functional - Limit max frequency when screen off. Using relation CPU frequency Current (C) (Low power as possible). - additional down load tunable.

4. Conservative: This governor biases the phone to prefer the lowest possible clock-speed as often as possible. In other words, a larger and more persistent load must be placed on the CPU before the conservative governor will be prompted to raise the CPU clockspeed. Depending on how the developer has implemented this governor, and the minimum clockspeed chosen by the user, the conservative governor can introduce choppy performance. On the other hand, it can be good for battery life.

The Conservative Governor is also frequently described as a "slow OnDemand". The original and unmodified conservative is slow and inefficient. Newer and modified versions of conservative (from some kernels) are much more responsive and are better all around for almost any use.

5. Darkness: It's based on nightmare but more simple and fast, basic configs but very complex structure. It is an updated nightmare gov and improved stability, so far it is quite stable in tests.

6. Electron: This is a governor based on interactive from the latest MSM8994 CAF branch with more upstream improvements, powersave bias, screen off max frequency, and some other tweaks to improve battery life without hindering performance.

7. Interactive: This governor 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.

8. Lisi: This governor is less aggressive and works similar to Alessa. This driver adds a dynamic cpufreq policy governor & designed for latency-sensitive workloads. The governor does a periodic polling and changes frequency based on the CPU utilization.

9. 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.

10. Ondemand: This 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.

11. Performance: The performance governor locks the phone's CPU at maximum frequency.

12. Powersave: The opposite of the Performance governor, the Powersave governor locks the CPU frequency at the lowest frequency set by the user.

13. Schedutil: This is a new EAS governor found in recent versions of the Linux Kernel (4.7+) that aims to integrate better with the Linux Kernel scheduler. It uses the kernel's scheduler to receive CPU utilisation information and make decisions from this input. As a direct result, schedutil can respond to CPU load faster and more accurate than normal governors such as Interactive that rely on timers.

14. Userspace: This governor, exceptionally rare for the world of mobile devices, allows any program executed by the user to set the CPU's operating frequency. This governor is more common amongst servers or desktop PCs where an application (like a power profile app) needs privileges to set the CPU clockspeed.

CPU Scheduler options... Search yourself.

THERMAL

1. Msm thermal is a kernel platform driver which regulates thermal conditions on the device during kernel boot. The goal of MSM_THERMAL is to prevent the temperature of the system from exceeding a thermal limit at which it cannot operate. Examples are CPU junction thermal limit, or POP memory thermal limit. The MSM_THERMAL driver polls the TSENS sensor hardware during boot, and reduces the maximum CPU frequency allowed in steps, to limit power/thermal output when a threshold temperature is crossed. It restores the maximum CPU frequency allowed in the same stepwise fashion when the threshold temperature (with hysteresis gap) is cleared.

2. Core Control Enable / disable throttling, this enables the thermal engine and enable VDD restriction and core throttle.

3. VDD Restriction Limits CPU voltage, limiting it will decrease temperature.

HOTPLUG OPTIONS

1. AiO_hotplug: An all in one HotPlug for Traditional Quad-Core and Hexa/Octa-Core big.LITTLE SoCs.

2. Autosmp: A highly-efficient hotplug driver, works in-sync with the CPU governor to enable off-line cpu cores when the the CPU frequency reaches a high threshold and still more compute power is needed. Therefore, touch boost bloat is removed.

GPU OPTIONS

Min GPU Freq: 216Mhz Max GPU Freq: 500 Mhz

GPU Governor:

1. 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.

2. 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.

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

4. Simple_ondemand: 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.

Note: There are many other broken GPU Governors. Do not select them. If you are using Chimera, then your device will reboot if you try to select them.

GPU Boost: If you are using msm-adreno-tz governor, then you can configure GPU boost option also. Use ExKM to configure this additional option.

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.

COLOR CONTROL

Self-explanatory

SCREEN OPTIONS

Backlight Dimmer: Enable only at night times.

GESTURE OPTIONS

1. DoubleTap2Wake

2. Sweep2Wake

3. Sweep2Sleep

All of them are self-explanatory

Pro tip: Use KA if using chimera or ExKM if using Jasper to configure gesture options.

GESTURE VIBRATION

You can the intensity of vibration for the gestures.

VOLTAGE

You can decrease or increase the voltage globally or per core by adjusting the values.

Pro tip: Just don’t play with this unless you’re pro. AFAIK, both custom kernels have under-voltage values according to CPU cluster so doing further can for sure cause in-stability issues.

SOUND

You can decrease or increase the headphone digital gain, mic gain or speaker gain by configuring settings under sound tab.

MEMORY

Low Memory Killer: is a process killer, which is designed to work in cooperation with the Android Framework. Each process is assigned a special value by the Framework when started, the oom_adj value(oom_score_adj on newer kernels). This value defines how important the process is for the system(its priority), and thus how easily it can be killed. Values vary between -17 and +15(0 to 1000 for oom_score_adj). Higher values are given to less important processes which are killed first. Moreover, LMK defines 5 different categories for processes, each one containing processes with oom_adj/oom_score_adj in a specific range of values:

1. Foreground Applications: The application currently shown on the screen and running.

2. Visible Applications Applications that might not be shown on the screen currently, but are still running. They might be hidden behind an overlay or have a transparent window.

3. Secondary Server Services running in the background and needed for Apps to function properly. This category includes Google Play Services for example.

4. Hidden Applications Applications that are hidden from the user, but are running in the background.

5. Content Providers These are the services providing content to the system like contacts provider, location provider etc.

6. Empty Applications This category contains Applications that the user exited, but Android still keeps in RAM. They do not steal any CPU time or cause any power drain.

ZRAM OPTIONS

zRAM is just compressed RAM space. So you can store more in RAM by compressing the data you can fit more data inside your RAM.

Now obviously it is slower than actual normal RAM (since you have to encrypt and decrypt the data), but apparently it still is faster than using swap (which is in your internal memory rather than RAM). The principle works based on that Android prefers to keep data stored as much as possible in RAM to keep recently used apps running quickly. The more you use an app the more priority it has, therefore will stay in normal RAM, things you use sometimes but not very often are kept in zRAM (regardless of how full your actual RAM is), but since you don't use this very often you don't notice the performance hiccup of decrypting that data.

Then last case scenario things you barely use are kept in swap.

For you IT enthusiasts you should have realised already that "z" is the technology prefix for Compression. So it shouldn't come as a surprise that zRAM is compressed RAM.

zRAM Size: 1 GiB is a fairly balanced amount. According to Google, it is useful even on devices with 4 GB of ram because it helps reduce page cache

thrashing, or constant unloading and reloading of cached pages from disk.

zRAM Compression: lzo or lz4

VIRTUAL MEMORY OPTIONS

Dirty Ratio & Dirty Background Ratio: Most people say that these need to be high, so that more stuff is stored in Cache. This will make your phone quick. Because cache is quick. But in reality this is only good advice if all you need to load on your phone is the system UI. Because as soon as you start loading different apps this cache fills quickly, and whenever you want to open an app/file/webpage that is not in cache, your CPU is tasked with both emptying whatever is filling up cache memory and load your new app into cache. Thus making multitasking a nightmare within the first day. A simple reboot of the phone is not enough, nor is clearing RAM (Note: Cache is not RAM).

Overcommit Ratio: While increasing allows more multitasking, I recommend leaving this at 0. It keeps RAM from completely filling up, thus avoiding "app xxx not responding" issues.

I/O OPTIONS

I/O Scheduler:

1. 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.

2. CFQ: This scheduler maintains a scalable per-process I/O queue and attempts to distribute the available I/O bandwidth equally among all I/O requests. Each per-process queue contains synchronous requests from processes. Time slice allocated for each queue depends on the priority of the 'parent' process. V2 of CFQ has some fixes which solves process' i/o starvation and some small backward seeks in the hope of improving responsiveness.

3. 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.

4. 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) I/O scheduler 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.

5. 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.

6. 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.

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

8. Zen: It 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.

More info can be found here.

MISCELLANEOUS

TCP Congestion algorithm: Available choices are bic, cubic, lp, reno & westwood.

More info can be found here.

My recommendation: Try both custom kernel for atleast two days and then decide which suits your need. And use ExKM to configure Jasper as some of the options available in that kernel are not available in KA.

References: Source 1 | Source 2 | Source 3