From: Baolin Wang <baolin.wang@linux.alibaba.com>
To: Kairui Song <kasong@tencent.com>, linux-mm@kvack.org
Cc: 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
Subject: Re: [PATCH v5 7/8] mm/shmem, swap: rework swap entry and index calculation for large swapin
Date: Fri, 11 Jul 2025 14:36:33 +0800 [thread overview]
Message-ID: <6d6feb41-5cdd-4591-8e19-d9c247e16fcb@linux.alibaba.com> (raw)
In-Reply-To: <20250710033706.71042-8-ryncsn@gmail.com>
On 2025/7/10 11:37, Kairui Song wrote:
> From: Kairui Song <kasong@tencent.com>
>
> Instead of calculating the swap entry differently in different swapin
> paths, calculate it early before the swap cache lookup and use that
> for the lookup and later swapin. And after swapin have brought a folio,
> simply round it down against the size of the folio.
>
> This is simple and effective enough to verify the swap value. A folio's
> swap entry is always aligned by its size. Any kind of parallel split or
> race is acceptable because the final shmem_add_to_page_cache ensures
> that all entries covered by the folio are correct, and thus there
> will be no data corruption.
>
> This also prevents false positive cache lookup. If a shmem read
> request's index points to the middle of a large swap entry,
> previously, shmem will try the swap cache lookup using the large swap
> entry's starting value (which is the first sub swap entry of this
> large entry). This will lead to false positive lookup results if only
> the first few swap entries are cached but the actual requested swap
> entry pointed by the index is uncached. This is not a rare event,
> as swap readahead always tries to cache order 0 folios when possible.
>
> And this shouldn't cause any increased repeated faults. Instead, no
> matter how the shmem mapping is split in parallel, as long as the
> mapping still contains the right entries, the swapin will succeed.
>
> The final object size and stack usage are also reduced due to
> simplified code:
>
> ./scripts/bloat-o-meter mm/shmem.o.old mm/shmem.o
> add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-233 (-233)
> Function old new delta
> shmem_swapin_folio 4040 3807 -233
> Total: Before=33152, After=32919, chg -0.70%
>
> Stack usage (Before vs After):
> mm/shmem.c:2277:12:shmem_swapin_folio 264 static
> mm/shmem.c:2277:12:shmem_swapin_folio 256 static
>
> And while at it, round down the index too if swap entry is round down.
> The index is used either for folio reallocation or confirming the
> mapping content. In either case, it should be aligned with the swap
> folio.
>
> Signed-off-by: Kairui Song <kasong@tencent.com>
Overall, I don't see any obvious issues, but please give me some time to
run some tests and then get back to you. Thanks.
next prev parent reply other threads:[~2025-07-11 6:36 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-10 3:36 [PATCH v5 0/8] mm/shmem, swap: bugfix and improvement of mTHP swap in Kairui Song
2025-07-10 3:36 ` [PATCH v5 1/8] mm/shmem, swap: improve cached mTHP handling and fix potential hung Kairui Song
2025-07-24 17:02 ` Kairui Song
2025-07-24 18:16 ` Kairui Song
2025-07-25 3:52 ` Baolin Wang
2025-07-25 4:54 ` Kairui Song
2025-07-10 3:37 ` [PATCH v5 2/8] mm/shmem, swap: avoid redundant Xarray lookup during swapin Kairui Song
2025-07-10 3:37 ` [PATCH v5 3/8] mm/shmem, swap: tidy up THP swapin checks Kairui Song
2025-07-10 3:37 ` [PATCH v5 4/8] mm/shmem, swap: tidy up swap entry splitting Kairui Song
2025-07-16 7:09 ` Baoquan He
2025-07-10 3:37 ` [PATCH v5 5/8] mm/shmem, swap: never use swap cache and readahead for SWP_SYNCHRONOUS_IO Kairui Song
2025-07-11 6:10 ` Baolin Wang
2025-07-13 10:53 ` Barry Song
2025-07-10 3:37 ` [PATCH v5 6/8] mm/shmem, swap: simplify swapin path and result handling Kairui Song
2025-07-11 6:23 ` Baolin Wang
2025-07-11 6:28 ` Kairui Song
2025-07-15 22:09 ` Hugh Dickins
2025-07-16 7:14 ` Kairui Song
2025-07-10 3:37 ` [PATCH v5 7/8] mm/shmem, swap: rework swap entry and index calculation for large swapin Kairui Song
2025-07-11 6:36 ` Baolin Wang [this message]
2025-07-14 2:39 ` Baolin Wang
2025-07-10 3:37 ` [PATCH v5 8/8] mm/shmem, swap: fix major fault counting 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=6d6feb41-5cdd-4591-8e19-d9c247e16fcb@linux.alibaba.com \
--to=baolin.wang@linux.alibaba.com \
--cc=akpm@linux-foundation.org \
--cc=baohua@kernel.org \
--cc=bhe@redhat.com \
--cc=chrisl@kernel.org \
--cc=hughd@google.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=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 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.