mm/vmscan: fix swappiness=max and clean up per-node proactive reclaim

From: Ridong Chen <[email protected]>

Commit 57972c78e678 ("mm/vmscan: make __node_reclaim() more generic") moved the scan_control construction out to the callers and passed the struct in by pointer. After that change every use of the gfp mask inside __node_reclaim() goes through sc->gfp_mask, leaving the gfp_mask parameter unused. Just remove the dead parameter and update the callers accordingly. No functional change.

Acked-by Shakeel Butt <[email protected]>

Acked-by Johannes Weiner <[email protected]>

Reviewed-by Muchun Song <[email protected]>

Signed-off-by Ridong Chen <[email protected]>

From: Ridong Chen <[email protected]>

As Qi mentioned [1], when swappiness=max (SWAPPINESS_ANON_ONLY) is set, the reclaim logic is expected to reclaim anonymous pages exclusively. However, due to the current ordering of checks in get_scan_count(), file pages may still be evicted if can_reclaim_anon_pages() returns false, which contradicts the semantics of SWAPPINESS_ANON_ONLY.

Reproducer in a cgroup holding 64M of file cache, with no swap configured:

Before (file cache is wrongly evicted):

    # cat memory.stat
    anon 196608
    file 67178496
    pgscan_proactive 0
    # echo "64M swappiness=max" > memory.reclaim
    # cat memory.stat
    anon 208896
    file 4096                 <- page cache evicted
    pgsteal_proactive 16400
    pgscan_proactive 16400

After (file cache is left intact):

    # cat memory.stat
    anon 200704
    file 67178496
    pgscan_proactive 0
    # echo "64M swappiness=max" > memory.reclaim
    -bash: echo: write error: Resource temporarily unavailable
    # cat memory.stat
    anon 208896
    file 67178496             <- page cache untouched
    pgsteal_proactive 0
    pgscan_proactive 0

Fix this by bailing out early when SWAPPINESS_ANON_ONLY is set and no anonymous pages are reclaimable, before falling back to file reclaim.

[1] https://lore.kernel.org/cgroups/[email protected]/

Fixes 68a1436bde00 ("mm: add swappiness=max arg to memory.reclaim for only anon reclaim")

Suggested-by Qi Zheng <[email protected]>

Acked-by Shakeel Butt <[email protected]>

Acked-by Johannes Weiner <[email protected]>

Reviewed-by Muchun Song <[email protected]>

Signed-off-by Ridong Chen <[email protected]>

---
 mm/vmscan.c | 18 +++++++++++-------
 1 file changed, 11 insertions(+), 7 deletions(-)

mm/vmscan.c +0 -0

index 35c3bb15ae96..d6b383d96a0c 100644

From: Ridong Chen <[email protected]>

The previous patch fixes this issue for the traditional LRU, which also exists in MGLRU [1]. Fix this by checking whether swappiness is SWAPPINESS_ANON_ONLY in get_swappiness() first, and returning 0 from get_nr_to_scan() when swappiness is SWAPPINESS_ANON_ONLY and anon pages cannot be reclaimed, to avoid useless work.

The test result:
Before fix:

  # cat /sys/kernel/mm/lru_gen/enabled
  0x0007
  # cat memory.stat
  anon 204800
  file 67108864
  ...
  pgsteal_proactive 0
  pgscan_proactive 0

  # echo "64M swappiness=max" > memory.reclaim
  # cat memory.stat
  anon 208896
  file 0
  ...
  pgsteal_proactive 16384
  pgscan_proactive 16384

After fix:

  # cat memory.stat
  anon 188416
  file 67215360
  kernel 1970176
  ...
  pgsteal_proactive 0
  pgscan_proactive 0

  # echo "64M swappiness=max" > memory.reclaim
  -bash: echo: write error: Resource temporarily unavailable
  # cat memory.stat
  anon 204800
  file 67215360
  ...
  pgsteal_proactive 0
  pgscan_proactive 0

[1] https://sashiko.dev/#/patchset/[email protected]

Fixes 68a1436bde00 ("mm: add swappiness=max arg to memory.reclaim for only anon reclaim")

Signed-off-by Ridong Chen <[email protected]>

---
 mm/vmscan.c | 14 +++++++++++++-
 1 file changed, 13 insertions(+), 1 deletion(-)

From: Ridong Chen <[email protected]>

As Qi mentioned [1], when swappiness=max (SWAPPINESS_ANON_ONLY) is set, the reclaim logic is expected to reclaim anonymous pages exclusively. However, due to the current ordering of checks in get_scan_count(), file pages may still be evicted if can_reclaim_anon_pages() returns false, which contradicts the semantics of SWAPPINESS_ANON_ONLY.

Reproducer in a cgroup holding 64M of file cache, with no swap configured:

Before (file cache is wrongly evicted):

     # cat memory.stat
     anon 196608
     file 67178496
     pgscan_proactive 0
     # echo "64M swappiness=max" > memory.reclaim
     # cat memory.stat
     anon 208896
     file 4096                 <- page cache evicted
     pgsteal_proactive 16400
     pgscan_proactive 16400

After (file cache is left intact):

     # cat memory.stat
     anon 200704
     file 67178496
     pgscan_proactive 0
     # echo "64M swappiness=max" > memory.reclaim
     -bash: echo: write error: Resource temporarily unavailable
     # cat memory.stat
     anon 208896
     file 67178496             <- page cache untouched
     pgsteal_proactive 0
     pgscan_proactive 0

Fix this by bailing out early when SWAPPINESS_ANON_ONLY is set and no anonymous pages are reclaimable, before falling back to file reclaim.

[1] https://lore.kernel.org/cgroups/[email protected]/

Fixes 68a1436bde00 ("mm: add swappiness=max arg to memory.reclaim for only anon reclaim")

Suggested-by Qi Zheng <[email protected]>

Acked-by Shakeel Butt <[email protected]>

Acked-by Johannes Weiner <[email protected]>

Reviewed-by Muchun Song <[email protected]>

Signed-off-by Ridong Chen <[email protected]>

---
  mm/vmscan.c | 18 +++++++++++-------
  1 file changed, 11 insertions(+), 7 deletions(-)

mm/vmscan.c +11 -7

index 35c3bb15ae96..d6b383d96a0c 100644
@@ -2501,6 +2501,17 @@ static void get_scan_count(struct lruvec *lruvec, struct scan_control *sc,
  	enum scan_balance scan_balance;
  	enum lru_list lru;
 
+	/* Proactive reclaim initiated by userspace for anonymous memory only */
+	if (swappiness == SWAPPINESS_ANON_ONLY) {
+		WARN_ON_ONCE(!sc->proactive);
+		if (!can_reclaim_anon_pages(memcg, pgdat->node_id, sc)) {
+			memset(nr, 0, sizeof(*nr) * NR_LRU_LISTS);
+			return;
+		}
+		scan_balance = SCAN_ANON;
+		goto out;
+	}
+
  	/* If we have no swap space, do not bother scanning anon folios. */
  	if (!sc->may_swap || !can_reclaim_anon_pages(memcg, pgdat->node_id, sc)) {
  		scan_balance = SCAN_FILE;

@@ -2519,13 +2530,6 @@ static void get_scan_count(struct lruvec *lruvec, struct scan_control *sc,
  		goto out;
  	}
 
-	/* Proactive reclaim initiated by userspace for anonymous memory only */
-	if (swappiness == SWAPPINESS_ANON_ONLY) {
-		WARN_ON_ONCE(!sc->proactive);
-		scan_balance = SCAN_ANON;
-		goto out;
-	}
-
  	/*
  	 * Do not apply any pressure balancing cleverness when the
  	 * system is close to OOM, scan both anon and file equally

From: Ridong Chen <[email protected]>

It has been observed that per-node proactive reclaim always returns -EAGAIN when any error occurs. As discussed in the mailing list [1], the interface should distinguish between cases where no reclaimable memory is left and where another entity is concurrently using the same interface. Propagate the real error code, consistent with how memcg proactive reclaim handles errors.

[1] https://lore.kernel.org/all/20250717235604.2atyx2aobwowpge3@offworld/T/#m3514718be82a31b05726a49da9b61fbfc69a589e

Fixes b980077899ea ("mm: introduce per-node proactive reclaim interface")

Reviewed-by Muchun Song <[email protected]>

Acked-by Johannes Weiner <[email protected]>

Acked-by Shakeel Butt <[email protected]>

Signed-off-by Ridong Chen <[email protected]>

---
  mm/vmscan.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

mm/vmscan.c +0 -0

index d6b383d96a0c..cfe4556c96d7 100644

From: Ridong Chen <[email protected]>

Commit 57972c78e678 ("mm/vmscan: make __node_reclaim() more generic") moved the scan_control construction out to the callers and passed the struct in by pointer. After that change every use of the gfp mask inside __node_reclaim() goes through sc->gfp_mask, leaving the gfp_mask parameter unused. Just remove the dead parameter and update the callers accordingly. No functional change.

Acked-by Shakeel Butt <[email protected]>

Acked-by Johannes Weiner <[email protected]>

Reviewed-by Muchun Song <[email protected]>

Signed-off-by Ridong Chen <[email protected]>

---
  mm/vmscan.c | 9 ++++-----
  1 file changed, 4 insertions(+), 5 deletions(-)

Quoted 3 lines · Ridong Chen

From: Ridong Chen <[email protected]>

Quoted 5 lines

The previous patch fixes this issue for the traditional LRU, which also exists in MGLRU [1]. Fix this by checking whether swappiness is SWAPPINESS_ANON_ONLY in get_swappiness() first, and returning 0 from get_nr_to_scan() when swappiness is SWAPPINESS_ANON_ONLY and anon pages cannot be reclaimed, to avoid useless work.

Is this intended to avoid unnecessary work, or to prevent file folios from being reclaimed incorrectly?

Quoted 41 lines

The test result:
Before fix:

   # cat /sys/kernel/mm/lru_gen/enabled
   0x0007
   # cat memory.stat
   anon 204800
   file 67108864
   ...
   pgsteal_proactive 0
   pgscan_proactive 0

   # echo "64M swappiness=max" > memory.reclaim
   # cat memory.stat
   anon 208896
   file 0
   ...
   pgsteal_proactive 16384
   pgscan_proactive 16384

After fix:

   # cat memory.stat
   anon 188416
   file 67215360
   kernel 1970176
   ...
   pgsteal_proactive 0
   pgscan_proactive 0

   # echo "64M swappiness=max" > memory.reclaim
   -bash: echo: write error: Resource temporarily unavailable
   # cat memory.stat
   anon 204800
   file 67215360
   ...
   pgsteal_proactive 0
   pgscan_proactive 0

Quoted 8 lines

[1] https://sashiko.dev/#/patchset/[email protected]

Fixes 68a1436bde00 ("mm: add swappiness=max arg to memory.reclaim for only anon reclaim")

Signed-off-by Ridong Chen <[email protected]>

---
  mm/vmscan.c | 14 +++++++++++++-
  1 file changed, 13 insertions(+), 1 deletion(-)

Quoted 39 lines · Ridong Chen

From: Ridong Chen <[email protected]>

As Qi mentioned [1], when swappiness=max (SWAPPINESS_ANON_ONLY) is set, the reclaim logic is expected to reclaim anonymous pages exclusively. However, due to the current ordering of checks in get_scan_count(), file pages may still be evicted if can_reclaim_anon_pages() returns false, which contradicts the semantics of SWAPPINESS_ANON_ONLY.

Reproducer in a cgroup holding 64M of file cache, with no swap configured:

Before (file cache is wrongly evicted):

     # cat memory.stat
     anon 196608
     file 67178496
     pgscan_proactive 0
     # echo "64M swappiness=max" > memory.reclaim
     # cat memory.stat
     anon 208896
     file 4096                 <- page cache evicted
     pgsteal_proactive 16400
     pgscan_proactive 16400

After (file cache is left intact):

     # cat memory.stat
     anon 200704
     file 67178496
     pgscan_proactive 0
     # echo "64M swappiness=max" > memory.reclaim
     -bash: echo: write error: Resource temporarily unavailable
     # cat memory.stat
     anon 208896
     file 67178496             <- page cache untouched
     pgsteal_proactive 0
     pgscan_proactive 0

Fix this by bailing out early when SWAPPINESS_ANON_ONLY is set and no anonymous pages are reclaimable, before falling back to file reclaim.

Quoted 8 lines

[1] https://lore.kernel.org/cgroups/[email protected]/

Fixes 68a1436bde00 ("mm: add swappiness=max arg to memory.reclaim for only anon reclaim")

Suggested-by Qi Zheng <[email protected]>

Acked-by Shakeel Butt <[email protected]>

Acked-by Johannes Weiner <[email protected]>

Reviewed-by Muchun Song <[email protected]>

Signed-off-by Ridong Chen <[email protected]>

Reviewed-by Barry Song <[email protected]>

Quoted 12 lines

---
  mm/vmscan.c | 18 +++++++++++-------
  1 file changed, 11 insertions(+), 7 deletions(-)

mm/vmscan.c +0 -0

index 35c3bb15ae96..d6b383d96a0c 100644
@@ -2501,6 +2501,17 @@ static void get_scan_count(struct lruvec *lruvec, struct scan_control *sc,
         enum scan_balance scan_balance;
         enum lru_list lru;
 

mm/vmscan.c static void get_scan_count(struct lruvec *lruvec, struct scan_control *sc, · line 2506

Quoted 3 lines

mm/vmscan.c +3 -0

+       /* Proactive reclaim initiated by userspace for anonymous memory only */
+       if (swappiness == SWAPPINESS_ANON_ONLY) {
+               WARN_ON_ONCE(!sc->proactive);

I feel it's a bit odd that the WARN_ON_ONCE() is placed here. Maybe adding a short comment would make the intent clearer. For example:
"SWAPPINESS_ANON_ONLY is only allowed for proactive reclaim."

I'm not sure whether it would be better to issue this warning earlier, for example in try_to_free_mem_cgroup_pages(). That said, I don't feel strongly about this.

Quoted 4 lines · Barry Song

Quoted 3 lines · Ridong Chen

From: Ridong Chen <[email protected]>

Quoted 8 lines

Quoted 5 lines

The previous patch fixes this issue for the traditional LRU, which also exists in MGLRU [1]. Fix this by checking whether swappiness is SWAPPINESS_ANON_ONLY in get_swappiness() first, and returning 0 from get_nr_to_scan() when swappiness is SWAPPINESS_ANON_ONLY and anon pages cannot be reclaimed, to avoid useless work.

Is this intended to avoid unnecessary work, or to prevent file folios from being reclaimed incorrectly?

Based on the test results below, it seems primarily intended to prevent file pages from being mistakenly reclaimed. Also, bailing out early in the SWAPPINESS_ANON_ONLY + !can_reclaim_anon_pages case is to avoid unnecessary work.

Hi Ridong, perhaps the commit message could be clearer. ;)

Quoted 41 lines

Quoted 41 lines

The test result:
Before fix:

   # cat /sys/kernel/mm/lru_gen/enabled
   0x0007
   # cat memory.stat
   anon 204800
   file 67108864
   ...
   pgsteal_proactive 0
   pgscan_proactive 0

   # echo "64M swappiness=max" > memory.reclaim
   # cat memory.stat
   anon 208896
   file 0
   ...
   pgsteal_proactive 16384
   pgscan_proactive 16384

After fix:

   # cat memory.stat
   anon 188416
   file 67215360
   kernel 1970176
   ...
   pgsteal_proactive 0
   pgscan_proactive 0

   # echo "64M swappiness=max" > memory.reclaim
   -bash: echo: write error: Resource temporarily unavailable
   # cat memory.stat
   anon 204800
   file 67215360
   ...
   pgsteal_proactive 0
   pgscan_proactive 0

Quoted 8 lines

Quoted 8 lines

[1] https://sashiko.dev/#/patchset/20260717113300.214717-1- [email protected]

Fixes 68a1436bde00 ("mm: add swappiness=max arg to memory.reclaim for only anon reclaim")

Signed-off-by Ridong Chen <[email protected]>

---
  mm/vmscan.c | 14 +++++++++++++-

  1 file changed, 13 insertions(+), 1 deletion(-)

Overall, this looks good to me.

Acked-by Qi Zheng <[email protected]>

Thanks,
Qi

From: Ridong Chen <[email protected]>

It has been observed that per-node proactive reclaim always returns -EAGAIN when any error occurs. As discussed in the mailing list [1], the interface should distinguish between cases where no reclaimable memory is left and where another entity is concurrently using the same interface. Propagate the real error code, consistent with how memcg proactive reclaim handles errors.

[1] https://lore.kernel.org/all/20250717235604.2atyx2aobwowpge3@offworld/T/#m3514718be82a31b05726a49da9b61fbfc69a589e

Fixes b980077899ea ("mm: introduce per-node proactive reclaim interface")

Reviewed-by Muchun Song <[email protected]>

Acked-by Johannes Weiner <[email protected]>

Acked-by Shakeel Butt <[email protected]>

Signed-off-by Ridong Chen <[email protected]>

---
 mm/vmscan.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Quoted 6 lines

Quoted 6 lines

mm/vmscan.c +0 -0

@@ -2501,6 +2501,17 @@ static void get_scan_count(struct lruvec *lruvec, struct scan_control *sc,
         enum scan_balance scan_balance;
         enum lru_list lru;
 

Quoted 7 lines

mm/vmscan.c static void get_scan_count(struct lruvec *lruvec, struct scan_control *sc, · line 2506

Quoted 3 lines

mm/vmscan.c +3 -0

+       /* Proactive reclaim initiated by userspace for anonymous memory only */
+       if (swappiness == SWAPPINESS_ANON_ONLY) {
+               WARN_ON_ONCE(!sc->proactive);

I feel it's a bit odd that the WARN_ON_ONCE() is placed here. Maybe adding a short comment would make the intent clearer. For example:
"SWAPPINESS_ANON_ONLY is only allowed for proactive reclaim."

Hi Barry,

I didn't change the original logic in this patch. I agree that adding a comment would help clarify the intent.

I'll include that in the next version.

Quoted 3 lines

I'm not sure whether it would be better to issue this warning earlier, for example in try_to_free_mem_cgroup_pages(). That said, I don't feel strongly about this.

Since patch 4 will address the MGLRU issue and could also include this warning, I think that triggering the warning earlier makes sense and would be more general. Would it be acceptable to add a separate patch (e.g., patch 5) for moving the warning? That way, each patch stays focused on a single logical change.

On Mon, Jul 20, 2026 at 12:43 PM Ridong Chen <[email protected]> wrote:
[...]

Quoted 25 lines

Quoted 6 lines

Quoted 6 lines

mm/vmscan.c +0 -0

@@ -2501,6 +2501,17 @@ static void get_scan_count(struct lruvec *lruvec, struct scan_control *sc,
          enum scan_balance scan_balance;
          enum lru_list lru;
 

Quoted 7 lines

mm/vmscan.c static void get_scan_count(struct lruvec *lruvec, struct scan_control *sc, · line 2506

Quoted 3 lines

mm/vmscan.c +3 -0

+       /* Proactive reclaim initiated by userspace for anonymous memory only */
+       if (swappiness == SWAPPINESS_ANON_ONLY) {
+               WARN_ON_ONCE(!sc->proactive);

I feel it's a bit odd that the WARN_ON_ONCE() is placed here. Maybe adding a short comment would make the intent clearer. For example:
"SWAPPINESS_ANON_ONLY is only allowed for proactive reclaim."

Hi Barry,

I didn't change the original logic in this patch. I agree that adding a comment would help clarify the intent.

I'll include that in the next version.

Quoted 3 lines

I'm not sure whether it would be better to issue this warning earlier, for example in try_to_free_mem_cgroup_pages(). That said, I don't feel strongly about this.

Quoted 5 lines

Since patch 4 will address the MGLRU issue and could also include this warning, I think that triggering the warning earlier makes sense and would be more general. Would it be acceptable to add a separate patch (e.g., patch 5) for moving the warning? That way, each patch stays focused on a single logical change.

I'm not quite sure where the best place would be to move it earlier. We already have two places that perform proactive reclaim:
try_to_free_mem_cgroup_pages() and __node_reclaim(). There are also other reclaim paths that are not proactive. Since they all eventually call shrink_node(), would it make more sense to handle it there?

If we can't find a suitable common path, I guess simply adding some comments to the current patches would be good enough.

Quoted 40 lines · Barry Song

On Mon, Jul 20, 2026 at 12:43 PM Ridong Chen <[email protected]> wrote:
[...]

Quoted 25 lines

Quoted 6 lines

Quoted 6 lines

mm/vmscan.c +0 -0

@@ -2501,6 +2501,17 @@ static void get_scan_count(struct lruvec *lruvec, struct scan_control *sc,
          enum scan_balance scan_balance;
          enum lru_list lru;
 

Quoted 7 lines

mm/vmscan.c static void get_scan_count(struct lruvec *lruvec, struct scan_control *sc, · line 2506

Quoted 3 lines

mm/vmscan.c +3 -0

+       /* Proactive reclaim initiated by userspace for anonymous memory only */
+       if (swappiness == SWAPPINESS_ANON_ONLY) {
+               WARN_ON_ONCE(!sc->proactive);

I feel it's a bit odd that the WARN_ON_ONCE() is placed here. Maybe adding a short comment would make the intent clearer. For example:
"SWAPPINESS_ANON_ONLY is only allowed for proactive reclaim."

Hi Barry,

I didn't change the original logic in this patch. I agree that adding a comment would help clarify the intent.

I'll include that in the next version.

Quoted 3 lines

I'm not sure whether it would be better to issue this warning earlier, for example in try_to_free_mem_cgroup_pages(). That said, I don't feel strongly about this.

Quoted 5 lines

Since patch 4 will address the MGLRU issue and could also include this warning, I think that triggering the warning earlier makes sense and would be more general. Would it be acceptable to add a separate patch (e.g., patch 5) for moving the warning? That way, each patch stays focused on a single logical change.

I'm not quite sure where the best place would be to move it earlier. We already have two places that perform proactive reclaim:
try_to_free_mem_cgroup_pages() and __node_reclaim(). There are also other reclaim paths that are not proactive. Since they all eventually call shrink_node(), would it make more sense to handle it there?

Quoted 3 lines

If we can't find a suitable common path, I guess simply adding some comments to the current patches would be good enough.

Eh, shrink_node handles MGLRU global reclaim via a special branch, so we'd have to add the warning at the beginning of shrink_node, but that feels a bit jarring. Let's just go with adding some comments instead.