How to Boost Performance on Android by Tweaking the KTS Part B

How to Boost Performance on Android by Tweaking KTS Part A

How to Boost Performance on Android by Tweaking the KTS Part B

As for as Android setting is to be concerned , androidjunctions is always ahead to help the android smartphone users. How to Boost Performance on Android by Tweaking the KTS Part B is before you to assist. KTS stands for kindler task scheduler. we are here with the topic How to Boost Performance on Android by Tweaking the KTS Part B. Samsung , Sony and many other brand smartphone companies keep updating through latest launch.

You most welcomed back to another kernel Task Scheduler tweaking guide for Android. In the last tutorial we had already covered some basic Task Scheduler configuration options, which can be manually tuned to increase the  performance on an Android device. In case you couldn’t go with the above mentioned article, read that. Androidjunctions strongly recommend you doing so before proceeding, as it includes some useful piece of information for better understanding “how  to boost the Task Scheduler actually works.

Except the basic parameters we had discussed in the last tutorial, there is Linux Task Scheduler implements. Those special features one must try to improve its fair distribution of processing power. These SPECIAL features do not produce the same results on all systems and used-cases.

Therefore they can be enabled or disabled at the runtime. They are available through the kernel debugfs. Not all the kernels pack support for tweaking scheduler debugfs features though. You can learn if your kernel supports changing these features by entering the following commands inside a Terminal App (as superuser):

cat /sys/kernel/debug/sched_features

If you get an output as given below, your kernel supports changing debug features at the runtime:

How to Boost Performance on Android by Tweaking the KTS Part B
How to Boost Performance on Android by Tweaking the KTS Part B

If you get a “No such file or directory” error output, you can try to mount the kernel debugfs, in case it is available but not mounted at boot:

mount -t debugfs none /sys/kernel/debug

If this command does not produce an error, you can try passing the first command again.

How to Boost Performance on Android by Tweaking the KTS Part B.

How to Boost Performance on Android by Tweaking the KTS Part B

Don't Miss - Download wallpapers fo android

Toggling A Scheduler Debug Feature

To enable a scheduler debug feature, you just need to write its name inside the sched_features file. For example:

echo GENTLE_FAIR_SLEEPERS > /sys/kernel/debug/sched_features

To disable a feature, you must also write its name inside the same file, but with a “NO_” in front. For example:

echo GENTLE_FAIR_SLEEPERS > /sys/kernel/debug/sched_features 


Mostly Seen Common Scheduler Debug Features

Through the mentioned article we confess that it’s not guaranteed that a specific kernel will support all scheduler features discussed below. Different supports for features are there. Features varies between kernel versions and  device implementations. All the features supported are those which  contained in the output of the command ;                                                                             ‘cat /sys/kernel/debug/sched_features’.

Features that start with a “NO_” are those supported but currently disabled.


The present feature attempts to reduce run time of sleepers (processes that tend to sleep for a long time). As a result, more runtime is distributed to active tasks. Some users report that disabling this feature might improve responsiveness on low-end devices.


This feature enables you to put a task that wakes up on the same CPU as the task that woke it. This signify that the new task will work on the same data and memory as the previous one. Scheduling it on the same CPU will improve cache locality(read below for more information about cache locality).


We require some deeper Task Scheduling knowledge to understand this mentioned feature.

On Linux, there are different task scheduling priorities. A task’s scheduling priority defines how important that task is and how much resources will get from the scheduler. Most tasks run using SCHED_OTHER (SCHED_NORMAL on newer kernels) priority. Other priorities are SCHED_BATCH, SCHED_RR, SCHED_FIFO and SCHED_DEADLINE.

Lastly three of these priorities are real-time priorities, designed for tasks that need to run as fast as possible and as soon as they are created.

The Task Scheduler assigns each CPU two special parameters: rt_runtime and rt_period. Rt_period is the scheduling period that is equivalent to 100% CPU bandwidth. Rt_runtime is the time in which each CPU runs only real-time tasks.

All other tasks run for [rt_period – rt_runtime] time. Typically, the kernel Task Scheduler gives 95% of a CPU’s time to real-time tasks and 5% to all others.

RT_RUNTIME_SHARE allows a CPU to run a real-time task up to 100% of time, by borrowing rt_runtime from other CPUs. CPUs that lend rt_runtime can then run non-realtime tasks for more time. Some custom kernel developers disable this feature by default, as it can render a CPU unable to service non-realtime tasks strictly scheduled on it and decrease performance.


Mostly on Linux, when a task wakes up, it preempts (=takes the place of) the task that was running before on the CPU (wakeup preemption). NEXT_BUDDY handles the case when the task that wakes up does not cause preemption. Whenever NEXT_BUDDY is enabled, the task that just woke up will run on the next scheduling event. This feature also improves cache locality.


When wakeup preemption succeeds, prefer to schedule next the task that ran just before preemption. LAST_BUDDY improves cache locality.


This handles wakeup preemption discussed above. Most kernels enable this behavior by default. Disabling it might help on heavy loaded systems.

Cache Memory and Cache Locality

The key point in modern CPU designs is minimizing latencies between fetching data from memory devices and processing them. RAM memory, even in its latest generations, is quite slow to operate. It usually requires hundreds of CPU cycles to get some data from an area inside RAM storage.

To overcome this situation, modern CPUs come packed with some special type of memory, known as cache memory. There are usually several cache memory devices connected in series, named L1, L2, L3 etc. Letter “L” stands for level, ie L1 cache is the one closest to the processor. The higher the level of cache, the slower it is to operate. On the other hand, higher level caches are less expensive to manufacture. However, all cache memories are a lot more expensive than typical RAM memory. That is why most CPUs only pack small amounts of cache memory (some MBs).

Typically, when a CPU needs to get some data from memory, it will first look in cache memories in increasing order. Every time it jumps to a higher level cache memory during the fetching process, latency increases. If data is not found inside the cache memory, CPU relies on RAM storage, which largely increases processing work.

It is up to the Operating System and Application developers to make correct use of cache memory. The Operating System should run all tasks within the same Application on CPUs that share the same cache memory, so Application data can be manipulated fast. Developers must design programs that save their data in near locations in memory. This strategy of collecting related data on the same cache areas is known as “cache locality”.

Android and Cache Locality

Through the topic How to Boost Performance on Android by Tweaking the KTS Part B, we help Android devices that ship with a number of the same type of processors in one cluster (eg. a Qualcomm msm8226 device), usually have a shared L2 cache. Each processor has its own L1 cache. These devices are easier to manage by the kernel Task Scheduler. In contrast, devices that implement the big.Little architecture (Asymmetric Multi-Processing, AMP) are more complex. They pack two clusters of processors, each one featuring its own L2 cache. The Linux Task Scheduler includes support for these types of devices, but custom manufacturer implementations need code reworks for them to operate efficiently.


All the features discussed above are quite complex to understand. It’s obvious that they have different performance impact on different devices. For example, low-end devices might show better performance with GENTLE_FAIR_SLEEPERS and RT_RUNTIME_SHARE disabled. Enabling WAKEUP_PREEMPTION might also increase throughput on these devices.

Consequently the performance is an unavoidable point for any android flagship.

Things are different on big or little platforms, which feature more than one CPU clusters. Scheduling a child process or thread from a big core on a little core, or vice-versa introduces cache-memory copying latency.

You can minimize the effect by enabling features that improve cache locality,        AFFINE_WAKEUPS and LAST_BUDDY.

Of course we have tried to deliver the article in a proper and easy mode. Androidjunctions is always there for the android users to cope up with such problems. The site helps all the smartphone users do or adopt tips or tutorials boost up their flagships.

Review- The Latest Samsung Galaxy S9

Leave a Reply