The major differences of Alinux 4 compared with Alinux 3 in terms of product positioning, kernel, components, and compatibility, for reference when evaluating upgrades and planning migration.-Alibaba Cloud Linux(Alinux)-阿里云帮助中心

Product positioning and recommended scenarios

Alinux 4 no longer pursues CentOS-compatible replacement. Instead, it adopts a brand-new 6.6 kernel and re-selects the versions of its core toolchain. Its design goals target directions such as heterogeneous computing power support, AI computing power optimization, AI operations observability, and intelligent system evolution.

Product generation positioning comparison

Dimension	Alibaba Cloud Linux 3	Alibaba Cloud Linux 4
Release year	2021	July 2025
Upstream base	Anolis OS 8	Anolis OS 23
CentOS compatibility	Core goal	No longer serves as a CentOS-compatible replacement
Core driver	Replacing CentOS and enabling Alibaba Cloud 8th-generation instances	AI-driven, heterogeneous computing power, intelligent evolution
Kernel version	5.10 (ANCK)	6.6 (ANCK)
Package management	dnf (yum-compatible)	dnf (same as Alinux 3, with a new-generation repository structure)
Typical component name	al8	alnx4

Recommended scenarios

Alinux 4 is recommended for the following scenarios:

Agent workload scenarios: Supports serving as an Agent Runtime, provides security protection and token-saving capabilities, fully supports the deployment and tuning of Alibaba Cloud and open source Sandbox framework runtime environments, and offers unique advantages in startup speed and workload density.
9th-generation and later general-purpose compute instances: Provides kernel-level performance optimization and feature enablement.
Training and inference scenarios: Provides training and inference suites to achieve optimization and acceleration for training and inference scenarios.
Domestic instance types: Meets security and compliance requirements and provides a lifecycle maintenance of up to 13 years.

Full component comparison

Based on a comparison between Alinux 3 (version 3.13 baseline) and Alinux 4 (version 4.0.2 baseline) components, identical components account for approximately 58%. The overall difference distribution is as follows:

Component status	Number of components	Description
Inherited by Alinux 4	1706	Among them, 1666 components are completely identical, and the remaining 40 are equivalent-capability components with changed component names/providers.
No longer provided by Alinux 4	1191	Mostly multi-language support and modules packages.
Newly added by Alinux 4	1109	Mostly for product strategy and ecosystem coverage. Among them, 257 are Perl language support packages, 427 are Python language support packages, and 40 are for OCaml support and GCC multi-version support.

For the full component comparison, see Appendix: Full component comparison list.

Module/component version differences

System feature changes

Capability	Alibaba Cloud Linux 3	Alibaba Cloud Linux 4	Difference description
Package management	dnf-4.7.0	dnf-4.16.2	No difference in usage: both dnf and yum are provided. The higher version is optimized in terms of security, signature verification, and performance.
Network configuration	NetworkManager-1.40.16	NetworkManager-1.44.2	Enhances container networking, WireGuard, and DNS-over-TLS by default.
Network packet filtering	nftables-1.0.4	nftables-1.0.8	Further converges the iptables compatibility layer.
Default container runtime	podman-4.9.4	moby-28.3.3 / containerd-1.7.29	Changes the docker provider and also provides an available containerd component.
Java distribution	OpenJDK 1.8/11/17/21 (community edition)	Alibaba Dragonwell 1.8/11/17/21/25	Additionally provides JDK 25 and accelerates OpenJDK through Dragonwell by default.
Default Python	python3.6 (with additional support for 3.11)	python3.11	3.11 offers notable system optimizations, including the specializing adaptive interpreter and inline caching.
OpenSSL	OpenSSL 1.1.1 (compatible with the legacy ABI)	OpenSSL 3.0.12 (default) / OpenSSL 1.1.1q (also provided)	OpenSSL 3.0.12 provides FIPS 140-3, the provider architecture, and TLS 1.3 priority.
Cgroup	Cgroup V1 enabled by default	Cgroup V2 enabled by default	Tools that depend on cgroup v1 need to be adapted.

Note: Alinux 4 provides cgroup v2 and OpenSSL 3.0 by default. Binaries that use the legacy OpenSSL ABI (such as libssl.so.1.1) need to be recompiled or have compatibility packages installed; container orchestration or monitoring tools that depend on cgroup v1 paths need to be adapted to the cgroup v2 unified hierarchy.

Component upgrade descriptions

Component	Category	Alinux 3	Alinux 4	Main changes
kernel	Kernel	5.10	6.6	ANCK 6.6 introduces a large number of upstream capabilities such as io_uring enhancements, ext4 performance optimizations, large folio, MGLRU, EEVDF/sched_ext, and cgroup v2 cpuset.
glibc	Base	2.32	2.38	Supports new system calls from Linux 5.8–6.3; optimizes ARM64/RISC-V; enhances malloc; accelerates VDSO.
libc++	Base	15.0.7	17.0.6	C++20 optimizations and new C++23 features; container and formatting optimizations.
libstdc++	Base	10.2.1	12.3.0	C++20 optimizations and early C++23 support; thread-safety adjustments.
libvirt	Virtualization	8.0.0	9.10.0	The virtualization stack is upgraded as a whole and integrates with a newer qemu.
qemu	Virtualization	6.2.0	8.2.0	Supports new hardware platforms and virtio enhancements; the package name is changed from qemu-kvm to qemu.
GCC	Compiler	8.5	12.3	Improved C++20/23, static analyzer, and new ISA instruction sets.
systemd	System management	239	254	Unified cgroup v2, Portable Services, Credential, BPF, OOM Policy, and more.
OpenSSL	Security	1.1.1	3.0.12	FIPS 140-3, the provider architecture, and TLS 1.3 priority.
containerd	Container	Not provided	1.7.29	Adds a standalone containerd component.
moby	Container	Not provided (podman only)	28.3.3	Adds moby (the open source Docker engine).

Key new kernel features

Storage

io_uring

Compared with 5.10, the 6.6 kernel continues to enhance the io_uring asynchronous IO framework:

Feature	Description
Async buffered writes	Adds buffered write support on the fast path, with an approximately 3x performance improvement in xfs tests.
Task work lock contention	The spin lock is changed to a lockless list, improving multi-threaded task_work_add performance by about 20%.
Multishot completion batching	Multishot completion events reuse IO_URING_F_COMPLETE_DEFER, increasing RPS from 8.3 M/s to 19.3 M/s (approximately 2.3x).
SQ/CQ caching optimization	The io_uring nop micro benchmark improves by about 9%.
New capabilities	multishot accept/recvmsg/timeout, network zero-copy, passthrough, the userspace block driver ublk, and more.

ext4

Covers multiple aspects such as block allocation, inode preallocation, concurrency and locking, and scalability:

Feature	Description
Improve delalloc buffer write performance	Removes unnecessary journal operations in the delalloc write path, improving UnixBench by about 73%.
Speedup orphan file handling	Introduces an orphan file to replace the on-disk linked list, reducing operation time by about 40% in a 128-thread micro benchmark.
Improve fast_commit performance	ext4_fc_commit_dentry_updates is optimized from O(n²) to O(n), improving performance by about 171x in the fs_mark multi-directory small-file scenario.
DIO shared inode lock covering preallocated blocks	Overwrite writes to preallocated blocks are changed to be protected by i_data_sem, improving 4k multi-threaded DIO write performance by about 4x.
Inode preallocation list → rbtree	Lookup complexity is reduced from O(n) to O(log n), improving sparse writes by 1x to 2x.
Speed up delalloc append write	In the append write scenario, i_disksize updates are deferred, improving 32-thread concurrent appends by about 34%; measured Kafka 2.6.2 throughput increases by 10%.
Enable large folio for regular files	Refactors folio on mballoc/write_begin/writeback based on buffer heads, improving buffered IO reads and writes by up to about 1.2x.

Memory

The memory subsystem covers directions such as cost optimization, large memory management, and software-hardware coordination.

Memory cost optimization

Feature	Description
HVO (HugeTLB vmemmap optimization)	Frees the unused tail page structs in hugetlb huge pages, saving 16G of memory for a 1T-sized 1G hugetlb.
DAMON (Data Access Monitor)	Proactively reclaims cold memory based on region sampling and adaptive region adjustment.
MGLRU cold memory reclamation	A more lightweight memory aging and proactive cold memory reclamation solution.
tmpfs zero-page filling	Reuses zero pages for tmpfs sparse files to avoid occupying additional physical memory.

Large memory management (Large folio + Lock Scalability)

In AI and virtualization large-memory scenarios, the 6.6 kernel enables Large folio by default, supports ARM contiguous PTE and AMD THP to reduce TLB misses, and thoroughly solves the mmap_lock scalability problem that could only be worked around in the 5.10 era.

Memory software-hardware coordination optimization

Feature	Description
Memory tiering	Supports automatic hot/cold tiering management of heterogeneous CXL/PMEM memory.
Migration batch TLB flushing	Batches TLB IPIs to optimize migration path performance.
NUMA balancing supports huge pages	Large folio also participates in NUMA balancing, improving business performance by accessing local huge pages.
Code segment multiple replicas (duptext)	Copies the code segment of remote nodes to the local node to avoid cross-NUMA access.

Scheduling

Feature	Description
EEVDF	Scheduling based on virtual deadlines. Compared with CFS, it enables faster responses for latency-sensitive tasks while keeping throughput unchanged.
sched_ext	Adds the ext scheduling class, which implements custom scheduling policies through eBPF programs to tailor the optimal scheduler for different business scenarios.
PSI enhancements	Per-cgroup PSI statistics switch, irq/softirq load statistics, and unprivileged poll psi event.
cgroup v2 cpuset isolation	Adds an isolated mode (no load balancing within the cpuset range, suitable for exclusive scenarios such as DPDK).
Group Identity 2.0	Fine-grained scheduling optimization based on CFS/EEVDF, simply and efficiently avoiding hyper-threading contention.
Group Balance 2.0	A dynamic scheduling solution that resolves affinity domain issues and cache/TLB contention interference in CPU-share mode.

Categorized analysis of differentiated components

Components no longer provided by Alinux 4

There are 1191 components in total, distributed by the reason for their introduction as follows:

190 multi-language format support packages: Alinux 4 supports only Chinese and English; other languages are not yet supported.
108 Module packages (DNF Modular): Alinux 4 does not currently support the module package format.
36 driver components (kmod-*): Not yet provided by Alinux 4; follow-up plans are under discussion.
30 mingw compilation toolchains: Alinux 4 does not provide the mingw cross-compilation environment.
42 gcc multi-versions: such as gcc-toolset-12/13; Alinux 4 has switched to a new default gcc version.
34 OCaml support packages: Alinux 4 does not introduce the OCaml ecosystem.
9 Red Hat product components: Alinux 4 is a proprietary product and does not need to introduce them.
806 other application components: Not yet clearly categorized; the application side needs to confirm them one by one.

Upgrade recommendation: Before migration, use rpm -qa to export the package list of your existing Alinux 3 instances and compare it against the preceding categories. If you depend on module packages, gcc multi-version toolchains, mingw, OCaml, kmod-*, or Red Hat product components, evaluate alternatives in advance.

Components changed in Alinux 4

There are 40 components in total that exist in Alinux 4 with equivalent capabilities but different package names/providers. Common replacement relationships are as follows:

Original Alinux 3 component	Alinux 4 equivalent provider	Description
SDL 1.2.15	sdl12-compat 1.2.68	SDL 1.2 → SDL 2 compatibility layer
device-mapper-multipath 0.8.4	multipath-tools 0.9.5	Provider change
fipscheck 1.5.0	libkcapi-fipscheck 1.4.0	FIPS verification switches to libkcapi
glassfish-annotation-api / servlet-api	jakarta-annotations / jakarta-servlet	JavaEE → Jakarta EE namespace migration
hardlink 1.3	util-linux-core 2.39.1	Merged into util-linux-core
java-1.8.0/11/17-openjdk	java-1.8.0/11/17-alibaba-dragonwell	Default OpenJDK replaced with Dragonwell
python3.11-* series (17 items)	Corresponding python3-* packages	Package name normalization
qemu-kvm 6.2.0	qemu 8.2.0	Package name changed from qemu-kvm to qemu
shadow-utils 4.6	shadow 4.14.3	Package name adjustment
system-lsb 4.1	lsb-release 3.2	Provider change

Components unique to Alinux 4 (1109 items)

The unique components newly added by Alinux 4 compared with Alinux 3 are mainly distributed across the following directions:

427 Python language ecosystem packages: python3-* modules added around the default python 3.11 runtime.
257 Perl language ecosystem packages: CPAN module packages added in conjunction with the perl 5.36 upgrade.
40 OCaml and gcc multi-version support packages: newer toolchains provided through other means.
385 other ecosystem/product strategy packages: from the Anolis 23 / OpenAnolis community ecosystem expansion.

Compatibility and migration recommendations

Applicable scenario assessment

We recommend that you prioritize evaluating an upgrade to Alinux 4 in the following scenarios:

Business scenario	Upgrade benefits
AI training/inference (large models, vLLM, SGLang)	6.6 large folio, Uncached IO, Cachefs, full-stack profiling, and distributed inference optimization.
Heterogeneous/domestic hardware (Hygon, Zhaoxin, Kunpeng, Phytium, domestic GPUs)	Alinux 4 is the next-generation core foundation of Alibaba Cloud's domestic route, with native enablement.
9th-generation and later instances	New instruction sets, platform drivers, and scheduling optimizations.
Large-scale containers/co-location	cgroup v2 by default, per-cgroup PSI, cpuset isolated, and Group Identity/Balance 2.0.
Strong requirements for OpenSSL 3.0, Python 3.11, or GCC 12+	Modern infrastructure works out of the box.

High-risk compatibility items

OpenSSL 3.0: The legacy libssl.so.1.1 binary is no longer provided by default and needs to be recompiled or have a compatibility package installed.
cgroup v2 by default: Container orchestration and monitoring agents that depend on cgroup v1 paths need to be adapted.
Java defaults to Dragonwell: If your business strictly depends on OpenJDK behavior or the vendor string, you need to explicitly specify between OpenJDK and Dragonwell.
Python defaults to 3.11: C extensions compiled with Python 3.6 and legacy scripts that depend on distutils need to be adapted.
Module packages are no longer supported: Deployment scripts that use DNF Modular need to be refactored.
kmod-* drivers: Some hardware drivers (such as ena, bnxt, and hns3) are not currently provided on Alinux 4, so you need to evaluate the business impact.
Package name changes: Namespace migrations such as qemu-kvm → qemu, shadow-utils → shadow, system-lsb → lsb-release, and python3.11-* → python3-* require updating deployment scripts.

Recommended migration path

Inventory: On the Alinux 3 instance, run rpm -qa > alinux3-pkglist.txt and perform a difference analysis against the categorized analysis of differentiated components in this topic.
Replace: For changed components, adjust the deployment scripts to the Alinux 4 equivalent package names.
Evaluate: For the components "to be confirmed one by one (806 items)", verify their necessity in a test environment.
Pilot: Prioritize piloting Alinux 4 on non-core business in AI, co-location, and domestic hardware scenarios.
Scale up: After the pilot is stable, replace core business in batches, using containerization as a transition when necessary.