From: YoungJun Park <youngjun.park@lge.com>
To: Kairui Song <ryncsn@gmail.com>
Cc: akpm@linux-foundation.org, chrisl@kernel.org,
shikemeng@huaweicloud.com, nphamcs@gmail.com, bhe@redhat.com,
baohua@kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH] mm/swap: fix wrong plist empty check in swap_alloc_slow()
Date: Fri, 21 Nov 2025 15:54:51 +0900 [thread overview]
Message-ID: <aSAMu04In6dLboPs@yjaykim-PowerEdge-T330> (raw)
In-Reply-To: <CAMgjq7C_ebrZv73VNBk-mhaSJwQXJur96R2OdW96YCM7vtJkzw@mail.gmail.com>
On Thu, Nov 20, 2025 at 10:18:34AM +0800, Kairui Song wrote:
> On Thu, Nov 20, 2025 at 10:06 AM YoungJun Park <youngjun.park@lge.com> wrote:
> >
> > I've investigated this further and noticed something about swap_sync_discard.
> > During iteration, it doesn't perform an empty check on swap devices. As a
> > result, if the iteration exits because the next device is full
> > (deleted by plist at this time), the
> > operation(swap I/O) fails even when other available swap devices remain.
> >
> > Should this be addressed?
> >
> > Best Regards,
> > Youngjun Park
>
> Actually after thinking about it again, swap_sync_discard should be
> looking at swap_active_head, not swap_avail_head. Changing to
> swap_active_head and also checking SWP_WRITEOK is a right fix I think,
> and should be good enough.
>
Hi Kairui,
Let me confirm if I understand your intention correctly.
It seems the following changes would be made:
- Change from swap_avail_lock to swap_lock
- After sync_discard, reacquire the lock and check if the list was
broken using SWP_WRITEOK instead. If broken, since we can't know
the next si, restart the list traversal from the beginning.
The advantage would be that it's only affected by swapoff changes,
so exceptional condition checks in this logic would occur less
frequently. Also, using swap_lock would be better in terms of
contention compared to swap I/O contention.
I'd like to confirm if this is what you intended, and if we agree
on this approach, I'll submit it as a separate patch.
Thank you.
Youngjun Park
next prev parent reply other threads:[~2025-11-21 6:55 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-19 11:41 Youngjun Park
2025-11-19 13:02 ` Kairui Song
2025-11-19 16:37 ` YoungJun Park
2025-11-20 2:08 ` Kairui Song
2025-11-20 2:06 ` YoungJun Park
2025-11-20 2:18 ` Kairui Song
2025-11-21 6:54 ` YoungJun Park [this message]
2025-11-21 16:56 ` Kairui Song
2025-11-20 2:47 ` Baoquan He
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=aSAMu04In6dLboPs@yjaykim-PowerEdge-T330 \
--to=youngjun.park@lge.com \
--cc=akpm@linux-foundation.org \
--cc=baohua@kernel.org \
--cc=bhe@redhat.com \
--cc=chrisl@kernel.org \
--cc=linux-mm@kvack.org \
--cc=nphamcs@gmail.com \
--cc=ryncsn@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