[PATCH v4 0/2] mm/swap: skip empty clusters in the swapoff scan

Youngjun Park posted 2 patches 2 weeks, 2 days ago
include/linux/swap.h |  2 +-
mm/swapfile.c        | 43 ++++++++++++++++++++++++++++++-------------
2 files changed, 31 insertions(+), 14 deletions(-)
[PATCH v4 0/2] mm/swap: skip empty clusters in the swapoff scan
Posted by Youngjun Park 2 weeks, 2 days ago
find_next_to_unuse() walks a swap device one offset at a time.  Slot
state now lives in a per cluster swap table, so patch 2 dismisses an
empty cluster with one counter read instead of SWAPFILE_CLUSTER table
reads.

Patch 1 is an unrelated one line comment fix noticed on the way.

A debug test confirmed the skip path runs, and swapoff completed
under load with no DEBUG_VM or lockdep splats.

Changes in v4:
- 2/2: put the measured swapoff times in the changelog (Andrew)
- 2/2: pick up Kairui's Acked-by and Baoquan's Reviewed-by
- Rebased on mm-new
- Link to v3: https://lore.kernel.org/r/20260806193228.458685-1-youngjun.park@lge.com

Changes in v3:
- 2/2: clamp the scan end with min_t() so it stops at si->max, rather
  than running into the masked tail of the last cluster, which drops the
  need to explain why walking that tail was safe (Barry)
- 2/2: compute ci_off only where it is used
- 1/2, 2/2: pick up Barry's Reviewed-by
- Rebased on mm-new
- Link to v2: https://lore.kernel.org/r/20260805141146.127776-1-youngjun.park@lge.com

Youngjun Park (2):
  mm/swap: fix stale comment on swap_info_struct::cluster_info
  mm/swap: scan by cluster in find_next_to_unuse()

 include/linux/swap.h |  2 +-
 mm/swapfile.c        | 43 ++++++++++++++++++++++++++++++-------------
 2 files changed, 31 insertions(+), 14 deletions(-)


base-commit: 0bffe67ab8a72b3725cc31c4b525709bd3a3e223
-- 
2.48.1
Re: [PATCH v4 0/2] mm/swap: skip empty clusters in the swapoff scan
Posted by Andrew Morton 2 weeks, 1 day ago
On Thu, 10 Sep 2026 01:15:50 +0900 Youngjun Park <youngjun.park@lge.com> wrote:

> find_next_to_unuse() walks a swap device one offset at a time.  Slot
> state now lives in a per cluster swap table, so patch 2 dismisses an
> empty cluster with one counter read instead of SWAPFILE_CLUSTER table
> reads.
> 
> Patch 1 is an unrelated one line comment fix noticed on the way.
> 
> A debug test confirmed the skip path runs, and swapoff completed
> under load with no DEBUG_VM or lockdep splats.

Please let's try to make the [0/N] words provide a summary of the
patchset's effects.  The above didn't even tell people that this is a
swapoff optimization!

I asked an LLM for this summary and we came up with

:  Speed up swapoff and reduce scanning stalls on large, mostly empty
:  swap devices by skipping empty clusters.  Reduce swapoff time on a 1
:  TiB device from 158 ms to 94 ms after filling 128 GiB, and from 392
:  ms to 73 ms after filling 512 GiB; expect little benefit when
:  substantial swap data remains.

Does that sound OK?
Re: [PATCH v4 0/2] mm/swap: skip empty clusters in the swapoff scan
Posted by Youngjun Park 2 weeks, 1 day ago
On Wed, Sep 09, 2026 at 10:49:39AM -0700, Andrew Morton wrote:
> On Thu, 10 Sep 2026 01:15:50 +0900 Youngjun Park <youngjun.park@lge.com> wrote:
> 
> > find_next_to_unuse() walks a swap device one offset at a time.  Slot
> > state now lives in a per cluster swap table, so patch 2 dismisses an
> > empty cluster with one counter read instead of SWAPFILE_CLUSTER table
> > reads.
> > 
> > Patch 1 is an unrelated one line comment fix noticed on the way.
> > 
> > A debug test confirmed the skip path runs, and swapoff completed
> > under load with no DEBUG_VM or lockdep splats.
> 
> Please let's try to make the [0/N] words provide a summary of the
> patchset's effects.  The above didn't even tell people that this is a
> swapoff optimization!

Hello Andrew.

I will keep in mind, Thank you for pointing it out.

> I asked an LLM for this summary and we came up with
> 
> :  Speed up swapoff and reduce scanning stalls on large, mostly empty
> :  swap devices by skipping empty clusters.  Reduce swapoff time on a 1
> :  TiB device from 158 ms to 94 ms after filling 128 GiB, and from 392
> :  ms to 73 ms after filling 512 GiB; expect little benefit when
> :  substantial swap data remains.
> 
> Does that sound OK?

Yes, sounds good. summary seems good enough!

Best regards,
Youngjun