[PATCH v3 0/2] ext4: fix shrinker scan budget accounting, plus a related cleanup

[Qiliang Yuan]

This revises the ext4_es_scan() shrinker scan-budget fix per review,
and adds a small follow-up cleanup noticed during that review.

Patch 1 simplifies the fix to just returning SHRINK_STOP when
__es_shrink() frees nothing, dropping the sc->nr_scanned computation
entirely (Zhang Yi and Sashiko AI both pointed out it added risk
without a corresponding benefit: do_shrink_slab() discards
sc->nr_scanned on SHRINK_STOP anyway, and computing an accurate but
small nonzero value could reduce the SHRINK_STOP hit rate under light
background load).

Patch 2 removes __es_shrink()'s locked_ei parameter, which Zhang Yi
noted is dead: its sole caller always passes NULL.

Signed-off-by: Qiliang Yuan <odys.yuan@xxxxxxxxx>
---
V2 -> V3:
- Drop the sc->nr_scanned computation entirely; just return
  SHRINK_STOP when __es_shrink() frees nothing (Zhang Yi, Sashiko AI
  review).
- Add patch 2/2: remove the now-dead locked_ei parameter (Zhang Yi).
- Add a Fixes: tag for the commit that split count_objects()/
  scan_objects() apart, and Cc: stable, matching the equivalent jbd2
  fix.
- Re-measure test data against the simplified fix (429 -> 238 calls).

V1 -> V2:
- Correct the comment and commit message: nr_scanned == 0 is not
  only reachable when sbi->s_es_list is genuinely empty, also when
  every inode walked was skipped or had nothing currently
  shrinkable. No code or test data changes.

v2: https://lore.kernel.org/r/20260929-fix-ext4-es-scan-nr-scanned-v2-1-f4e8f6f6b8b1@xxxxxxxxx
v1: https://lore.kernel.org/r/20260928-fix-ext4-es-scan-nr-scanned-v1-1-91d88228b0c8@xxxxxxxxx

---
Qiliang Yuan (2):
      ext4: fix shrinker scan budget accounting in ext4_es_scan()
      ext4: remove unused locked_ei parameter from __es_shrink()

 fs/ext4/extents_status.c | 23 ++++++++++++++---------
 1 file changed, 14 insertions(+), 9 deletions(-)
---
base-commit: 502d801f0ab03e4f32f9a33d203154ce84887921
change-id: 20260928-fix-ext4-es-scan-nr-scanned-5af70744f6cd

Best regards,
-- 
Qiliang Yuan <odys.yuan@xxxxxxxxx>