linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
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


  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