linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Kairui Song <ryncsn@gmail.com>
To: Baolin Wang <baolin.wang@linux.alibaba.com>
Cc: linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>,
	 Hugh Dickins <hughd@google.com>,
	Matthew Wilcox <willy@infradead.org>,
	 Kemeng Shi <shikemeng@huaweicloud.com>,
	Chris Li <chrisl@kernel.org>,  Nhat Pham <nphamcs@gmail.com>,
	Baoquan He <bhe@redhat.com>, Barry Song <baohua@kernel.org>,
	 linux-kernel@vger.kernel.org, stable@vger.kernel.org
Subject: Re: [PATCH v2 1/4] mm/shmem, swap: improve cached mTHP handling and fix potential hung
Date: Mon, 23 Jun 2025 11:40:23 +0800	[thread overview]
Message-ID: <CAMgjq7Amf-ceW914NojmFFGPyypN4iFw7FJNLp7iHKoG=kms2A@mail.gmail.com> (raw)
In-Reply-To: <9e31bbb8-73e7-4e67-973d-491f93ba938f@linux.alibaba.com>

On Mon, Jun 23, 2025 at 11:39 AM Baolin Wang
<baolin.wang@linux.alibaba.com> wrote:
> On 2025/6/23 11:35, Kairui Song wrote:
> > On Mon, Jun 23, 2025 at 11:26 AM Baolin Wang
> > <baolin.wang@linux.alibaba.com> wrote:
> >>
> >> Hi Kairui,
> >>
> >> On 2025/6/20 01:55, Kairui Song wrote:
> >>> From: Kairui Song <kasong@tencent.com>
> >>>
> >>> The current swap-in code assumes that, when a swap entry in shmem
> >>> mapping is order 0, its cached folios (if present) must be order 0
> >>> too, which turns out not always correct.
> >>>
> >>> The problem is shmem_split_large_entry is called before verifying the
> >>> folio will eventually be swapped in, one possible race is:
> >>>
> >>>       CPU1                          CPU2
> >>> shmem_swapin_folio
> >>> /* swap in of order > 0 swap entry S1 */
> >>>     folio = swap_cache_get_folio
> >>>     /* folio = NULL */
> >>>     order = xa_get_order
> >>>     /* order > 0 */
> >>>     folio = shmem_swap_alloc_folio
> >>>     /* mTHP alloc failure, folio = NULL */
> >>>     <... Interrupted ...>
> >>>                                    shmem_swapin_folio
> >>>                                    /* S1 is swapped in */
> >>>                                    shmem_writeout
> >>>                                    /* S1 is swapped out, folio cached */
> >>>     shmem_split_large_entry(..., S1)
> >>>     /* S1 is split, but the folio covering it has order > 0 now */
> >>>
> >>> Now any following swapin of S1 will hang: `xa_get_order` returns 0,
> >>> and folio lookup will return a folio with order > 0. The
> >>> `xa_get_order(&mapping->i_pages, index) != folio_order(folio)` will
> >>> always return false causing swap-in to return -EEXIST.
> >>>
> >>> And this looks fragile. So fix this up by allowing seeing a larger folio
> >>> in swap cache, and check the whole shmem mapping range covered by the
> >>> swapin have the right swap value upon inserting the folio. And drop
> >>> the redundant tree walks before the insertion.
> >>>
> >>> This will actually improve the performance, as it avoided two redundant
> >>> Xarray tree walks in the hot path, and the only side effect is that in
> >>> the failure path, shmem may redundantly reallocate a few folios
> >>> causing temporary slight memory pressure.
> >>>
> >>> And worth noting, it may seems the order and value check before
> >>> inserting might help reducing the lock contention, which is not true.
> >>> The swap cache layer ensures raced swapin will either see a swap cache
> >>> folio or failed to do a swapin (we have SWAP_HAS_CACHE bit even if
> >>> swap cache is bypassed), so holding the folio lock and checking the
> >>> folio flag is already good enough for avoiding the lock contention.
> >>> The chance that a folio passes the swap entry value check but the
> >>> shmem mapping slot has changed should be very low.
> >>
> >> Thanks for fixing the issue. Sadly, I haven't reproduced this issue from
> >> my previous test cases :(
> >>
> >> And I have a question below.
> >>
> >>> Cc: stable@vger.kernel.org
> >>> Fixes: 809bc86517cc ("mm: shmem: support large folio swap out")
> >>> Signed-off-by: Kairui Song <kasong@tencent.com>
> >>> Reviewed-by: Kemeng Shi <shikemeng@huaweicloud.com>
> >>> ---
> >>>    mm/shmem.c | 30 +++++++++++++++++++++---------
> >>>    1 file changed, 21 insertions(+), 9 deletions(-)
> >>>
> >>> diff --git a/mm/shmem.c b/mm/shmem.c
> >>> index eda35be2a8d9..4e7ef343a29b 100644
> >>> --- a/mm/shmem.c
> >>> +++ b/mm/shmem.c
> >>> @@ -884,7 +884,9 @@ static int shmem_add_to_page_cache(struct folio *folio,
> >>>                                   pgoff_t index, void *expected, gfp_t gfp)
> >>>    {
> >>>        XA_STATE_ORDER(xas, &mapping->i_pages, index, folio_order(folio));
> >>> -     long nr = folio_nr_pages(folio);
> >>> +     unsigned long nr = folio_nr_pages(folio);
> >>> +     swp_entry_t iter, swap;
> >>> +     void *entry;
> >>>
> >>>        VM_BUG_ON_FOLIO(index != round_down(index, nr), folio);
> >>>        VM_BUG_ON_FOLIO(!folio_test_locked(folio), folio);
> >>> @@ -896,14 +898,24 @@ static int shmem_add_to_page_cache(struct folio *folio,
> >>>
> >>>        gfp &= GFP_RECLAIM_MASK;
> >>>        folio_throttle_swaprate(folio, gfp);
> >>> +     swap = iter = radix_to_swp_entry(expected);
> >>>
> >>>        do {
> >>>                xas_lock_irq(&xas);
> >>> -             if (expected != xas_find_conflict(&xas)) {
> >>> -                     xas_set_err(&xas, -EEXIST);
> >>> -                     goto unlock;
> >>> +             xas_for_each_conflict(&xas, entry) {
> >>> +                     /*
> >>> +                      * The range must either be empty, or filled with
> >>> +                      * expected swap entries. Shmem swap entries are never
> >>> +                      * partially freed without split of both entry and
> >>> +                      * folio, so there shouldn't be any holes.
> >>> +                      */
> >>> +                     if (!expected || entry != swp_to_radix_entry(iter)) {
> >>> +                             xas_set_err(&xas, -EEXIST);
> >>> +                             goto unlock;
> >>> +                     }
> >>> +                     iter.val += 1 << xas_get_order(&xas);
> >>>                }
> >>> -             if (expected && xas_find_conflict(&xas)) {
> >>> +             if (expected && iter.val - nr != swap.val) {
> >>>                        xas_set_err(&xas, -EEXIST);
> >>>                        goto unlock;
> >>>                }
> >>> @@ -2323,7 +2335,7 @@ static int shmem_swapin_folio(struct inode *inode, pgoff_t index,
> >>>                        error = -ENOMEM;
> >>>                        goto failed;
> >>>                }
> >>> -     } else if (order != folio_order(folio)) {
> >>> +     } else if (order > folio_order(folio)) {
> >>>                /*
> >>>                 * Swap readahead may swap in order 0 folios into swapcache
> >>>                 * asynchronously, while the shmem mapping can still stores
> >>> @@ -2348,15 +2360,15 @@ static int shmem_swapin_folio(struct inode *inode, pgoff_t index,
> >>>
> >>>                        swap = swp_entry(swp_type(swap), swp_offset(swap) + offset);
> >>>                }
> >>> +     } else if (order < folio_order(folio)) {
> >>> +             swap.val = round_down(swp_type(swap), folio_order(folio));
> >>
> >> Why rounding down the swap type? do you mean rounding down the swap offset?
> >
> > Ouch, right, it should be the value:
> >
> > swap.val = round_down(swap.val, folio_order(folio));
> >
> > I messed up the code here during a rebase, let me send a V3 then.
>
> Should be
>
> swap.val = round_down(swap.val, 1 << folio_order(folio));
>
> ?

Yes, exactly.


  reply	other threads:[~2025-06-23  3:41 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-19 17:55 [PATCH v2 0/4] mm/shmem, swap: bugfix and improvement of mTHP swap in Kairui Song
2025-06-19 17:55 ` [PATCH v2 1/4] mm/shmem, swap: improve cached mTHP handling and fix potential hung Kairui Song
2025-06-23  3:26   ` Baolin Wang
2025-06-23  3:35     ` Kairui Song
2025-06-23  3:37       ` Kairui Song
2025-06-23  3:38       ` Baolin Wang
2025-06-23  3:40         ` Kairui Song [this message]
2025-06-19 17:55 ` [PATCH v2 2/4] mm/shmem, swap: avoid redundant Xarray lookup during swapin Kairui Song
2025-06-20  3:34   ` Dev Jain
2025-06-21  4:27   ` Baolin Wang
2025-06-19 17:55 ` [PATCH v2 3/4] mm/shmem, swap: improve mthp swapin process Kairui Song
2025-06-20  7:53   ` YoungJun Park
2025-06-22 18:48     ` Kairui Song
2025-06-23  3:37   ` Baolin Wang
2025-06-23  3:39     ` Kairui Song
2025-06-19 17:55 ` [PATCH v2 4/4] mm/shmem, swap: avoid false positive swap cache lookup Kairui Song

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='CAMgjq7Amf-ceW914NojmFFGPyypN4iFw7FJNLp7iHKoG=kms2A@mail.gmail.com' \
    --to=ryncsn@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=baohua@kernel.org \
    --cc=baolin.wang@linux.alibaba.com \
    --cc=bhe@redhat.com \
    --cc=chrisl@kernel.org \
    --cc=hughd@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=nphamcs@gmail.com \
    --cc=shikemeng@huaweicloud.com \
    --cc=stable@vger.kernel.org \
    --cc=willy@infradead.org \
    /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