Need help with cacule-cpu-scheduler?
Click the “chat” button below for chat support from the developer who created it, or find similar developers for support.

About the developer

259 Stars 22 Forks 266 Commits 2 Opened issues


The CacULE CPU scheduler is based on interactivity score mechanism. The interactivity score is inspired by the ULE scheduler (FreeBSD scheduler).

Services available


Need anything else?

Contributors list

No Data


The CacULE CPU scheduler is a CFS patchset that is based on interactivity score mechanism. The interactivity score is inspired by the ULE scheduler (FreeBSD scheduler). The goal of this patch is to enhance system responsiveness/latency.

About CacULE Scheduler

  • Each CPU has its own runqueue.
  • NORMAL runqueue is a linked list of sched_entities (instead of RB-Tree).
  • RT and other runqueues are just the same as the CFS's.
  • Wake up tasks preempt currently running tasks if its interactivity score value is higher.

The CacULE Interactivity Score

The interactivity score is inspired by the ULE scheduler (FreeBSD scheduler). For more information see: CacULE doesn't replace CFS with ULE, it only changes the CFS' pick next task mechanism to ULE's interactivity score mechanism for picking next task to run.


Sets the value m for interactivity score calculations. See Figure 1 in The default value of in CacULE is 32768 which means that the Maximum Interactive Score is 65536 (since m = Maximum Interactive Score / 2). You can tune schedinteractivityfactor with sysctl command:

sysctl kernel.sched_interactivity_factor=50

This command changes the schedinteractivityfactor from 32768 to 50.


Instead of calculating a task IS value for infinite life time, we use

which is 22s by default. Task's
shrink whenever a task life time exceeds 30s. Therefore, the rate of change of IS for old and new tasks is normalized. The value
can be changed at run time by the following sysctl command:
sysctl kernel.sched_max_lifetime_ms=60000
The value is in milliseconds, the above command changes
from 22s to 60s.

In the first round, when the task's life time became > 22s, the

get reset to be (
current_time - 11s
), then, the task will keep resetting every 15s.

Starve and Cache Scores

See here.


See here.


  • The complexity of Enqueue a task is O(1).
  • The complexity of Dequeue a task is O(1).
  • The complexity of pick the next task is in O(n).

n is the number of tasks in a runqueue (each CPU has its own runqueue).

Note: O(n) sounds scary, but usually for a machine with 4 CPUS where it is used for desktop or mobile jobs, the maximum number of runnable tasks might not exceeds 10 (at the pick next run time) - the idle tasks are excluded since they are dequeued when sleeping and enqueued when they wake up.

Tasks' Priorities

The priorities are applied as the followings: The

is used in Interactivity Score as the sum of execution time. The
is adjusted by CFS based on tasks priorities. The same code from CFS is used in CacULE. The
is equal to
if a task has nice value of 0 (normal priority). The
will be lower than
for higher tasks priorities, which make Interactivity Score thinks that those task didn't run for much time (compared to their actual run time). The
will be higher than
for lower tasks priorities, which make Interactivity Score thinks that those task ran for much time (compared to their actual run time). So priorities are already taken in the acount by using
in the Interactivity Score equation instead of actual

Response Driven Balancer (RDB)

This is an experimental load balancer for Cachy/CacULE. It is a lightweight load balancer which is a replacement of CFS load balancer. It migrates tasks based on their HRRN/Interactivity Scores (IS). Most of CFS load balancing-related updates (cfs and se updates loads) are removed. The RDB balancer follows CFS paradigm in which RDB balancing happen at the same points CFS does. RDB balancing happens in three functions:

, and
. The
is called exactly at the same time as CFS did (when pick next task fails to find any task to run). The RDB
pulls one task that is the highest HRRN/IS from any CPU. The RDB
is called in
when CPU is idle, it does the same as
but with slight changes since
is a special case. The RDB
checks if the current (NORMAL) runqueue has one task, if so, it pulls the highest of the highest HRRN/IS among all other CPUS. If the runqueue has more than one task, then it pulls any highest HRRN/IS (same as idle does). A CPU cannot pull a task from another CPU that has fewer tasks (when pull any). For the all three balancing
, and
, the cpu first tries to pull from a CPU that shares the same cache (
). If can't pull any then it tries to pull from any CPU even though they are not in the same core. Only when pulling the highest of the highest HRRN/IS (i.e.
when CPU has one task), there is no check for shared cache.

How to install

The following installation links are not only for easier installation, but they are also right configured for best CacULE experience.




AUR - ptr1337

Patched Kernel Tree

  1. Go to kernel tree repository
  2. Select a tag version that starts with
    cachy / cacule
  3. Download and compile

How to apply the patch

  1. Download the linux kernel ( that is same version as the patch (i.e if patch file name is cachy-5.7.6.patch, then download
  2. Unzip linux kernel
  3. Download cachy patch file and place it inside the just unzipped linux kernel folder
  4. cd linux-(version)
  5. patch -p1 < cachy-5.7.6.patch (or git -am)
  6. To build the kernel you need to follow linux build kernel documentation and tutorials.

To confirm that CacULE is currently running: ```

dmesg | grep -i "cacule cpu" [ 0.122999] CacULE CPU scheduler v5.9 by Hamad Al Marri.

## Suggested Configs
For a helper script to auto config use [this](


The tests are ran 11 times and best 10 tests are picked. Between each test, a sleep for 2 minutes such the following script:

for i in (seq 1 11); sleep 2m; ; end ```

For the following tests, CacULE is patched on Ubuntu linux-lowlatency kernel source.

Benchmarks Data

Stress-ng test

Benchmarks Data Benchmarks Data

Latency test

Please see the scripts for responsiveness/latency tests: os-scheduler-responsiveness-test

Benchmarks Data Benchmarks Data

Blind Tests

I made comparison between cfs and cachy on xanmod, for blind test

  • test1:
  • test2:
  • test3:

to reveal the which is which go back to time 0s on the video and see

uname -r

Note: In one of the tests, the recorder seems to be freezes and lagging, I repeated this test twice, while testing system is not pausing but the recorder maybe freezing or lagging while recording.

Special Thanks to

  1. Alexandre Frade (the maintainer of xanmod)
  2. Raymond K. Zhao (github)
  3. Peter Jung (github)
  4. JohnyPeaN (github)




We use cookies. If you continue to browse the site, you agree to the use of cookies. For more information on our use of cookies please see our Privacy Policy.