From: Baoquan He <baoquan.he@linux.dev>
To: Youngjun Park <youngjun.park@lge.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Chris Li <chrisl@kernel.org>, Kairui Song <kasong@tencent.com>,
Kemeng Shi <shikemeng@huaweicloud.com>,
Nhat Pham <nphamcs@gmail.com>, Barry Song <baohua@kernel.org>,
her0gyugyu@gmail.com, linux-mm@kvack.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 0/2] mm/swap: skip empty clusters in the swapoff scan
Date: Fri, 7 Aug 2026 16:42:22 +0800 [thread overview]
Message-ID: <anWabobwPyAXvRe5@MiWiFi-R3L-srv> (raw)
In-Reply-To: <anV+EoxWGKdU9da0@yjaykim-PowerEdge-T330>
On 08/07/26 at 03:41pm, Youngjun Park wrote:
> On Thu, Aug 06, 2026 at 01:06:55PM -0700, Andrew Morton wrote:
> > On Fri, 7 Aug 2026 04:32:26 +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.
> >
> > Thanks.
> >
> > Can you help us understand how significant this change is for users?
> > If "not very" then I'd prefer to defer consideraton of the series until
> > after 7.3-rc1.
>
> Hello Andrew
>
> "Not very" in the common case, though there is a case where the win is clear.
> No bug and no user report.
>
> For now I would rather defer to after 7.3-rc1.
>
> And for your reference, here is the details.
>
> Every swapoff does a little less work now, because the scan steps over an
> unused area one cluster at a time.
> But IMHO most of the swapoff time goes to unuse_mm() and to reading the pages back in.
>
> The gain shows on a large swap device that is almost empty, when the last
> pages still in use are near the end of it. The scan has to walk up to
> them, and today it looks at every slot on the way. Now the empty clusters
> in between are skipped in one step.
>
> 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.
>
> That should be around half a second of scan saved.
Yeah, a concrete number is shown.
next prev parent reply other threads:[~2026-08-07 8:42 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-06 19:32 [PATCH v3 0/2] mm/swap: skip empty clusters in the swapoff scan Youngjun Park
2026-08-06 19:32 ` [PATCH v3 1/2] mm/swap: fix stale comment on swap_info_struct::cluster_info Youngjun Park
2026-08-07 9:49 ` Baoquan He
2026-08-06 19:32 ` [PATCH v3 2/2] mm/swap: scan by cluster in find_next_to_unuse() Youngjun Park
2026-08-07 7:33 ` Kairui Song
2026-08-07 9:52 ` Baoquan He
2026-08-06 20:06 ` [PATCH v3 0/2] mm/swap: skip empty clusters in the swapoff scan Andrew Morton
2026-08-07 6:41 ` Youngjun Park
2026-08-07 6:59 ` Youngjun Park
2026-08-07 8:42 ` Baoquan He [this message]
2026-08-07 9:59 ` Youngjun Park
2026-08-07 21:42 ` Andrew Morton
2026-08-08 15:53 ` Youngjun Park
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=anWabobwPyAXvRe5@MiWiFi-R3L-srv \
--to=baoquan.he@linux.dev \
--cc=akpm@linux-foundation.org \
--cc=baohua@kernel.org \
--cc=chrisl@kernel.org \
--cc=her0gyugyu@gmail.com \
--cc=kasong@tencent.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=nphamcs@gmail.com \
--cc=shikemeng@huaweicloud.com \
--cc=youngjun.park@lge.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.