Introduction
Linux runs many processes and threads concurrently. However, a single logical CPU can execute only one task at a time. When multiple tasks are runnable, Linux must decide which task should run next.
For example, suppose Apache is processing HTTP requests, PostgreSQL is executing SQL, and another process is doing background processing. In such situations, multiple tasks may require execution on the CPU at the same time.
Therefore, the Linux kernel selects the next task to run from among tasks in the runnable state. The CPU scheduler is responsible for this decision.
The CPU scheduler enables multiple tasks to share CPU resources efficiently. It determines which runnable task should execute next according to factors such as scheduling policy and priority.
In a multi-core environment, the scheduler must also decide which CPU should execute each task.
Understanding the CPU scheduler helps answer practical questions such as: Where are runnable tasks managed? How does Linux choose which task runs next? What effect does the nice value have when tasks compete for CPU time?
This article explains the Linux CPU scheduler, run queues, scheduling classes, CFS and EEVDF, nice values, CPU affinity, and practical commands for observing scheduling behavior.
What Is a CPU Scheduler?
Linux has many processes and threads running at the same time.
However, there is a limit to the tasks that can be executed simultaneously on one CPU. Therefore, when multiple tasks are in a runnable state, it is necessary to decide which task should be executed by the CPU next.
The CPU scheduler plays this role.
Role of CPU scheduler
The CPU scheduler is a mechanism in the Linux kernel that selects the next task to be executed from among the tasks that can be executed by the CPU.
If multiple tasks are waiting to be executed on a CPU, they cannot all be executed simultaneously on one CPU. The CPU scheduler selects a task to run, and the selected task executes instructions on the CPU.
The role of the CPU scheduler can be simplified as shown in the diagram below.
CPU scheduler selects tasks
The targets of scheduling in Linux are “tasks” managed by the kernel. When multiple threads exist in the same process, each thread is scheduled as an independent task.
Therefore, in an environment with multiple CPU cores, different threads belonging to the same process may run on different CPUs.
The CPU scheduler allows multiple processes and threads to share the CPU by selecting tasks to execute from among these many tasks.
The CPU scheduler is a mechanism for efficiently using the CPU.
If the CPU scheduler simply continues to execute the same task, other tasks will not be able to utilize the CPU. Therefore, in Linux, tasks to be executed on the CPU are determined by considering task priorities, scheduling policies, etc. This allows efficient use of limited CPU even in environments with a large number of processes and threads.
So where are the tasks that are ready to run on the CPU managed until they are selected by the scheduler? In the next chapter, we’ll take a closer look at the run queue, which manages executable tasks.
What Is a Run Queue?
A task that becomes executable on the CPU does not necessarily run on the CPU immediately. If another task is already using the CPU, you may have to wait until it runs on the CPU.
Linux provides a mechanism called “run queue” to manage such executable tasks.
A Run Queue Manages Runnable Tasks
Conceptually, a run queue is where Linux manages tasks that are runnable and eligible to compete for CPU time.
For example, while task A is running on the CPU, task B and task C also become runnable. In this case, task B and task C will be waiting for an opportunity to be executed on the CPU.
The CPU scheduler selects the next task to be executed on the CPU from among the executable tasks managed by the run queue.
For a simplified mental model, you can think of a run queue as the place where runnable tasks are managed while waiting for CPU time.
Each CPU Has Its Own Run Queue
In modern Linux, there is a run queue for each CPU, rather than having one run queue shared across the system.
For example, if you have 4 logical CPUs, each CPU has a corresponding run queue.
CPU 0：run queue → CPU 0
CPU 1：run queue → CPU 1
CPU 2：run queue → CPU 2
CPU 3：run queue → CPU 3
Each CPU basically selects the next task to execute from the tasks managed by its own run queue.
By having a run queue for each CPU, multiple CPUs can perform scheduling and execute tasks in parallel.
An image diagram is shown below.
Adjust load between CPUs
If a run queue exists for each CPU, the number of tasks waiting to be executed may be uneven depending on the CPU.
For example, there may be many tasks in the run queue of CPU 0, but very few tasks in CPU 1.
CPU 0: Tasks A, B, C, D
CPU 1: Task E
In this state, even though many tasks are waiting to be executed on CPU 0, the processing power of CPU 1 may not be fully utilized.
Therefore, Linux moves tasks between CPUs as needed to adjust the load imbalance. This mechanism is called load balancing.
However, it is not enough to simply equalize the number of tasks. The Linux kernel considers various factors when placing tasks, such as CPU cache, CPU affinity, and NUMA.
How the CPU scheduler selects tasks
So, under what conditions does the CPU scheduler select the execution target and switch tasks?
Not all tasks are treated the same
Linux does not allocate CPU to all tasks in exactly the same way. A “scheduling policy” is set for a task, which determines the rules for allocating CPU.
For example, the method of allocating CPU differs between a normal task that executes a general application and a task that requires real-time performance. Furthermore, even for normal tasks, you can adjust the priority of using the CPU by using nice values, etc.
In this way, the CPU scheduler determines the next task to execute according to the scheduling rules set for the task.
Timing of task switching
The tasks executed by the CPU are switched at various times. A typical example is when a running task no longer requires the CPU due to I/O waits, etc.
For example, when task A waits to read data from storage, task A relinquishes the CPU. The CPU scheduler selects another executable task and allocates the CPU to that task.
Scheduling is also performed when a task that should be executed with priority over the currently executing task becomes executable.
If the task to be executed changes, the execution state of the current task must be saved and the execution state of the next task must be restored. This process is a “context switch.”
The detailed mechanism of context switching will be explained in another article.
Utilize CPU fairly and efficiently
One of the important roles of the CPU scheduler is to efficiently utilize the limited CPU for multiple tasks. If a specific task occupies the CPU for a long time, it becomes difficult for other tasks to execute.
On the other hand, it is not sufficient to simply allocate the CPU for the same amount of time to all tasks. This is because the priority and required responsiveness vary depending on the task. For this reason, Linux determines which tasks should be executed on the CPU by considering the task type and priority.
So, how does Linux use different scheduling methods for different types of tasks?
In the next chapter, we will look at Linux’s “scheduling classes”.
Linux Scheduling Classes
Linux does not schedule all tasks using the same rules.
Some tasks run common applications, while others are real-time tasks that must be completed within a fixed time. Linux provides multiple scheduling methods because each requires different characteristics.
The mechanism that handles these different scheduling methods inside the Linux kernel is the “scheduling class.”
What is a scheduling class?
The scheduling class is a mechanism that determines the rules for assigning tasks to CPUs. The CPU scheduler uses the appropriate scheduling class depending on the scheduling policy set for the task.
Linux has multiple scheduling classes, but to understand a typical Linux server, it is easiest to think of them broadly as follows.
| kinds | Main scheduling policy | Purpose |
|---|---|---|
| normal task | SCHED_OTHER（SCHED_NORMAL） | Common applications |
| real-time tasks | SCHED_FIFO / SCHED_RR | Processing that requires real-time performance |
| deadline tasks | SCHED_DEADLINE | Processing that emphasizes execution deadlines |
Many of the Apache, PostgreSQL, shell, Linux commands, etc. that are normally executed on Linux are scheduled as normal tasks.
Scheduling Normal Tasks
Typical processes and threads use a scheduling policy called SCHED_OTHER. The name SCHED_NORMAL is also used inside the Linux kernel.
Standard tasks allocate the CPU to multiple tasks while ensuring that only a specific task does not continue to monopolize the CPU. You can also differentiate the CPU allocation between tasks using the nice value.
For example, if normal task A and task B require CPU, Linux will allocate the CPU while considering their respective priorities and previous CPU usage.
Understanding the scheduling of this normal task is especially important for regular Linux server operations.
Scheduling Real-Time Tasks
Linux also provides real-time scheduling, which allows tasks to run at a higher priority than normal tasks. Typical policies are SCHED_FIFO and SCHED_RR.
SCHED_FIFO basically executes tasks with the same priority using the FIFO (First In, First Out) concept. A running task can continue running unless it relinquishes the CPU or a higher priority task becomes available.
On the other hand, with SCHED_RR (Round Robin), if there are multiple real-time tasks with the same priority, they are executed by alternating the CPU at regular intervals.
For example, if there are tasks A, B, and C with the same priority, they will use the CPU in order as shown below.
Task A → Task B → Task C → Task A → …
Please note that real-time tasks are executed with priority over normal tasks, so incorrect settings may make it difficult for normal processes to utilize the CPU.
SCHED_DEADLINE
Linux also has a scheduling policy called SCHED_DEADLINE. SCHED_DEADLINE schedules tasks based on conditions such as “how much CPU execution time is required” and “by when does processing need to be done”.
Although it is not something that is often configured on a typical Linux server, it is sufficient to understand that Linux has scheduling methods for different purposes in addition to normal tasks and real-time tasks.
CFS and EEVDF
For common tasks executed on Linux, it is necessary to appropriately allocate the CPU to multiple tasks, rather than having only a specific task occupy the CPU.
For many years, Linux has used CFS (Completely Fair Scheduler) to schedule normal tasks. Starting with Linux 6.6, the transition to EEVDF (Earliest Eligible Virtual Deadline First) has begun, using concepts such as virtual runtime that have been used in CFS.
Here, we will first understand the basic concept of CFS, and then look at what has changed with EEVDF.
What is CFS?
CFS (Completely Fair Scheduler) is a scheduler that aims to fairly allocate CPU time to normal tasks.
For example, suppose tasks A, B, and C have the same priority and require CPU. Ideally, it would be desirable for each task to be able to use the CPU equally, rather than having only certain tasks use the CPU for a long time.
Therefore, in CFS, the next task to be executed is determined by considering “how much CPU each task uses.” At this time, “vruntime” is important.
What is vruntime?
vruntime (Virtual Runtime) represents a task’s CPU execution progress while taking its scheduling weight into account. As a task consumes CPU time, its vruntime increases.
For example, suppose you have a task like this:
Task A: vruntime 10
Task B: vruntime 20
Task C: vruntime 30
CFS gives priority to executing tasks with a small vruntime, giving an opportunity to execute tasks that are not fully utilizing the CPU. In this example, task A is likely to be selected for execution next. When task A uses the CPU, vruntime increases, giving other tasks a chance to use the CPU.
This mechanism allows multiple tasks to share the CPU fairly.
Adjusting Fairness with nice Values
However, it does not give all tasks exactly the same amount of CPU time. A normal task can have a nice value, and that value can be used to weight CPU time allocation. High-priority tasks tend to get more CPU time because vruntime advances relatively slowly.
In other words, “fairness” in CFS does not mean giving the same CPU time to all tasks, but rather allocating the CPU fairly while taking into account the set weights.
What is EEVDF?
Historically, CFS primarily selected the task with the smallest vruntime. In current Linux, EEVDF (Earliest Eligible Virtual Deadline First) is used for task selection in the fair scheduling class.
EEVDF considers both whether a task is eligible to receive CPU time and how urgently it should run.
Eligibility and virtual deadline are important for this purpose.
First, EEVDF identifies eligible tasks. Among those tasks, it prioritizes the one with the earliest virtual deadline.
CFS to EEVDF
CFS and EEVDF are not completely unrelated mechanisms.
EEVDF changes how Linux chooses which fair-class task should execute next while retaining concepts such as vruntime and task weight.
Roughly speaking, it can be understood as follows.
| CFS | EEVDF |
|---|---|
| Management centered on vruntime | Inheriting the idea of vruntime etc. |
| Emphasis on fairness in CPU usage | Consider responsiveness in addition to fairness |
| Prioritize tasks with smaller vruntime | Select eligible tasks with early virtual deadlines |
EEVDF should not be thought of as an entirely separate scheduler that replaced every part of CFS. Instead, it changes task selection within Linux’s fair scheduling class while retaining core concepts such as virtual runtime and task weights.
nice Values and CPU Priority
On Linux, you can adjust the CPU usage priority for normal tasks. A typical mechanism is the “nice value.”
For example, if a CPU-intensive batch process and an application that processes user requests are running at the same time, you can lower the priority of the batch process to make it easier for other tasks to use the CPU.
What Is a nice Value?
The nice value is a value used to adjust the CPU scheduling priority of normal tasks.
The nice value can be set in the following range:
- -20: highest priority
- 0: default
- 19: lowest priority
In other words, the smaller the nice value, the higher the priority for using the CPU, and the larger the nice value, the lower the priority.
For example, if a task with a nice value of 0 and a task with a nice value of 10 require CPU at the same time, the task with a nice value of 0 will be more likely to be allocated more CPU time.
The nice value affects the distribution of CPU time
One thing to note about nice values is that it does not mean that tasks with high nice values will not be executed on the CPU.
The nice value affects the distribution of CPU time when multiple normal tasks require CPU. For example, a task with a nice value of 19 can still utilize the CPU if there is enough CPU available and no other tasks are available to run.
On the other hand, if multiple CPU-bound tasks are competing for the same CPU, differences in CPU time distribution depending on the nice value will likely appear.
In other words, the nice value is easier to understand if you think of it as a mechanism that adjusts “how much CPU time is allocated when CPU contention occurs,” rather than “whether or not the CPU can be used.”
Relationship between nice value and scheduler
For normal tasks, the weights used in scheduling change depending on the nice value. A task with a higher priority has a higher weight and is more likely to be allocated more CPU time. Conversely, increasing the nice value reduces the weight and allocates less CPU time when other tasks compete for the CPU.
Simplifying it, you can think of it like this:
Specifying priority with the nice command
On Linux, you can use the nice command to specify a nice value when starting a program. For example, to lower the scheduling priority of a CPU-intensive batch process by starting it with a nice value of 10, run:
[root@localhost ~]# nice -n 10 ./sample.shIn this case, sample.sh runs with a lower scheduling priority than a process using the default nice value of 0.
You can check the nice value with the top command. In this example, the NI column should show 10.
root@ubuntu20:~# top
top - 22:25:50 up 1:00, 2 users, load average: 1.05, 0.29, 0.10
Tasks: 127 total, 2 running, 124 sleeping, 0 stopped, 1 zombie
%Cpu(s): 9.7 us, 32.6 sy, 0.0 ni, 52.1 id, 0.0 wa, 0.0 hi, 5.7 si, 0.0 st
MiB Mem : 3919.9 total, 2724.5 free, 231.2 used, 964.3 buff/cache
MiB Swap: 2290.0 total, 2290.0 free, 0.0 used. 3459.1 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
22015 root 30 10 7024 3672 3240 R 40.9 0.1 0:02.59 sample.shThis is useful when you want a CPU-intensive batch process to receive a smaller share of CPU time when it competes with other applications.
Changing a Running Process with renice
If you want to change the nice value of a process that is already running, you can use the renice command. For example, to change the nice value of the process with PID 1234 to -10, run the following:
root@ubuntu20:~# renice -10 -p 22015
22015 (process ID) old priority -5, new priority -10
root@ubuntu20:~#After changing, check using the top or ps command.
root@ubuntu20:~# top
top - 22:25:50 up 1:00, 2 users, load average: 1.05, 0.29, 0.10
Tasks: 127 total, 2 running, 124 sleeping, 0 stopped, 1 zombie
%Cpu(s): 9.7 us, 32.6 sy, 0.0 ni, 52.1 id, 0.0 wa, 0.0 hi, 5.7 si, 0.0 st
MiB Mem : 3919.9 total, 2724.5 free, 231.2 used, 964.3 buff/cache
MiB Swap: 2290.0 total, 2290.0 free, 0.0 used. 3459.1 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
22015 root 15 -10 7024 3672 3240 R 40.9 0.1 0:02.59 sample.shIt was confirmed that the NI value has changed to -10.
Note that there are permission restrictions for general users to increase the priority of their own processes, that is, to reduce the nice value.
A nice Value Is Not a Measure of CPU Load
Changing the nice value allows you to adjust the CPU scheduling priority, but it does not directly limit the amount of CPU used by the process itself.
For example, if there is only one task that uses the CPU, that task may use a large amount of the CPU even if you increase the nice value.
Therefore, the nice value is not a setting for “limiting the CPU usage rate to ○% or less”, but a mechanism for adjusting the distribution of CPU time when there is CPU contention.
Which CPU executes in a multi-core environment?
Today’s Linux servers are generally equipped with multiple CPU cores.
In a multi-core environment, the CPU scheduler needs to consider not only which task to execute, but also which CPU to execute that task on.
For example, in an environment with 4 CPUs, if many tasks are concentrated only on CPU 0, the processing power of CPUs 1 to 3 will not be fully utilized.
Linux uses the entire system’s CPU efficiently by appropriately allocating tasks to multiple CPUs.
Have a run queue for each CPU
As mentioned above, Linux has a run queue for each CPU. Each run queue manages the tasks that can be executed on that CPU. The CPU scheduler basically selects the next task to run from the run queue corresponding to that CPU. This mechanism allows each CPU to execute tasks independently.
Unbalanced load occurs between CPUs
If each CPU has a run queue, the load may be uneven between CPUs.
For example, in the following situation:
CPU 0: Tasks A, B, C, D
CPU 1: Task E
CPU 2: No tasks
CPU 3: No tasks
In this state, CPU 0 has multiple tasks waiting to be executed on the CPU, while CPU 2 and CPU 3 are not utilized.
Looking at the system as a whole, the available CPU resources are not being fully utilized.
Distribute tasks with load balancing
In Linux, load balancing is performed by the CPU scheduler to adjust the load imbalance between CPUs. Efficiently utilize multiple CPUs by moving executable tasks from CPUs with high loads to CPUs with low loads.
The image is as below.
This makes it easier to run tasks in parallel on multiple CPUs.
Tasks Are Not Simply Distributed Evenly
However, Linux does not simply arrange the number of tasks in the run queue to be the same.
For example, if you move a task from CPU 0 to CPU 1, the data previously held in CPU 0’s cache may not be available on CPU 1. As a result, cache misses may increase and performance may decrease.
Additionally, in a NUMA environment*, the physical location of the CPU and memory also affects performance. Therefore, in Linux, tasks are placed while taking into consideration not only the CPU load, but also the CPU configuration and cache.
*NUMA (Non-Uniform Memory Access) is a system that manages servers with multiple CPUs by dividing the CPUs and memory into several groups (NUMA nodes).
Restricting Execution with CPU Affinity
Linux also has a mechanism called “CPU affinity” that limits the CPUs that can execute tasks. For example, if you set a task to run only on CPU 0 and CPU 1, that task will generally not run on CPU 2 or CPU 3.
CPU affinity can be checked and set using taskset command, etc. For example, to check the CPU affinity of PID 1234, run:
[root@almalinux ~]# taskset -cp 2671217
pid 2671217's current affinity list: 0-3
[root@almalinux ~]#If you want to set it to run on CPU 0 and CPU 1, run:
[root@almalinux ~]# taskset -cp 0,1 2671217
pid 2671217's current affinity list: 0-3
pid 2671217's new affinity list: 0,1
[root@almalinux ~]#CPU affinity allows you to control which CPU a particular task runs on. However, fixing the CPU limits the range in which Linux can freely place tasks, so performance does not necessarily improve.
Check CPU scheduling on Linux
So far, we have explained how the Linux CPU scheduler works, such as run queue, scheduling policy, nice value, and CPU affinity. You can actually see some of this information using Linux commands such as ps and top.
Here, we will introduce typical confirmation methods that will help you understand CPU scheduling.
Check process scheduling information with ps
With the ps command, you can check not only the PID and CPU usage of a process, but also the nice value and scheduling policy.
For example, run:
[root@almalinux ~]# ps -eo pid,comm,stat,ni,pri,cls,psr
PID COMMAND STAT NI PRI CLS PSR
1 systemd Ss 0 19 TS 1
2 kthreadd S 0 19 TS 2
3 pool_workqueue_ S 0 19 TS 0
4 kworker/R-rcu_g I< -20 39 TS 0
5 kworker/R-sync_ I< -20 39 TS 0
6 kworker/R-slub_ I< -20 39 TS 0The main items are:
| item | Content |
|---|---|
| PID | process id |
| COMMAND | command name |
| STAT | process state |
| NI | nice value |
| PRI | Scheduling priority |
| CLS | scheduling class |
| PSR | Last executed CPU |
For example, if TS is displayed in CLS, it is a task that is subject to normal time sharing. You can also check which CPU the task was running on by looking at the PSR.
Checking Running Processes with top
The top command allows you to check the processes using the CPU in real time.
Typical items include the following information:
PID: Process ID
PR: Priority
NI: nice value
S: Process state
%CPU: CPU usage rate
You can check the state of the process, especially by looking at S.
for example,
R: Running or Runnable
S: Interruptible Sleep
D: Non-interruptible Sleep
Z：Zombie
etc. will be displayed.
If the CPU load is high, you can see which tasks require more CPU by looking not only at %CPU but also by looking at which processes are in R.
Check the run queue status with vmstat
vmstat is useful for checking CPU wait status. For example, if you want to check at 1 second intervals, run as follows.
[root@almalinux ~]# vmstat 1
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
0 0 0 2383156 5756 251992 0 0 5 20 0 0 0 0 99 0 0
0 0 0 2383668 5756 252036 0 0 0 0 943 1306 1 1 99 0 0
0 0 0 2383668 5756 252036 0 0 0 4 647 1144 1 0 99 0 0
0 0 0 2383668 5756 252036 0 0 0 96 651 1148 0 0 100 0 0
0 0 0 2383668 5756 252036 0 0 0 0 662 1144 1 1 99 0 0In this output, pay particular attention to procs r. The r value shows the number of runnable processes, including processes currently running or waiting for CPU time. If r remains consistently high relative to the number of logical CPUs, CPU contention may be occurring.
A temporary increase in r does not by itself prove that the system lacks CPU capacity. Check it together with CPU utilization, load average, and the behavior of the relevant processes.
Check scheduling information in /proc
On Linux, you can also check the scheduling information for each process from /proc.
[root@almalinux ~]# cat /proc/2671217/sched
java (2671217, #threads: 59)
-------------------------------------------------------------------
se.exec_start : 19742068175.495653
se.vruntime : 16298.120623
se.sum_exec_runtime : 9.517587
se.nr_migrations : 1
nr_switches : 5
nr_voluntary_switches : 4
nr_involuntary_switches : 1
se.load.weight : 1048576
se.avg.load_sum : 42
se.avg.runnable_sum : 43008
se.avg.util_sum : 43008
se.avg.load_avg : 0
se.avg.runnable_avg : 0
se.avg.util_avg : 0
se.avg.last_update_time : 19742068175495168
se.avg.util_est : 400
policy : 0
prio : 120
clock-delta : 107
mm->numa_scan_seq : 0
numa_pages_migrated : 0
numa_preferred_nid : -1
total_numa_faults : 0
current_node=0, numa_group_id=0
numa_faults node=0 task_private=0 task_shared=0 group_private=0 group_shared=0
[root@almalinux ~]#
This file records various information regarding the scheduling of that task. The main items are as follows.
| Item | Description | Current value |
|---|---|---|
| se.vruntime | Virtual execution time, which represents how much CPU a task uses, taking fairness into account | 16298.120623 |
| se.sum_exec_runtime | Cumulative amount of time this task actually ran on the CPU | 9.517587 |
| nr_switches | Number of context switches that have occurred in this task | 5 |
It can be used when you want to investigate the operation of the CPU scheduler in more detail, but in normal operation, it will be easier to understand if you first check from ps, top, vmstat, etc.
Check multiple pieces of information together
When checking the status of CPU scheduling, it is important not to rely on just one value.
For example, if the CPU load is high,
- Check CPU usage and running processes with top
- Check the number of executable tasks with vmstat
- Check nice value and scheduling information with ps
- Check CPU affinity with taskset
Investigate by combining multiple pieces of information.
By understanding how the CPU scheduler works, you will be able to analyze the CPU load from the perspective of “Which tasks require the CPU,” “Are there any CPU execution waits,” and “Is there a problem with CPU placement or priority?” rather than just looking at the numerical value of “high CPU usage.”
Summary
In this article, we explained how the Linux CPU scheduler manages tasks and assigns them to the CPU.
On Linux, tasks made available for execution on the CPU are managed by a run queue. The CPU scheduler selects the next task to be executed from among them and assigns it to the CPU.
Also, not all tasks are scheduled the same way. Scheduling policies are available for each purpose, such as normal tasks and real-time tasks.
For normal tasks, in order to appropriately share the CPU between multiple tasks, the execution target is determined by taking into consideration the task priority and CPU usage status. By using the nice value, you can also adjust the distribution of CPU time when there is CPU contention.
Furthermore, in a multi-core environment, each CPU has a run queue, and load balancing adjusts the load between CPUs. You can also use CPU affinity to limit the CPUs that can execute tasks.
The basic flow of CPU scheduling can be summarized as follows.
Runnable tasks
↓
Manage with run queue
↓
CPU scheduler selects execution target
↓
Execute tasks on CPU
↓
Switch to another task as needed
On an actual Linux server, you can use ps, top, vmstat, taskset, etc. to check the status and priority of tasks, CPU execution queues, CPU affinity, etc.
By understanding how the CPU scheduler works, you will be able to not only look at numbers such as CPU usage rate and load average, but also think about the internal workings of Linux, such as “Why is the CPU waiting for execution?” and “How is the CPU allocated to tasks?”
References
EEVDF Scheduler — The Linux Kernel documentation
An EEVDF CPU scheduler for Linux [LWN.net]
English 
Japanese
コメント