From: Youngjun Park <youngjun.park@lge.com>
To: Kemeng Shi <shikemeng@huaweicloud.com>
Cc: chrisl@kernel.org, kasong@tencent.com, nphamcs@gmail.com,
baoquan.he@linux.dev, baohua@kernel.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 4/4] mm, swap: Remove unneeded swap_extend_table_try_free() in swap_dup_entries_cluster()
Date: Tue, 21 Jul 2026 16:58:34 +0900 [thread overview]
Message-ID: <al8mqsmCy42X3Ewo@yjaykim-PowerEdge-T330> (raw)
In-Reply-To: <20260720071342.50742-5-shikemeng@huaweicloud.com>
On Mon, Jul 20, 2026 at 03:13:42PM +0800, Kemeng Shi wrote:
> Since commit 0475fde0f68de ("mm, swap: avoid leaving unused extend table
> after alloc race"), extend table is always allocated when any swap count
Looks like this? 395085eacdfa
> reach MAX - 1 and is always freed when swap count decrease to MAX - 1
> or MAX - 2 with cluster lock held. So the extend table will always be
> freed properly when decrease swap count in __swap_cluster_put_entry().
> So swap_extend_table_try_free() outside of __swap_cluster_put_entry()
> is unneeded and can be removed.
>
> Signed-off-by: Kemeng Shi <shikemeng@huaweicloud.com>
> ---
> mm/swapfile.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/mm/swapfile.c b/mm/swapfile.c
> index 3fcbd10c6353..fc9f16bc2e4e 100644
> --- a/mm/swapfile.c
> +++ b/mm/swapfile.c
> @@ -1732,7 +1732,6 @@ static int swap_dup_entries_cluster(struct swap_info_struct *si,
> failed:
> while (ci_off-- > ci_start)
> __swap_cluster_put_entry(ci, ci_off);
Right, it handles duplicate here.
> - swap_extend_table_try_free(ci);
> swap_cluster_unlock(ci);
> return err;
> }
> --
> 2.36.1
However, looking at this part, since swap_extend_table_alloc() uses
GFP_ATOMIC, I think it could be further improved by not releasing the ci
lock.
This would also clarify the situation where scount becomes MAX - 2.
But there seem to be some drawbacks. For instance, the original intention
might have been to make the swap_extend_table_alloc() API work seamlessly
for both sleepable and unsleepable contexts, and some implementation details
might not look as clean.
Here is what I was thinking:
...
err = __swap_cluster_dup_entry(ci, ci_off);
/* <- Could -ENOMEM handling be improved here? */
if (unlikely(err)) {
if (err == -ENOMEM) {
spin_unlock(&ci->lock);
/* <- Change to NOT release the lock, and make
* swap_extend_table_alloc aware of it with
* GFP_ATOMIC(aware cluster locked) */
err = swap_extend_table_alloc(si, ci, ci_off,
GFP_ATOMIC);
spin_lock(&ci->lock);
if (!err)
goto restart;
Just sharing my thoughts! (Wondering if this could be a good direction for
further improvement?)
The current modification looks good enough to me.
Reviewed-by: Youngjun Park <youngjun.park.lge.com>
Youngjun
next prev parent reply other threads:[~2026-07-21 7:58 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-20 7:13 [PATCH 0/4] mm, swap: some random fixes and cleanups Kemeng Shi
2026-07-20 7:13 ` [PATCH 1/4] mm, swap: Fix potential NULL dereference when trying a sleep table allocation Kemeng Shi
2026-07-20 9:11 ` Youngjun Park
2026-07-21 1:49 ` Kemeng Shi
2026-07-21 2:15 ` Youngjun Park
2026-07-21 6:12 ` Kemeng Shi
2026-07-20 9:11 ` Kairui Song
2026-07-21 2:21 ` Kemeng Shi
2026-07-20 7:13 ` [PATCH 2/4] mm, swap: Move setup_swap_clusters_info() after SWP_SOLIDSTATE initialization Kemeng Shi
2026-07-20 15:54 ` Luiz Capitulino
2026-07-21 2:19 ` Kemeng Shi
2026-07-20 7:13 ` [PATCH 3/4] mm, swap: return early from swap_extend_table_try_free() on first non-zero entry Kemeng Shi
2026-07-21 4:07 ` Youngjun Park
2026-07-20 7:13 ` [PATCH 4/4] mm, swap: Remove unneeded swap_extend_table_try_free() in swap_dup_entries_cluster() Kemeng Shi
2026-07-21 7:58 ` Youngjun Park [this message]
2026-08-20 11:46 ` Kemeng Shi
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=al8mqsmCy42X3Ewo@yjaykim-PowerEdge-T330 \
--to=youngjun.park@lge.com \
--cc=baohua@kernel.org \
--cc=baoquan.he@linux.dev \
--cc=chrisl@kernel.org \
--cc=kasong@tencent.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=nphamcs@gmail.com \
--cc=shikemeng@huaweicloud.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox