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

On Fri, Aug 07, 2026 at 02:42:56PM -0700, Andrew Morton wrote:
> On Fri, 7 Aug 2026 16:42:22 +0800 Baoquan He <[email protected]> wrote:
> 
> > > I have no measured times yet, since that case has to be set up on purpose.
> > > What I did is the arithmetic for the case that skips best,
> > > For example 1T of swap with 256M slots with SWAPFILE_CLUSTER = 512
> > > and everything free but the far end:
> > > 
> > >   - today:          256M table reads
> > >   - with the skip:  512K counter reads
> > 
> > 
> > Maybe just use time to measure swapoff time consuming, just like below
> > as I did on a kvm guest, I guess a bare metal machine with larger system
> > ram could be more obvious?
> > 
> > root@fedora:~# free -h
> >                total        used        free      shared  buff/cache   available
> > Mem:           3.8Gi       181Mi       3.6Gi       924Ki        72Mi       3.7Gi
> > Swap:          2.0Gi        18Mi       2.0Gi
> > root@fedora:~# time swapoff /dev/vdb
> > 
> > real	0m0.101s
> > user	0m0.001s
> > sys	0m0.017s
> > root@fedora:~# swapon /dev/vdb
> > root@fedora:~# time swapoff /dev/vdb
> > 
> > real	0m0.014s
> > user	0m0.003s
> > sys	0m0.001s
> > 
> > Not sure if Andrew is asking for this.
> 
> I think it's helpful to include such info.  The audience for changelogs
> is more than swap developers!  It's also an MM maintainer and -stable
> maintainers and other people who are all wondering "should I backport
> this for my users".  Let's give them the means to determine that.

Hello Andrew Here is the experiment.

7.2-rc5, fill a 1 TiB swap up to some amount, then swapoff.  

What is left sits at the top of what was filled, so every slot below it is free.  
Those entries are in the swap cache and cheap to free, so the search is most of the time.  
In short, best scenario my patch shows improvement.

Medians over 11 pairs at 32 and 128 GiB, 3 pairs at 256 and 512.

      filled          swapoff 
                      old        new     
       32 GiB          92.4ms    66.3ms
      128 GiB         157.6ms    94.4ms
      256 GiB         209.7ms    63.8ms  
      512 GiB         391.8ms    73.4ms   

old grows with how much was filled, new does not.  

In the ordinary case swap still holds real data and swapoff spends its time
reading it back.  I tested 4 GiB on an 8 GiB device, where the scan is 1.4%
of try_to_unuse(), and there is no difference either way. meaning no regression

Thanks!
Youngjun