Re: [PATCH 2/2] mm: vmscan: fix node reclaim ignoring swappiness parameter

From: Johannes Weiner

Date: Mon Jul 13 2026 - 07:28:17 EST


On Sat, Jul 11, 2026 at 05:11:57PM +0800, Ridong Chen wrote:
> From: Ridong Chen <chenridong@xxxxxxxxxx>
>
> sc_swappiness() had two separate definitions depending on
> CONFIG_MEMCG. The !CONFIG_MEMCG variant simply returned
> vm_swappiness, ignoring the proactive_swappiness value passed
> through scan_control. This caused the swappiness parameter
> written to /sys/devices/system/node/nodeX/reclaim to have no
> effect when CONFIG_MEMCG is disabled.
>
> Fix this by consolidating sc_swappiness() into a single definition
> that checks sc->proactive_swappiness first, then falls back to
> mem_cgroup_swappiness() which already handles both CONFIG_MEMCG
> and !CONFIG_MEMCG.
>
> Before fix (swappiness=max ignored, mostly file pages reclaimed):
>
> # cat /proc/sys/vm/swappiness
> 60
> # cat /proc/vmstat | grep pgsteal
> pgsteal_kswapd 0
> pgsteal_direct 0
> pgsteal_khugepaged 0
> pgsteal_proactive 1840
> pgsteal_anon 25
> pgsteal_file 1815
> # echo "64M swappiness=max" > /sys/devices/system/node/node0/reclaim
> # cat /proc/vmstat | grep pgsteal
> pgsteal_kswapd 0
> pgsteal_direct 0
> pgsteal_khugepaged 0
> pgsteal_proactive 18013
> pgsteal_anon 337
> pgsteal_file 17676
>
> After fix (swappiness=max honored, anon pages reclaimed as expected):
>
> # cat /proc/vmstat | grep pgsteal
> pgsteal_kswapd 0
> pgsteal_direct 0
> pgsteal_khugepaged 0
> pgsteal_proactive 0
> pgsteal_anon 0
> pgsteal_file 0
> # echo "64M swappiness=max" > /sys/devices/system/node/node0/reclaim
> # cat /proc/vmstat | grep pgsteal
> pgsteal_kswapd 0
> pgsteal_direct 0
> pgsteal_khugepaged 0
> pgsteal_proactive 16283
> pgsteal_anon 16283
> pgsteal_file 0
>
> Fixes: 68cd9050d871 ("mm: add swappiness= arg to memory.reclaim")
> Signed-off-by: Ridong Chen <chenridong@xxxxxxxxxx>

Acked-by: Johannes Weiner <hannes@xxxxxxxxxxx>

I would put Fixes: b980077899ea ("mm: introduce per-node proactive
reclaim interface") instead. It wasn't a bug before that.

Probably warrants a stable CC for 6.16 as well since this is pretty
user-visible breakage.