[PATCH v5 0/5] mm: batch TLB flushing for dirty folios in vmscan

[PATCH v5 0/5] mm: batch TLB flushing for dirty folios in vmscan

[Zhang Peng]

This series introduces batch TLB flushing optimization for dirty folios
during memory reclaim, aiming to reduce IPI overhead on multi-core systems.

Background
----------
Currently, when performing pageout in memory reclaim, try_to_unmap_flush_dirty()
is called for each dirty folio individually. On multi-core systems, this causes
frequent IPIs which can significantly impact performance.

Approach
--------
This patch series accumulates dirty folios into batches and performs a single
TLB flush for the entire batch, rather than flushing for each individual folio.

Changes
-------
Patch 1: Extract the folio activation block at activate_locked into
         folio_activate_locked().
Patch 2: Extract the folio-freeing path (buffer release, lazyfree,
         __remove_mapping, folio_batch drain) into folio_free().
Patch 3: Extract the pageout() dispatch state machine into pageout_one().
Patch 4: Extract the TTU setup and try_to_unmap() block into folio_try_unmap().
Patch 5: Implement batch TLB flushing logic. Dirty folios are accumulated in
         batches and a single TLB flush is performed for each batch before
         calling pageout.

Testing
-------
The benchmark script uses stress-ng to compare TLB shootdown behavior before and
after this patch. It constrains a stress-ng workload via memcg to force reclaim
through shrink_folio_list(), reporting TLB shootdowns and IPIs.

Core benchmark command: stress-ng --vm 16 --vm-bytes 2G --vm-keep --timeout 60

==========================================================================
                 batch_dirty_tlb_flush Benchmark Results
==========================================================================
  Kernel: 7.0.0-rc1+   CPUs: 16
  MemTotal: 31834M   SwapTotal: 8191M
  memcg limit: 512M   alloc: 2G   workers: 16   duration: 60s
--------------------------------------------------------------------------
Metric                 Before        After             Delta (abs / %)
--------------------------------------------------------------------------
bogo ops/s             28238.63      35833.97          +7595.34 (+26.9%)
TLB shootdowns         55428953      17621697          -37807256 (-68.2%)
Function call IPIs     34073695      14498768          -19574927 (-57.4%)
pgscan_anon (pages)    52856224      60252894          7396670 (+14.0%)
pgsteal_anon (pages)   29004962      34054753          5049791 (+17.4%)
--------------------------------------------------------------------------

Suggested-by: Kairui Song <kasong@tencent.com>
Signed-off-by: Zhang Peng <bruzzhang@tencent.com>
---
Changes in v5 (addressing David Hildenbrand's review on v4):
- Patch 1: Drop the nr_pages parameter; use folio_nr_pages() inside
  folio_activate_locked(). Add VM_WARN_ON_ONCE_FOLIO(!folio_test_locked)
  at the top of the function. Turn the VM_BUG_ON_FOLIO(folio_test_active)
  into VM_WARN_ON_ONCE_FOLIO and move it to the top.
- Patch 2: Rename folio_free() to folio_try_reclaim_free() to make the
  reclaim-specific role clear and justify the bool return. Make nr_pages
  const. Add VM_WARN_ON_ONCE_FOLIO(folio_ref_count, folio) at the free_it:
  label. Drop the now-redundant "swapped out as a whole" comment and the
  "else continue" after goto keep_locked.
- Patch 3: Rename pageout_one() to folio_try_pageout() for consistency
  with the other helpers. Fix continuation-line alignment.
- Patch 4: Fix continuation-line alignment.
- Patch 5: Replace the in-place folio_batch_reinit() + walk pattern
  with a plain local array; @fbatch is now only read during the walk
  and cleared once afterwards, so its invariant is never temporarily
  broken. Add a comment documenting why each recheck (writeback, mapped,
  dma_pinned) is required.
- Link to v4: https://lore.kernel.org/r/20260525-batch-tlb-flush-v4-0-83789d6abc00@icloud.com

Changes in v4 (addressing Barry Song's review on v3):
- Drop the "track reclaimed pages in reclaim_stat" patch; keep
  shrink_folio_list() returning nr_reclaimed directly. Avoids touching
  the function signature and its MGLRU evict_folios() and
  reclaim_clean_pages_from_list() callers in this series.
- Rename folio_active_bounce() to folio_activate_locked(). The new name
  reflects the precondition (the folio is locked) that callers care about.
- Split the folio_free()/pageout_one() extraction into two patches;
  make pageout_one() return bool so shrink_folio_list() can see whether
  the folio was reclaimed or kept.
- Move the !folio_mapped() check out of folio_try_unmap() into the
  caller, so folio_try_unmap() is only invoked for mapped folios.
- Link to v3: https://lore.kernel.org/r/20260410-batch-tlb-flush-v3-0-ff0b9d3a351a@icloud.com

Changes in v3:
- Patch 5: Replace folio_test_lru() condition check with
  VM_WARN_ON_FOLIO assertion, as PG_lru should never be set for
  isolated folios
- Patch 5: Add comment explaining folio_batch reuse-in-place
  technique in pageout_batch()
- Patch 5: Rewrite comment above folio_unlock() to explain why the
  folio is unlocked while batching
- Link to v2: https://lore.kernel.org/r/20260326-batch-tlb-flush-v2-0-403e523325c4@icloud.com

Changes in v2:
- Fix incorrect comment about page_ref_freeze
- Add folio_maybe_dma_pinned() check in pageout_batch()
- Link to v1: https://lore.kernel.org/r/20260309-batch-tlb-flush-v1-0-eb8fed7d1a9e@icloud.com

---
Zhang Peng (5):
      mm/vmscan: introduce folio_activate_locked() helper
      mm/vmscan: extract folio_free() from shrink_folio_list()
      mm/vmscan: extract pageout_one() from shrink_folio_list()
      mm/vmscan: extract folio unmap logic into folio_try_unmap()
      mm/vmscan: flush TLB for every 31 folios evictions

 mm/vmscan.c | 455 ++++++++++++++++++++++++++++++++++++++----------------------
 1 file changed, 293 insertions(+), 162 deletions(-)
---
base-commit: d0b709f436b2788a10407624688ab8327c5ce18d
change-id: 20260309-batch-tlb-flush-893f0e56b496

Best regards,
-- 
Zhang Peng <zippermonkey@icloud.com>

[PATCH v5 1/5] mm/vmscan: introduce folio_activate_locked() helper

[Zhang Peng]

The activate_locked label in shrink_folio_list() reclaims swap cache
when needed, marks the folio active, and updates activation statistics.
Extract this block into folio_activate_locked() so it can be reused.

No functional change.

Signed-off-by: Zhang Peng <bruzzhang@tencent.com>
---
 mm/vmscan.c | 38 +++++++++++++++++++++++++++-----------
 1 file changed, 27 insertions(+), 11 deletions(-)

diff --git a/mm/vmscan.c b/mm/vmscan.c
index ca4533eba701..5ba880dce21e 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -1050,6 +1050,32 @@ static bool may_enter_fs(struct folio *folio, gfp_t gfp_mask)
 	return !data_race(folio_swap_flags(folio) & SWP_FS_OPS);
 }
 
+/*
+ * Prepare a locked folio to be kept active rather than reclaimed.
+ * Reclaims its swap slot if it will not be swapped, then marks it
+ * active and updates activation statistics.
+ */
+static void folio_activate_locked(struct folio *folio,
+		struct reclaim_stat *stat)
+{
+	unsigned int nr_pages = folio_nr_pages(folio);
+
+	VM_WARN_ON_ONCE_FOLIO(!folio_test_locked(folio), folio);
+	VM_WARN_ON_ONCE_FOLIO(folio_test_active(folio), folio);
+
+	/* Not a candidate for swapping, so reclaim swap space. */
+	if (folio_test_swapcache(folio) &&
+	    (mem_cgroup_swap_full(folio) || folio_test_mlocked(folio)))
+		folio_free_swap(folio);
+	if (!folio_test_mlocked(folio)) {
+		int type = folio_is_file_lru(folio);
+
+		folio_set_active(folio);
+		stat->nr_activate[type] += nr_pages;
+		count_memcg_folio_events(folio, PGACTIVATE, nr_pages);
+	}
+}
+
 /*
  * shrink_folio_list() returns the number of reclaimed pages
  */
@@ -1525,17 +1551,7 @@ static unsigned int shrink_folio_list(struct list_head *folio_list,
 			nr_pages = 1;
 		}
 activate_locked:
-		/* Not a candidate for swapping, so reclaim swap space. */
-		if (folio_test_swapcache(folio) &&
-		    (mem_cgroup_swap_full(folio) || folio_test_mlocked(folio)))
-			folio_free_swap(folio);
-		VM_BUG_ON_FOLIO(folio_test_active(folio), folio);
-		if (!folio_test_mlocked(folio)) {
-			int type = folio_is_file_lru(folio);
-			folio_set_active(folio);
-			stat->nr_activate[type] += nr_pages;
-			count_memcg_folio_events(folio, PGACTIVATE, nr_pages);
-		}
+		folio_activate_locked(folio, stat);
 keep_locked:
 		folio_unlock(folio);
 keep:

-- 
2.43.7

[PATCH v5 2/5] mm/vmscan: extract folio_free() from shrink_folio_list()

[Zhang Peng]

shrink_folio_list() contains a self-contained folio-freeing section:
buffer release, lazyfree, __remove_mapping, and folio_batch drain.
Extract it into folio_free() to reduce the size of shrink_folio_list()
and make the freeing step independently readable.

No functional change.

Signed-off-by: Zhang Peng <bruzzhang@tencent.com>
---
 mm/vmscan.c | 164 +++++++++++++++++++++++++++++++++---------------------------
 1 file changed, 89 insertions(+), 75 deletions(-)

diff --git a/mm/vmscan.c b/mm/vmscan.c
index 5ba880dce21e..a0807dd01c5a 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -1076,6 +1076,93 @@ static void folio_activate_locked(struct folio *folio,
 	}
 }
 
+static bool folio_try_reclaim_free(struct folio *folio,
+		struct folio_batch *free_folios,
+		struct scan_control *sc, struct reclaim_stat *stat,
+		unsigned int *nr_reclaimed)
+{
+	const unsigned int nr_pages = folio_nr_pages(folio);
+	struct address_space *mapping = folio_mapping(folio);
+
+	/*
+	 * If the folio has buffers, try to free the buffer mappings
+	 * associated with this folio. If we succeed we try to free
+	 * the folio as well.
+	 *
+	 * We do this even if the folio is dirty.
+	 * filemap_release_folio() does not perform I/O, but it is
+	 * possible for a folio to have the dirty flag set, but it
+	 * is actually clean (all its buffers are clean).  This
+	 * happens if the buffers were written out directly, with
+	 * submit_bh(). ext3 will do this, as well as the blockdev
+	 * mapping.  filemap_release_folio() will discover that
+	 * cleanness and will drop the buffers and mark the folio
+	 * clean - it can be freed.
+	 *
+	 * Rarely, folios can have buffers and no ->mapping.  These
+	 * are the folios which were not successfully invalidated in
+	 * truncate_cleanup_folio().  We try to drop those buffers
+	 * here and if that worked, and the folio is no longer
+	 * mapped into process address space (refcount == 1) it can
+	 * be freed.  Otherwise, leave the folio on the LRU so it is
+	 * swappable.
+	 */
+	if (folio_needs_release(folio)) {
+		if (!filemap_release_folio(folio, sc->gfp_mask)) {
+			folio_activate_locked(folio, stat);
+			return false;
+		}
+
+		if (!mapping && folio_ref_count(folio) == 1) {
+			folio_unlock(folio);
+			if (folio_put_testzero(folio))
+				goto free_it;
+			else {
+				/*
+				 * rare race with speculative reference.
+				 * the speculative reference will free
+				 * this folio shortly, so we may
+				 * increment nr_reclaimed here (and
+				 * leave it off the LRU).
+				 */
+				*nr_reclaimed += nr_pages;
+				return true;
+			}
+		}
+	}
+
+	if (folio_test_lazyfree(folio)) {
+		/* follow __remove_mapping for reference */
+		if (!folio_ref_freeze(folio, 1))
+			return false;
+		/*
+		 * The folio has only one reference left, which is
+		 * from the isolation. After the caller puts the
+		 * folio back on the lru and drops the reference, the
+		 * folio will be freed anyway. It doesn't matter
+		 * which lru it goes on. So we don't bother checking
+		 * the dirty flag here.
+		 */
+		count_vm_events(PGLAZYFREED, nr_pages);
+		count_memcg_folio_events(folio, PGLAZYFREED, nr_pages);
+	} else if (!mapping || !__remove_mapping(mapping, folio, true,
+							sc->target_mem_cgroup))
+		return false;
+
+	folio_unlock(folio);
+free_it:
+	VM_WARN_ON_ONCE_FOLIO(folio_ref_count(folio), folio);
+	*nr_reclaimed += nr_pages;
+
+	folio_unqueue_deferred_split(folio);
+	if (folio_batch_add(free_folios, folio) == 0) {
+		mem_cgroup_uncharge_folios(free_folios);
+		try_to_unmap_flush();
+		free_unref_folios(free_folios);
+	}
+	return true;
+}
+
 /*
  * shrink_folio_list() returns the number of reclaimed pages
  */
@@ -1463,82 +1550,9 @@ static unsigned int shrink_folio_list(struct list_head *folio_list,
 			}
 		}
 
-		/*
-		 * If the folio has buffers, try to free the buffer
-		 * mappings associated with this folio. If we succeed
-		 * we try to free the folio as well.
-		 *
-		 * We do this even if the folio is dirty.
-		 * filemap_release_folio() does not perform I/O, but it
-		 * is possible for a folio to have the dirty flag set,
-		 * but it is actually clean (all its buffers are clean).
-		 * This happens if the buffers were written out directly,
-		 * with submit_bh(). ext3 will do this, as well as
-		 * the blockdev mapping.  filemap_release_folio() will
-		 * discover that cleanness and will drop the buffers
-		 * and mark the folio clean - it can be freed.
-		 *
-		 * Rarely, folios can have buffers and no ->mapping.
-		 * These are the folios which were not successfully
-		 * invalidated in truncate_cleanup_folio().  We try to
-		 * drop those buffers here and if that worked, and the
-		 * folio is no longer mapped into process address space
-		 * (refcount == 1) it can be freed.  Otherwise, leave
-		 * the folio on the LRU so it is swappable.
-		 */
-		if (folio_needs_release(folio)) {
-			if (!filemap_release_folio(folio, sc->gfp_mask))
-				goto activate_locked;
-			if (!mapping && folio_ref_count(folio) == 1) {
-				folio_unlock(folio);
-				if (folio_put_testzero(folio))
-					goto free_it;
-				else {
-					/*
-					 * rare race with speculative reference.
-					 * the speculative reference will free
-					 * this folio shortly, so we may
-					 * increment nr_reclaimed here (and
-					 * leave it off the LRU).
-					 */
-					nr_reclaimed += nr_pages;
-					continue;
-				}
-			}
-		}
-
-		if (folio_test_lazyfree(folio)) {
-			/* follow __remove_mapping for reference */
-			if (!folio_ref_freeze(folio, 1))
-				goto keep_locked;
-			/*
-			 * The folio has only one reference left, which is
-			 * from the isolation. After the caller puts the
-			 * folio back on the lru and drops the reference, the
-			 * folio will be freed anyway. It doesn't matter
-			 * which lru it goes on. So we don't bother checking
-			 * the dirty flag here.
-			 */
-			count_vm_events(PGLAZYFREED, nr_pages);
-			count_memcg_folio_events(folio, PGLAZYFREED, nr_pages);
-		} else if (!mapping || !__remove_mapping(mapping, folio, true,
-							 sc->target_mem_cgroup))
+		if (!folio_try_reclaim_free(folio, &free_folios, sc, stat,
+					   &nr_reclaimed))
 			goto keep_locked;
-
-		folio_unlock(folio);
-free_it:
-		/*
-		 * Folio may get swapped out as a whole, need to account
-		 * all pages in it.
-		 */
-		nr_reclaimed += nr_pages;
-
-		folio_unqueue_deferred_split(folio);
-		if (folio_batch_add(&free_folios, folio) == 0) {
-			mem_cgroup_uncharge_folios(&free_folios);
-			try_to_unmap_flush();
-			free_unref_folios(&free_folios);
-		}
 		continue;
 
 activate_locked_split:

-- 
2.43.7

[PATCH v5 3/5] mm/vmscan: extract pageout_one() from shrink_folio_list()

[Zhang Peng]

shrink_folio_list() contains a self-contained pageout() dispatch state
machine. Extract it into pageout_one() to reduce the size of
shrink_folio_list() and make the pageout step independently readable.

No functional change.

Signed-off-by: Zhang Peng <bruzzhang@tencent.com>
---
 mm/vmscan.c | 104 ++++++++++++++++++++++++++++++++++++------------------------
 1 file changed, 62 insertions(+), 42 deletions(-)

diff --git a/mm/vmscan.c b/mm/vmscan.c
index a0807dd01c5a..3e18948e90d1 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -1163,8 +1163,65 @@ static bool folio_try_reclaim_free(struct folio *folio,
 	return true;
 }
 
+static bool folio_try_pageout(struct folio *folio,
+		struct folio_batch *free_folios,
+		struct scan_control *sc, struct reclaim_stat *stat,
+		struct swap_iocb **plug, struct list_head *folio_list,
+		unsigned int *nr_reclaimed)
+{
+	struct address_space *mapping = folio_mapping(folio);
+	unsigned int nr_pages = folio_nr_pages(folio);
+
+	switch (pageout(folio, mapping, plug, folio_list)) {
+	case PAGE_ACTIVATE:
+		/*
+		 * If shmem folio is split when writeback to swap, the
+		 * tail pages will make their own pass through this
+		 * function and be accounted then.
+		 */
+		if (nr_pages > 1 && !folio_test_large(folio))
+			sc->nr_scanned -= (nr_pages - 1);
+		folio_activate_locked(folio, stat);
+		folio_unlock(folio);
+		return false;
+	case PAGE_KEEP:
+		folio_unlock(folio);
+		return false;
+	case PAGE_SUCCESS:
+		if (nr_pages > 1 && !folio_test_large(folio)) {
+			sc->nr_scanned -= (nr_pages - 1);
+			nr_pages = 1;
+		}
+		stat->nr_pageout += nr_pages;
+
+		if (folio_test_writeback(folio))
+			return false;
+		if (folio_test_dirty(folio))
+			return false;
+
+		/*
+		 * A synchronous write - probably a ramdisk.  Go ahead
+		 * and try to reclaim the folio.
+		 */
+		if (!folio_trylock(folio))
+			return false;
+		if (folio_test_dirty(folio) ||
+		    folio_test_writeback(folio)) {
+			folio_unlock(folio);
+			return false;
+		}
+		fallthrough;
+	case PAGE_CLEAN:
+		; /* try to free the folio below */
+	}
+	if (folio_try_reclaim_free(folio, free_folios, sc, stat, nr_reclaimed))
+		return true;
+	folio_unlock(folio);
+	return false;
+}
+
 /*
- * shrink_folio_list() returns the number of reclaimed pages
+ * Reclaimed folios are counted in the return value.
  */
 static unsigned int shrink_folio_list(struct list_head *folio_list,
 		struct pglist_data *pgdat, struct scan_control *sc,
@@ -1501,53 +1558,16 @@ static unsigned int shrink_folio_list(struct list_head *folio_list,
 				goto keep_locked;
 			if (!sc->may_writepage)
 				goto keep_locked;
-
 			/*
 			 * Folio is dirty. Flush the TLB if a writable entry
 			 * potentially exists to avoid CPU writes after I/O
 			 * starts and then write it out here.
 			 */
 			try_to_unmap_flush_dirty();
-			switch (pageout(folio, mapping, &plug, folio_list)) {
-			case PAGE_KEEP:
-				goto keep_locked;
-			case PAGE_ACTIVATE:
-				/*
-				 * If shmem folio is split when writeback to swap,
-				 * the tail pages will make their own pass through
-				 * this function and be accounted then.
-				 */
-				if (nr_pages > 1 && !folio_test_large(folio)) {
-					sc->nr_scanned -= (nr_pages - 1);
-					nr_pages = 1;
-				}
-				goto activate_locked;
-			case PAGE_SUCCESS:
-				if (nr_pages > 1 && !folio_test_large(folio)) {
-					sc->nr_scanned -= (nr_pages - 1);
-					nr_pages = 1;
-				}
-				stat->nr_pageout += nr_pages;
-
-				if (folio_test_writeback(folio))
-					goto keep;
-				if (folio_test_dirty(folio))
-					goto keep;
-
-				/*
-				 * A synchronous write - probably a ramdisk.  Go
-				 * ahead and try to reclaim the folio.
-				 */
-				if (!folio_trylock(folio))
-					goto keep;
-				if (folio_test_dirty(folio) ||
-				    folio_test_writeback(folio))
-					goto keep_locked;
-				mapping = folio_mapping(folio);
-				fallthrough;
-			case PAGE_CLEAN:
-				; /* try to free the folio below */
-			}
+			if (!folio_try_pageout(folio, &free_folios, sc, stat,
+					      &plug, folio_list, &nr_reclaimed))
+				goto keep;
+			continue;
 		}
 
 		if (!folio_try_reclaim_free(folio, &free_folios, sc, stat,

-- 
2.43.7

[PATCH v5 4/5] mm/vmscan: extract folio unmap logic into folio_try_unmap()

[Zhang Peng]

shrink_folio_list() contains a self-contained block that sets up
TTU flags and calls try_to_unmap(), accounting for failures via
reclaim_stat. Extract it into folio_try_unmap() to reduce the size
of shrink_folio_list() and make the unmap step independently readable.

folio_try_unmap() is only called when the folio is actually mapped;
the !folio_mapped() check stays in the caller, keeping the function's
semantics clear: it tries to unmap a mapped folio and returns whether
the unmap succeeded.

No functional change.

Signed-off-by: Zhang Peng <bruzzhang@tencent.com>
---
 mm/vmscan.c | 65 +++++++++++++++++++++++++++++++++----------------------------
 1 file changed, 35 insertions(+), 30 deletions(-)

diff --git a/mm/vmscan.c b/mm/vmscan.c
index 3e18948e90d1..bb479ead1ee0 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -1220,6 +1220,38 @@ static bool folio_try_pageout(struct folio *folio,
 	return false;
 }
 
+static bool folio_try_unmap(struct folio *folio, struct reclaim_stat *stat,
+		unsigned int nr_pages)
+{
+	enum ttu_flags flags = TTU_BATCH_FLUSH;
+	const bool was_swapbacked = folio_test_swapbacked(folio);
+
+	if (folio_test_pmd_mappable(folio))
+		flags |= TTU_SPLIT_HUGE_PMD;
+	/*
+	 * Without TTU_SYNC, try_to_unmap will only begin to hold PTL
+	 * from the first present PTE within a large folio. Some
+	 * initial PTEs might be skipped due to races with parallel
+	 * PTE writes in which PTEs can be cleared temporarily before
+	 * being written new present values. This will lead to a large
+	 * folio is still mapped while some subpages have been
+	 * partially unmapped after try_to_unmap; TTU_SYNC helps
+	 * try_to_unmap acquire PTL from the first PTE, eliminating the
+	 * influence of temporary PTE values.
+	 */
+	if (folio_test_large(folio))
+		flags |= TTU_SYNC;
+
+	try_to_unmap(folio, flags);
+	if (folio_mapped(folio)) {
+		stat->nr_unmap_fail += nr_pages;
+		if (!was_swapbacked && folio_test_swapbacked(folio))
+			stat->nr_lazyfree_fail += nr_pages;
+		return false;
+	}
+	return true;
+}
+
 /*
  * Reclaimed folios are counted in the return value.
  */
@@ -1494,36 +1526,9 @@ static unsigned int shrink_folio_list(struct list_head *folio_list,
 		 * The folio is mapped into the page tables of one or more
 		 * processes. Try to unmap it here.
 		 */
-		if (folio_mapped(folio)) {
-			enum ttu_flags flags = TTU_BATCH_FLUSH;
-			bool was_swapbacked = folio_test_swapbacked(folio);
-
-			if (folio_test_pmd_mappable(folio))
-				flags |= TTU_SPLIT_HUGE_PMD;
-			/*
-			 * Without TTU_SYNC, try_to_unmap will only begin to
-			 * hold PTL from the first present PTE within a large
-			 * folio. Some initial PTEs might be skipped due to
-			 * races with parallel PTE writes in which PTEs can be
-			 * cleared temporarily before being written new present
-			 * values. This will lead to a large folio is still
-			 * mapped while some subpages have been partially
-			 * unmapped after try_to_unmap; TTU_SYNC helps
-			 * try_to_unmap acquire PTL from the first PTE,
-			 * eliminating the influence of temporary PTE values.
-			 */
-			if (folio_test_large(folio))
-				flags |= TTU_SYNC;
-
-			try_to_unmap(folio, flags);
-			if (folio_mapped(folio)) {
-				stat->nr_unmap_fail += nr_pages;
-				if (!was_swapbacked &&
-				    folio_test_swapbacked(folio))
-					stat->nr_lazyfree_fail += nr_pages;
-				goto activate_locked;
-			}
-		}
+		if (folio_mapped(folio) &&
+		    !folio_try_unmap(folio, stat, nr_pages))
+			goto activate_locked;
 
 		/*
 		 * Folio is unmapped now so it cannot be newly pinned anymore.

-- 
2.43.7

[PATCH v5 5/5] mm/vmscan: flush TLB for every 31 folios evictions

[Zhang Peng]

Currently we flush TLB for every dirty folio, which is a bottleneck for
systems with many cores as this causes heavy IPI usage.

So instead, batch the folios, and flush once for every 31 folios (one
folio_batch). These folios will be held in a folio_batch with their lock
released, then when the folio_batch is full, do the following steps:

  - For each folio: trylock - recheck still evictable (writeback, mapped,
    dma_pinned). If no longer evictable, put back via ret_folios.
  - Flush TLB once for the whole batch.
  - Pageout each survivor via folio_try_pageout().

The recheck step is required because dropping the folio lock between
shrink_folio_list() and pageout_batch() opens a window in which a
parallel swapin (do_swap_page) can fully complete and install a new PTE;
once mapped, a parallel GUP can pin the folio without taking the folio
lock. Folios caught by any of these checks are put back via ret_folios.

Suggested-by: Kairui Song <kasong@tencent.com>
Signed-off-by: Zhang Peng <bruzzhang@tencent.com>
---
 mm/vmscan.c | 92 +++++++++++++++++++++++++++++++++++++++++++++++++++++++------
 1 file changed, 84 insertions(+), 8 deletions(-)

diff --git a/mm/vmscan.c b/mm/vmscan.c
index bb479ead1ee0..251535613336 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -1220,6 +1220,71 @@ static bool folio_try_pageout(struct folio *folio,
 	return false;
 }
 
+static void pageout_batch(struct folio_batch *fbatch,
+			  struct list_head *ret_folios,
+			  struct folio_batch *free_folios,
+			  struct scan_control *sc, struct reclaim_stat *stat,
+			  struct swap_iocb **plug, struct list_head *folio_list,
+			  unsigned int *nr_reclaimed)
+{
+	int i, nr = folio_batch_count(fbatch);
+	int count = 0;
+	struct folio *folios[FOLIO_BATCH_SIZE];
+
+	/*
+	 * Collect survivors into a local array: this avoids walking and
+	 * mutating @fbatch in the same loop, so its invariant (only
+	 * folios[0..nr) are valid) is preserved throughout.
+	 */
+	for (i = 0; i < nr; i++) {
+		struct folio *folio = fbatch->folios[i];
+
+		if (!folio_trylock(folio)) {
+			list_add(&folio->lru, ret_folios);
+			continue;
+		}
+
+		VM_WARN_ON_FOLIO(folio_test_lru(folio), folio);
+
+		/*
+		 * Recheck what shrink_folio_list() verified before dropping
+		 * the folio lock. Between that folio_unlock() and our
+		 * folio_trylock() here, a parallel swapin (do_swap_page) can
+		 * fully complete -- taking the lock, installing a new PTE,
+		 * and releasing the lock -- after which a parallel GUP
+		 * (O_DIRECT, vmsplice, RDMA, ...) can pin the folio through
+		 * that PTE without taking the folio lock. Each flag catches
+		 * one case:
+		 *   folio_test_writeback   -- defensive guard.
+		 *   folio_mapped           -- swapin installed a PTE.
+		 *   folio_maybe_dma_pinned -- GUP pinned through such a PTE.
+		 */
+		if (folio_test_writeback(folio) || folio_mapped(folio) ||
+		    folio_maybe_dma_pinned(folio)) {
+			folio_unlock(folio);
+			list_add(&folio->lru, ret_folios);
+			continue;
+		}
+
+		folios[count++] = folio;	/* keep lock held */
+	}
+	folio_batch_reinit(fbatch);
+
+	if (!count)
+		return;
+
+	/* One TLB flush for the whole batch */
+	try_to_unmap_flush_dirty();
+
+	for (i = 0; i < count; i++) {
+		struct folio *folio = folios[i];
+
+		if (!folio_try_pageout(folio, free_folios, sc, stat, plug,
+				       folio_list, nr_reclaimed))
+			list_add(&folio->lru, ret_folios);
+	}
+}
+
 static bool folio_try_unmap(struct folio *folio, struct reclaim_stat *stat,
 		unsigned int nr_pages)
 {
@@ -1261,6 +1326,7 @@ static unsigned int shrink_folio_list(struct list_head *folio_list,
 		struct mem_cgroup *memcg)
 {
 	struct folio_batch free_folios;
+	struct folio_batch flush_folios;
 	LIST_HEAD(ret_folios);
 	LIST_HEAD(demote_folios);
 	unsigned int nr_reclaimed = 0, nr_demoted = 0;
@@ -1269,6 +1335,7 @@ static unsigned int shrink_folio_list(struct list_head *folio_list,
 	struct swap_iocb *plug = NULL;
 
 	folio_batch_init(&free_folios);
+	folio_batch_init(&flush_folios);
 	memset(stat, 0, sizeof(*stat));
 	cond_resched();
 	do_demote_pass = can_demote(pgdat->node_id, sc, memcg);
@@ -1564,15 +1631,18 @@ static unsigned int shrink_folio_list(struct list_head *folio_list,
 			if (!sc->may_writepage)
 				goto keep_locked;
 			/*
-			 * Folio is dirty. Flush the TLB if a writable entry
-			 * potentially exists to avoid CPU writes after I/O
-			 * starts and then write it out here.
+			 * Drop the lock so swap faults finding this folio
+			 * via swap cache lookup can make progress; the
+			 * recheck that this necessitates is documented in
+			 * pageout_batch().
 			 */
-			try_to_unmap_flush_dirty();
-			if (!folio_try_pageout(folio, &free_folios, sc, stat,
-					      &plug, folio_list, &nr_reclaimed))
-				goto keep;
-			continue;
+			folio_unlock(folio);
+			if (!folio_batch_add(&flush_folios, folio))
+				pageout_batch(&flush_folios,
+					      &ret_folios, &free_folios,
+					      sc, stat, &plug,
+					      folio_list, &nr_reclaimed);
+			goto next;
 		}
 
 		if (!folio_try_reclaim_free(folio, &free_folios, sc, stat,
@@ -1597,6 +1667,12 @@ static unsigned int shrink_folio_list(struct list_head *folio_list,
 		list_add(&folio->lru, &ret_folios);
 		VM_BUG_ON_FOLIO(folio_test_lru(folio) ||
 				folio_test_unevictable(folio), folio);
+next:
+		continue;
+	}
+	if (folio_batch_count(&flush_folios)) {
+		pageout_batch(&flush_folios, &ret_folios, &free_folios, sc,
+			      stat, &plug, folio_list, &nr_reclaimed);
 	}
 	/* 'folio_list' is always empty here */
 

-- 
2.43.7

Re: [PATCH v5 1/5] mm/vmscan: introduce folio_activate_locked() helper

[Barry Song]

On Mon, Jul 20, 2026 at 1:08 PM Zhang Peng <zippermonkey@icloud.com> wrote:
>
> The activate_locked label in shrink_folio_list() reclaims swap cache
> when needed, marks the folio active, and updates activation statistics.
> Extract this block into folio_activate_locked() so it can be reused.
>
> No functional change.
>
> Signed-off-by: Zhang Peng <bruzzhang@tencent.com>

Thanks,

Reviewed-by: Barry Song <baohua@kernel.org>

[...]

> + * Prepare a locked folio to be kept active rather than reclaimed.
> + * Reclaims its swap slot if it will not be swapped, then marks it

I'm not quite sure whether this should be "if". Because, it seems
to always be true up to this point. BTW, if we really want to use
"if", shouldn't we use it to check whether swap is full?

> + * active and updates activation statistics.
> + */
> +static void folio_activate_locked(struct folio *folio,
> +               struct reclaim_stat *stat)
> +{
> +       unsigned int nr_pages = folio_nr_pages(folio);
> +
> +       VM_WARN_ON_ONCE_FOLIO(!folio_test_locked(folio), folio);
> +       VM_WARN_ON_ONCE_FOLIO(folio_test_active(folio), folio);
> +
> +       /* Not a candidate for swapping, so reclaim swap space. */
> +       if (folio_test_swapcache(folio) &&
> +           (mem_cgroup_swap_full(folio) || folio_test_mlocked(folio)))
> +               folio_free_swap(folio);

Best Regards
Barry

Re: [PATCH v5 2/5] mm/vmscan: extract folio_free() from shrink_folio_list()

[Barry Song]

On Mon, Jul 20, 2026 at 1:08 PM Zhang Peng <zippermonkey@icloud.com> wrote:
>
> shrink_folio_list() contains a self-contained folio-freeing section:
> buffer release, lazyfree, __remove_mapping, and folio_batch drain.
> Extract it into folio_free() to reduce the size of shrink_folio_list()
> and make the freeing step independently readable.
>
> No functional change.
>
> Signed-off-by: Zhang Peng <bruzzhang@tencent.com>
> ---
>  mm/vmscan.c | 164 +++++++++++++++++++++++++++++++++---------------------------
>  1 file changed, 89 insertions(+), 75 deletions(-)
>
> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index 5ba880dce21e..a0807dd01c5a 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -1076,6 +1076,93 @@ static void folio_activate_locked(struct folio *folio,
>         }
>  }
>
> +static bool folio_try_reclaim_free(struct folio *folio,
> +               struct folio_batch *free_folios,
> +               struct scan_control *sc, struct reclaim_stat *stat,
> +               unsigned int *nr_reclaimed)
> +{
> +       const unsigned int nr_pages = folio_nr_pages(folio);
> +       struct address_space *mapping = folio_mapping(folio);
> +
> +       /*
> +        * If the folio has buffers, try to free the buffer mappings
> +        * associated with this folio. If we succeed we try to free
> +        * the folio as well.
> +        *
> +        * We do this even if the folio is dirty.
> +        * filemap_release_folio() does not perform I/O, but it is
> +        * possible for a folio to have the dirty flag set, but it
> +        * is actually clean (all its buffers are clean).  This
> +        * happens if the buffers were written out directly, with
> +        * submit_bh(). ext3 will do this, as well as the blockdev
> +        * mapping.  filemap_release_folio() will discover that
> +        * cleanness and will drop the buffers and mark the folio
> +        * clean - it can be freed.
> +        *
> +        * Rarely, folios can have buffers and no ->mapping.  These
> +        * are the folios which were not successfully invalidated in
> +        * truncate_cleanup_folio().  We try to drop those buffers
> +        * here and if that worked, and the folio is no longer
> +        * mapped into process address space (refcount == 1) it can
> +        * be freed.  Otherwise, leave the folio on the LRU so it is
> +        * swappable.
> +        */
> +       if (folio_needs_release(folio)) {
> +               if (!filemap_release_folio(folio, sc->gfp_mask)) {
> +                       folio_activate_locked(folio, stat);

Could we avoid hiding the activate semantics inside
folio_try_reclaim_free()? It makes the logic harder to read and
can be confusing.

Could we pull this out so that the three possible outcomes are
explicit?

1. activate
2. keep
3. free

[...]

> -               } else if (!mapping || !__remove_mapping(mapping, folio, true,
> -                                                        sc->target_mem_cgroup))
> +               if (!folio_try_reclaim_free(folio, &free_folios, sc, stat,
> +                                          &nr_reclaimed))
>                         goto keep_locked;

I mean, this is confusing because an activated folio ends up in the
"keep" path. Can we make the activation semantics explicit at the
outer level?

Best Regards
Barry

Re: [PATCH v5 3/5] mm/vmscan: extract pageout_one() from shrink_folio_list()

[Barry Song]

On Mon, Jul 20, 2026 at 1:08 PM Zhang Peng <zippermonkey@icloud.com> wrote:
>
> shrink_folio_list() contains a self-contained pageout() dispatch state
> machine. Extract it into pageout_one() to reduce the size of
> shrink_folio_list() and make the pageout step independently readable.
>
> No functional change.
>
> Signed-off-by: Zhang Peng <bruzzhang@tencent.com>
> ---
[...]
> +                       if (!folio_try_pageout(folio, &free_folios, sc, stat,
> +                                             &plug, folio_list, &nr_reclaimed))
> +                               goto keep;

Also, this patch looks basically good, just like the previous one.
Could we also avoid hiding the activation semantics in the inner
function? It would be clearer to make the activation semantics
explicit at the outer level, so readers don't have to dig into a
deep internal function to realize that a folio may take the
activation path.

In LRU, we have two distinct possibilities: activate a folio or just
keep it. This is an important semantic distinction in the LRU logic.
Hiding the activation decision so deep in an inner function makes
that semantic much less obvious.

> +                       continue;
>                 }
>
>                 if (!folio_try_reclaim_free(folio, &free_folios, sc, stat,
>

Best Regards
Barry

Re: [PATCH v5 4/5] mm/vmscan: extract folio unmap logic into folio_try_unmap()

[Barry Song]

On Mon, Jul 20, 2026 at 1:08 PM Zhang Peng <zippermonkey@icloud.com> wrote:
>
> shrink_folio_list() contains a self-contained block that sets up
> TTU flags and calls try_to_unmap(), accounting for failures via
> reclaim_stat. Extract it into folio_try_unmap() to reduce the size
> of shrink_folio_list() and make the unmap step independently readable.
>
> folio_try_unmap() is only called when the folio is actually mapped;
> the !folio_mapped() check stays in the caller, keeping the function's
> semantics clear: it tries to unmap a mapped folio and returns whether
> the unmap succeeded.
>
> No functional change.
>
> Signed-off-by: Zhang Peng <bruzzhang@tencent.com>

Reviewed-by: Barry Song <baohua@kernel.org>

Re: [PATCH v5 5/5] mm/vmscan: flush TLB for every 31 folios evictions

[Barry Song]

On Mon, Jul 20, 2026 at 1:08 PM Zhang Peng <zippermonkey@icloud.com> wrote:
>
> Currently we flush TLB for every dirty folio, which is a bottleneck for
> systems with many cores as this causes heavy IPI usage.
>
> So instead, batch the folios, and flush once for every 31 folios (one
> folio_batch). These folios will be held in a folio_batch with their lock
> released, then when the folio_batch is full, do the following steps:
>
>   - For each folio: trylock - recheck still evictable (writeback, mapped,
>     dma_pinned). If no longer evictable, put back via ret_folios.
>   - Flush TLB once for the whole batch.
>   - Pageout each survivor via folio_try_pageout().
>
> The recheck step is required because dropping the folio lock between
> shrink_folio_list() and pageout_batch() opens a window in which a
> parallel swapin (do_swap_page) can fully complete and install a new PTE;
> once mapped, a parallel GUP can pin the folio without taking the folio
> lock. Folios caught by any of these checks are put back via ret_folios.
>
> Suggested-by: Kairui Song <kasong@tencent.com>
> Signed-off-by: Zhang Peng <bruzzhang@tencent.com>

Yes, I think batching the dirty flush is a great idea. I can clearly
see that IPIs for dirty flushes (smp_call) on x86 take up a
significant part of the flame graph when building the kernel in a
memcg, so I think this is something we should pursue.

Could we revisit this patch after we clean up the previous ones?

Best Regards
Barry

Re: [PATCH v5 1/5] mm/vmscan: introduce folio_activate_locked() helper

[Zhang Peng]

On Mon, Aug 10, 2026 at 4:36 PM Barry Song <baohua@kernel.org> wrote:
>
> Reviewed-by: Barry Song <baohua@kernel.org>

Thanks for the review!

> > + * Prepare a locked folio to be kept active rather than reclaimed.
> > + * Reclaims its swap slot if it will not be swapped, then marks it
>
> I'm not quite sure whether this should be "if". Because, it seems
> to always be true up to this point. BTW, if we really want to use
> "if", shouldn't we use it to check whether swap is full?

You're right, the wording was misleading: the condition that actually
guards folio_free_swap() is the swapcache/swap-full/mlocked test right
below it, not anything about whether the folio "will be swapped".

Rather than try to restate that in prose, I dropped the paragraph and
left a single line, since the code below is already explicit:

	/* Activate an isolated, locked folio and account the activation. */
	static void folio_activate_locked(struct folio *folio,
			struct reclaim_stat *stat)

One thing I should flag, since it is not just a comment change: the
VM_BUG_ON_FOLIO(folio_test_active(folio)) that used to sit at the
activate_locked label is now a VM_WARN_ON_ONCE_FOLIO(), so a caller
that gets this wrong is reported rather than taking the machine down.
Both are CONFIG_DEBUG_VM-only, and no non-debug behaviour changes, but
it is a deliberate change rather than a pure move, and the changelog
now says so.

I kept your Reviewed-by on that basis - please let me know if you'd
rather I dropped it, or if you'd prefer the BUG_ON left alone.

This patch is now part of a smaller cleanup-only series, see my reply
on 5/5.

Thanks
Zhang Peng

From nobody Sun Sep 20 00:00:00 2026
From: Zhang Peng <zippermonkey@icloud.com>
To: Barry Song <baohua@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	David Hildenbrand <david@kernel.org>,
	Lorenzo Stoakes <ljs@kernel.org>,
	Vlastimil Babka <vbabka@kernel.org>,
	Mike Rapoport <rppt@kernel.org>,
	Suren Baghdasaryan <surenb@google.com>,
	Michal Hocko <mhocko@suse.com>,
	Michal Hocko <mhocko@kernel.org>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Shakeel Butt <shakeel.butt@linux.dev>,
	Axel Rasmussen <axelrasmussen@google.com>,
	Yuanchu Xie <yuanchu@google.com>,
	Wei Xu <weixugc@google.com>,
	Qi Zheng <qi.zheng@linux.dev>,
	"Liam R. Howlett" <liam@infradead.org>,
	Kairui Song <kasong@tencent.com>,
	Zhang Peng <bruzzhang@tencent.com>,
	linux-mm@kvack.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v5 2/5] mm/vmscan: extract folio_free() from shrink_folio_list()
Date: Sun, 20 Sep 2026 14:14:37 +0800
References: <20260720-batch-tlb-flush-v5-0-db943a0d0d6b@icloud.com>
 <20260720-batch-tlb-flush-v5-2-db943a0d0d6b@icloud.com>
 <CAGsJ_4ykbJKVqEv6uGNKZaQhtV1UxxV-MWt7D1jx6SpdMN+cqA@mail.gmail.com>
In-Reply-To: <CAGsJ_4ykbJKVqEv6uGNKZaQhtV1UxxV-MWt7D1jx6SpdMN+cqA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On Fri, Aug 14, 2026 at 5:40 AM Barry Song <baohua@kernel.org> wrote:
>
> Could we avoid hiding the activate semantics inside
> folio_try_reclaim_free()? It makes the logic harder to read and
> can be confusing.
>
> Could we pull this out so that the three possible outcomes are
> explicit?
>
> 1. activate
> 2. keep
> 3. free
[...]
> I mean, this is confusing because an activated folio ends up in the
> "keep" path. Can we make the activation semantics explicit at the
> outer level?

Agreed, and thanks - the bool return was the root of it. The helper
now returns exactly the three outcomes you listed, and the caller,
not the helper, decides what to do with each:

	enum folio_reclaim_result {
		FOLIO_RECLAIM_KEEP,
		FOLIO_RECLAIM_ACTIVATE,
		FOLIO_RECLAIM_SUCCESS,
	};

	switch (folio_try_reclaim_free(folio, &free_folios, sc,
				       &nr_reclaimed)) {
	case FOLIO_RECLAIM_ACTIVATE:
		goto activate_locked;
	case FOLIO_RECLAIM_KEEP:
		goto keep_locked;
	case FOLIO_RECLAIM_SUCCESS:
		continue;
	}

So there is no longer a folio_activate_locked() call inside the
helper at all, and an activated folio no longer disappears into the
"keep" path.

The patch has been respun on that basis and posted in a cleanup-only
series, see my reply on 5/5.

Thanks
Zhang Peng

From nobody Sun Sep 20 00:00:00 2026
From: Zhang Peng <zippermonkey@icloud.com>
To: Barry Song <baohua@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	David Hildenbrand <david@kernel.org>,
	Lorenzo Stoakes <ljs@kernel.org>,
	Vlastimil Babka <vbabka@kernel.org>,
	Mike Rapoport <rppt@kernel.org>,
	Suren Baghdasaryan <surenb@google.com>,
	Michal Hocko <mhocko@suse.com>,
	Michal Hocko <mhocko@kernel.org>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Shakeel Butt <shakeel.butt@linux.dev>,
	Axel Rasmussen <axelrasmussen@google.com>,
	Yuanchu Xie <yuanchu@google.com>,
	Wei Xu <weixugc@google.com>,
	Qi Zheng <qi.zheng@linux.dev>,
	"Liam R. Howlett" <liam@infradead.org>,
	Kairui Song <kasong@tencent.com>,
	Zhang Peng <bruzzhang@tencent.com>,
	linux-mm@kvack.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v5 3/5] mm/vmscan: extract pageout_one() from shrink_folio_list()
Date: Sun, 20 Sep 2026 14:16:52 +0800
References: <20260720-batch-tlb-flush-v5-0-db943a0d0d6b@icloud.com>
 <20260720-batch-tlb-flush-v5-3-db943a0d0d6b@icloud.com>
 <CAGsJ_4zOfR3Rn5tk_RcOWUDmREO1JyRwXA15Vr3aeUs=+ybMMA@mail.gmail.com>
In-Reply-To: <CAGsJ_4zOfR3Rn5tk_RcOWUDmREO1JyRwXA15Vr3aeUs=+ybMMA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On Fri, Aug 14, 2026 at 5:49 AM Barry Song <baohua@kernel.org> wrote:
>
> Also, this patch looks basically good, just like the previous one.
> Could we also avoid hiding the activation semantics in the inner
> function? It would be clearer to make the activation semantics
> explicit at the outer level, so readers don't have to dig into a
> deep internal function to realize that a folio may take the
> activation path.
>
> In LRU, we have two distinct possibilities: activate a folio or just
> keep it. This is an important semantic distinction in the LRU logic.
> Hiding the activation decision so deep in an inner function makes
> that semantic much less obvious.

Done, same treatment as 2/5 - the helper reports the decision and the
caller acts on it:

	enum folio_pageout_result {
		FOLIO_PAGEOUT_KEEP_LOCKED,
		FOLIO_PAGEOUT_KEEP_UNLOCKED,
		FOLIO_PAGEOUT_ACTIVATE,
		FOLIO_PAGEOUT_FREE,	/* folio is locked, hand it to
					   folio_try_reclaim_free() */
	};

	switch (folio_try_pageout(folio, sc, &ctx, folio_list)) {
	case FOLIO_PAGEOUT_ACTIVATE:
		goto activate_locked;
	case FOLIO_PAGEOUT_KEEP_LOCKED:
		goto keep_locked;
	case FOLIO_PAGEOUT_KEEP_UNLOCKED:
		goto keep;
	case FOLIO_PAGEOUT_FREE:
		break;	/* folio is locked; try to free it below */
	}

Two things beyond what you asked for, both because pageout() has more
outcomes than the freeing path does:

 - "keep" is split into KEEP_LOCKED and KEEP_UNLOCKED. pageout() can
   return with the folio either still locked or already unlocked, and
   previously the caller had to know which internal branch it came
   from to pick between the keep_locked and keep labels. Now the
   result says so.

 - FOLIO_PAGEOUT_FREE keeps the "and now try to free it" step at the
   outer level too, instead of chaining into folio_try_reclaim_free()
   from inside folio_try_pageout().

This patch is in the cleanup-only series, see my reply on 5/5.

Thanks
Zhang Peng

From nobody Sun Sep 20 00:00:00 2026
From: Zhang Peng <zippermonkey@icloud.com>
To: Barry Song <baohua@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	David Hildenbrand <david@kernel.org>,
	Lorenzo Stoakes <ljs@kernel.org>,
	Vlastimil Babka <vbabka@kernel.org>,
	Mike Rapoport <rppt@kernel.org>,
	Suren Baghdasaryan <surenb@google.com>,
	Michal Hocko <mhocko@suse.com>,
	Michal Hocko <mhocko@kernel.org>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Shakeel Butt <shakeel.butt@linux.dev>,
	Axel Rasmussen <axelrasmussen@google.com>,
	Yuanchu Xie <yuanchu@google.com>,
	Wei Xu <weixugc@google.com>,
	Qi Zheng <qi.zheng@linux.dev>,
	"Liam R. Howlett" <liam@infradead.org>,
	Kairui Song <kasong@tencent.com>,
	Zhang Peng <bruzzhang@tencent.com>,
	linux-mm@kvack.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v5 5/5] mm/vmscan: flush TLB for every 31 folios evictions
Date: Sun, 20 Sep 2026 14:19:08 +0800
References: <20260720-batch-tlb-flush-v5-0-db943a0d0d6b@icloud.com>
 <20260720-batch-tlb-flush-v5-5-db943a0d0d6b@icloud.com>
 <CAGsJ_4wrQRGjqavMzWgi2+PrRr1ztf4QRZEb6HKm02OF8nEBUQ@mail.gmail.com>
In-Reply-To: <CAGsJ_4wrQRGjqavMzWgi2+PrRr1ztf4QRZEb6HKm02OF8nEBUQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On Fri, Aug 14, 2026 at 5:58 AM Barry Song <baohua@kernel.org> wrote:
>
> Yes, I think batching the dirty flush is a great idea. I can clearly
> see that IPIs for dirty flushes (smp_call) on x86 take up a
> significant part of the flame graph when building the kernel in a
> memcg, so I think this is something we should pursue. Could we
> revisit this patch after we clean up the previous ones?

Sounds good, and thanks for confirming the workload - useful to know
the dirty-flush IPIs show up that clearly in a memcg kernel build.

I've split the series accordingly. The four cleanup patches, with the
explicit-outcome rework you asked for in 2/5 and 3/5, are posted on
their own as:

  [PATCH 0/4] mm/vmscan: refactor shrink_folio_list()
  https://lore.kernel.org/all/20260920-vmscan-refactor-v1-0-ec04d71cb761@tencent.com/

No functional change intended there. I'll repost the TLB batching on
top once that has settled.

Thanks
Zhang Peng

Re: [PATCH v5 2/5] mm/vmscan: extract folio_free() from shrink_folio_list()

[Zhang Peng]

[Resending this one on its own - my first attempt accidentally sent
all four replies concatenated into a single mail, see
https://lore.kernel.org/all/20260920143816.39827-1-zippermonkey@icloud.com/
Sorry for the noise.]

On Fri, Aug 14, 2026 at 5:40 AM Barry Song <baohua@kernel.org> wrote:
>
> Could we avoid hiding the activate semantics inside
> folio_try_reclaim_free()? It makes the logic harder to read and
> can be confusing.
>
> Could we pull this out so that the three possible outcomes are
> explicit?
>
> 1. activate
> 2. keep
> 3. free
[...]
> I mean, this is confusing because an activated folio ends up in the
> "keep" path. Can we make the activation semantics explicit at the
> outer level?

Agreed, and thanks - the bool return was the root of it. The helper
now returns exactly the three outcomes you listed, and the caller,
not the helper, decides what to do with each:

	enum folio_reclaim_result {
		FOLIO_RECLAIM_KEEP,
		FOLIO_RECLAIM_ACTIVATE,
		FOLIO_RECLAIM_SUCCESS,
	};

	switch (folio_try_reclaim_free(folio, &free_folios, sc,
				       &nr_reclaimed)) {
	case FOLIO_RECLAIM_ACTIVATE:
		goto activate_locked;
	case FOLIO_RECLAIM_KEEP:
		goto keep_locked;
	case FOLIO_RECLAIM_SUCCESS:
		continue;
	}

So there is no longer a folio_activate_locked() call inside the
helper at all, and an activated folio no longer disappears into the
"keep" path.

The patch has been respun on that basis and posted in a cleanup-only
series, see my reply on 5/5.

Thanks
Zhang Peng

Re: [PATCH v5 3/5] mm/vmscan: extract pageout_one() from shrink_folio_list()

[Zhang Peng]

[Resending this one on its own - my first attempt accidentally sent
all four replies concatenated into a single mail, see
https://lore.kernel.org/all/20260920143816.39827-1-zippermonkey@icloud.com/
Sorry for the noise.]

On Fri, Aug 14, 2026 at 5:49 AM Barry Song <baohua@kernel.org> wrote:
>
> Also, this patch looks basically good, just like the previous one.
> Could we also avoid hiding the activation semantics in the inner
> function? It would be clearer to make the activation semantics
> explicit at the outer level, so readers don't have to dig into a
> deep internal function to realize that a folio may take the
> activation path.
>
> In LRU, we have two distinct possibilities: activate a folio or just
> keep it. This is an important semantic distinction in the LRU logic.
> Hiding the activation decision so deep in an inner function makes
> that semantic much less obvious.

Done, same treatment as 2/5 - the helper reports the decision and the
caller acts on it:

	enum folio_pageout_result {
		FOLIO_PAGEOUT_KEEP_LOCKED,
		FOLIO_PAGEOUT_KEEP_UNLOCKED,
		FOLIO_PAGEOUT_ACTIVATE,
		FOLIO_PAGEOUT_FREE,	/* folio is locked, hand it to
					   folio_try_reclaim_free() */
	};

	switch (folio_try_pageout(folio, sc, &ctx, folio_list)) {
	case FOLIO_PAGEOUT_ACTIVATE:
		goto activate_locked;
	case FOLIO_PAGEOUT_KEEP_LOCKED:
		goto keep_locked;
	case FOLIO_PAGEOUT_KEEP_UNLOCKED:
		goto keep;
	case FOLIO_PAGEOUT_FREE:
		break;	/* folio is locked; try to free it below */
	}

Two things beyond what you asked for, both because pageout() has more
outcomes than the freeing path does:

 - "keep" is split into KEEP_LOCKED and KEEP_UNLOCKED. pageout() can
   return with the folio either still locked or already unlocked, and
   previously the caller had to know which internal branch it came
   from to pick between the keep_locked and keep labels. Now the
   result says so.

 - FOLIO_PAGEOUT_FREE keeps the "and now try to free it" step at the
   outer level too, instead of chaining into folio_try_reclaim_free()
   from inside folio_try_pageout().

This patch is in the cleanup-only series, see my reply on 5/5.

Thanks
Zhang Peng

Re: [PATCH v5 5/5] mm/vmscan: flush TLB for every 31 folios evictions

[Zhang Peng]

[Resending this one on its own - my first attempt accidentally sent
all four replies concatenated into a single mail, see
https://lore.kernel.org/all/20260920143816.39827-1-zippermonkey@icloud.com/
Sorry for the noise.]

On Fri, Aug 14, 2026 at 5:58 AM Barry Song <baohua@kernel.org> wrote:
>
> Yes, I think batching the dirty flush is a great idea. I can clearly
> see that IPIs for dirty flushes (smp_call) on x86 take up a
> significant part of the flame graph when building the kernel in a
> memcg, so I think this is something we should pursue. Could we
> revisit this patch after we clean up the previous ones?

Sounds good, and thanks for confirming the workload - useful to know
the dirty-flush IPIs show up that clearly in a memcg kernel build.

I've split the series accordingly. The four cleanup patches, with the
explicit-outcome rework you asked for in 2/5 and 3/5, are posted on
their own as:

  [PATCH 0/4] mm/vmscan: refactor shrink_folio_list()
  https://lore.kernel.org/all/20260920-vmscan-refactor-v1-0-ec04d71cb761@tencent.com/

No functional change intended there. I'll repost the TLB batching on
top once that has settled.

Thanks
Zhang Peng