Change the kernel preemption mode-Alibaba Cloud Linux(Alinux)-阿里云帮助中心

Alibaba Cloud Linux 3 with kernel 5.10.134-17 or later supports dynamic kernel preemption switching at runtime — no rebuild or static reconfig required. Switch between none and voluntary preemption modes to match your workload's latency and throughput requirements.

Preemption modes

The following modes are available on Alibaba Cloud Linux 3 (kernel 5.10.134-17 or later).

Mode	Description	Throughput	Latency
`none`	The kernel is non-preemptible. When the kernel executes a critical task, the CPU resources of the task cannot be preempted and the task cannot be interrupted. The system performs context switching when the system returns responses in user mode and does not perform active preemption in kernel mode.	High	Higher (may spike)
`voluntary`	The kernel actively releases CPU resources at specific preemption points.	Slightly lower	Lower

Why full mode is not supported

The Linux community also defines a full preemption mode, where CPU resources can be preempted at any time in the kernel. More code checkpoints are added to allow the kernel to perform quasi-real-time task scheduling, which increases the overheads of kernel context switching. The full mode is mainly used in real-time systems or scenarios that require high response speed, and is suitable for desktop environments that require fast response and high interactivity — not cloud server workloads.

Alibaba Cloud Linux 3 does not support full mode. In benchmark testing on cloud server workloads, enabling dynamic switching to full mode causes several Linux benchmark metric values to drop by more than 10%.

Choose a mode

Use the following guidance to decide which mode fits your workload:

Latency-sensitive workloads (online transaction processing, real-time APIs): use voluntary mode to reduce scheduling delay at the cost of a small throughput reduction.
Throughput-oriented workloads (batch processing, compute-intensive tasks): keep the default none mode to maximize CPU utilization.

See Performance considerations for benchmark data.

Prerequisites

Before you begin, ensure that you have:

An instance running Alibaba Cloud Linux 3 with kernel version 5.10.134-17 or later
sudo privileges on the instance

Change the preemption mode persistently

A persistent change survives instance restarts. It works by adding or removing the preempt=none kernel boot argument via grubby.

Check the current preemption mode.

sudo cat /sys/kernel/debug/sched_preempt

Get the kernel path from the current boot entry.
```
sudo grubby --info=0
```
Note the kernel= value — for example, /boot/vmlinuz-5.10.134-17.2.al8.x86_64.
Update the boot argument. Replace <kernel> with the path from step 2.
- To switch to voluntary: ``bash sudo grubby --update-kernel=<kernel> --remove-args="preempt=none" ``
- To switch to none: ``bash sudo grubby --update-kernel=/boot/vmlinuz-<kernel> --args="preempt=none" ``
Restart the instance.
```
sudo reboot
```

Verify the new preemption mode.

sudo cat /sys/kernel/debug/sched_preempt

Change the preemption mode temporarily

A temporary change takes effect immediately but becomes invalid after an instance is restarted. Use this for testing before committing to a persistent change.

The following example switches the preemption mode to voluntary.

Check the current preemption mode.
```
sudo cat /sys/kernel/debug/sched_preempt
```
The following figure shows the current mode is none.

Switch to voluntary.

sudo sh -c 'echo voluntary > /sys/kernel/debug/sched_preempt'

Verify the change.
```
sudo cat /sys/kernel/debug/sched_preempt
```
The following figure shows the mode is now voluntary.

Performance considerations

Benchmark tests on MySQL, Redis, and NGINX on both x86 and Arm64 instances show that none mode outperforms voluntary mode in most cases, though the gap is relatively small.

The tests use three OLTP workloads: oltp_write_only, oltp_read_only, and oltp_read_write. Higher TPS (transactions per second) and QPS (queries per second) values, combined with lower avg latency and avg 95th percentile latency, indicate better performance. The none mode results are normalized to 1 as the baseline.

x86
Arm64

On both architectures, none mode delivers higher throughput. If your workload is latency-sensitive and the small throughput trade-off is acceptable, voluntary mode can reduce scheduling latency.