Statistical state change of anonymous pages in the /proc/meminfo file - Alibaba Cloud Linux

Starting with kernel version 4.19.91-22.al7, Alibaba Cloud Linux 2 and all versions of Alibaba Cloud Linux 3 report Active(anon) and Inactive(anon) differently in /proc/meminfo. If your applications or monitoring tools rely on these fields, the values you observe will not match historical data collected before the upgrade.

What Active(anon) and Inactive(anon) track

In /proc/meminfo, Active(anon) and Inactive(anon) track swap-backed memory — primarily anonymous mappings such as heap and stack memory allocated by applications (for example, via malloc()). Together they form the Active and Inactive totals:

Active(anon): anonymous memory that has been recently accessed and is less likely to be reclaimed by the kernel
Inactive(anon): anonymous memory that has not been accessed recently and is a candidate for reclaim

What changed

The Linux kernel community changed how newly allocated anonymous pages are placed on the least-recently used (LRU) lists in Linux Kernel 5.10 (commit b518154e59aab3ad0780a169c5cc84bd4ee4357e). Before this change, newly allocated anonymous pages were placed on the active LRU list by default. After this change, they are placed on the inactive LRU list and only move to the active list after they are accessed.

Alibaba Cloud incorporated this upstream change into:

Alibaba Cloud Linux 2 starting with kernel version 4.19.91-22.al7.x86_64
Alibaba Cloud Linux 3 (all versions)

The following table shows how anonymous page accounting differs between kernel versions.

Kernel version	Default placement of newly allocated anonymous pages	Moved to `Active(anon)` when	Moved to `Inactive(anon)` when
Alibaba Cloud Linux 2 earlier than `4.19.91-22.al7.x86_64`	`Active(anon)`	N/A — already active by default	Memory is insufficient
Alibaba Cloud Linux 2 `4.19.91-22.al7.x86_64` or later, and Alibaba Cloud Linux 3	`Inactive(anon)`	The pages are subsequently accessed	N/A — already inactive by default

To check whether your kernel includes this change, run:

uname -r

If the output is 4.19.91-22.al7.x86_64 or later (for Alibaba Cloud Linux 2), or any version of Alibaba Cloud Linux 3, the new behavior is in effect.

Potential impacts

This change affects any system that monitors or makes decisions based on Active(anon) or Inactive(anon) values in /proc/meminfo. Common scenarios include:

Memory monitoring and alerting: Alert thresholds based on Active(anon) may trigger unexpectedly after a kernel upgrade. The same workload now shows a higher Inactive(anon) and lower Active(anon), even when total memory usage is unchanged.
Application-level memory management: Applications that read /proc/meminfo to determine memory pressure and tune their behavior — for example, cache eviction policies — may behave differently after the upgrade.
Capacity planning and dashboards: Historical trend data for Active(anon) and Inactive(anon) will show a discontinuity at the point of the kernel upgrade, making before-and-after comparisons misleading.

What to do

Review how your applications and monitoring tools use Active(anon) and Inactive(anon), then adjust based on the scenario:

Memory monitoring and alerting: Recalibrate thresholds based on observed values after the kernel upgrade. The distribution between Active(anon) and Inactive(anon) has shifted even when total memory usage is the same.
Applications that read /proc/meminfo: Re-evaluate any logic that branches on Active(anon) or Inactive(anon) values to confirm it reflects the new default placement behavior.
Historical dashboards: Mark the kernel upgrade event on your timeline to distinguish the statistical change from a genuine workload change.