From: Barry Song <baohua@kernel.org>
To: Nhat Pham <nphamcs@gmail.com>
Cc: Baolin Wang <baolin.wang@linux.alibaba.com>,
Yosry Ahmed <yosryahmed@google.com>,
akpm@linux-foundation.org, hannes@cmpxchg.org, hughd@google.com,
shakeel.butt@linux.dev, ryan.roberts@arm.com,
ying.huang@intel.com, chrisl@kernel.org, david@redhat.com,
kasong@tencent.com, willy@infradead.org,
viro@zeniv.linux.org.uk, chengming.zhou@linux.dev,
linux-mm@kvack.org, kernel-team@meta.com,
linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH 0/2] remove SWAP_MAP_SHMEM
Date: Thu, 26 Sep 2024 15:59:09 +1200 [thread overview]
Message-ID: <CAGsJ_4yTbLwfzMTk9sivBDLJb1JAcDNdvsFHUeag9mUvAi0SUQ@mail.gmail.com> (raw)
In-Reply-To: <CAKEwX=NB-vf4zTTJ2KaRFGJmcfeDQpLLuiX=Rh6X+49ib8S=wA@mail.gmail.com>
On Thu, Sep 26, 2024 at 2:37 AM Nhat Pham <nphamcs@gmail.com> wrote:
>
> On Tue, Sep 24, 2024 at 6:53 PM Baolin Wang
> <baolin.wang@linux.alibaba.com> wrote:
> >
> >
> > One benefit I can mention is that removing 'SWAP_MAP_SHMEM' can help to
> > batch free shmem swap entries in __swap_entries_free(), similar to the
> > commit bea67dcc5eea ("mm: attempt to batch free swap entries for
> > zap_pte_range()") did, which can improve the performance of shmem mTHP
> > munmap() function based on my testing.
>
> Yeah, the problem with having an extraneous state is you have to
> constantly check for it in code, and/or keep it in mind when you
> develop things. I've been constantly having to check for this state
> when I develop code around this area, and it gets old fast.
>
> If we can use it to optimize something, I can understand keeping it.
> But it just seems like dead code to me :)
>
> My preference is to do this as simply as possible - add another case
> (usage == 1, nr > 1, and we need to add swap continuations) in the
> check in __swap_duplicate()'s first loop, and just WARN right there.
>
> That case CANNOT happen UNLESS we introduce a bug, or have a new use
> case. When we actually have a use case, we can always introduce
> handling/fallback logic for that case.
>
> Barry, Yosry, Baolin, Ying, how do you feel about this?
I’m not entirely clear on your point. If your proposal is to support the
case where usage == 1 and nr > 1 only when we don’t require
CONTINUED, and to issue a warning once we determine that
CONTINUED is needed, then I’m completely on board with that
approach.
It seems that your intention is to simply relocate the existing warning
to the scenario where CONTINUED is actually required, rather than
maintaining a warning for the case where usage == 1 and nr > 1 at
all times?
I wasn't actually suggesting a rollback as you posted:
err = __swap_duplicate(entry, 1, nr);
if (err == -ENOMEM) {
/* fallback to non-batched version */
for (i = 0; i < nr; i++) {
cur_entry = (swp_entry_t){entry.val + i};
if (swap_duplicate(cur_entry)) {
/* rollback */
while (--i >= 0) {
cur_entry = (swp_entry_t){entry.val + i};
swap_free(cur_entry);
}
I suggested checking for all errors except -ENOMEM in the first loop. If all
conditions indicate that only CONTINUED is necessary (with no other
issues like ENOENT, EEXIST, etc., for any entry), we can proceed
with a for loop for swap_duplicate(), eliminating the need for a rollback.
However, I agree that we can proceed with that only when there is actually
a user involved. (There's no need to address it right now.)
Thanks
Barry
next prev parent reply other threads:[~2024-12-05 15:20 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-23 23:11 Nhat Pham
2024-09-23 23:11 ` [RFC PATCH 1/2] swapfile: add a batched variant for swap_duplicate() Nhat Pham
2024-09-23 23:11 ` [RFC PATCH 2/2] swap: shmem: remove SWAP_MAP_SHMEM Nhat Pham
2024-09-24 0:32 ` Yosry Ahmed
2024-09-24 0:20 ` [RFC PATCH 0/2] " Yosry Ahmed
2024-09-24 1:55 ` Baolin Wang
2024-09-24 2:15 ` Yosry Ahmed
2024-09-24 3:25 ` Baolin Wang
2024-09-24 14:32 ` Nhat Pham
2024-09-24 15:07 ` Yosry Ahmed
2024-09-24 15:48 ` Nhat Pham
2024-09-24 18:11 ` Yosry Ahmed
2024-09-25 6:26 ` Barry Song
2024-09-25 7:24 ` Huang, Ying
2024-09-25 7:38 ` Barry Song
2024-09-25 1:53 ` Baolin Wang
2024-09-25 14:37 ` Nhat Pham
2024-09-26 1:59 ` Huang, Ying
2024-09-26 3:30 ` Baolin Wang
2024-09-26 3:59 ` Barry Song [this message]
2024-09-26 22:50 ` Nhat Pham
2024-09-26 4:00 ` Barry Song
2024-09-25 7:19 ` Huang, Ying
2024-09-25 7:32 ` Barry Song
2024-09-25 14:21 ` Nhat Pham
2024-09-25 14:24 ` Nhat Pham
2024-09-25 14:28 ` Nhat Pham
2024-09-24 20:15 ` Chris Li
2024-09-24 21:30 ` Yosry Ahmed
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=CAGsJ_4yTbLwfzMTk9sivBDLJb1JAcDNdvsFHUeag9mUvAi0SUQ@mail.gmail.com \
--to=baohua@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=baolin.wang@linux.alibaba.com \
--cc=chengming.zhou@linux.dev \
--cc=chrisl@kernel.org \
--cc=david@redhat.com \
--cc=hannes@cmpxchg.org \
--cc=hughd@google.com \
--cc=kasong@tencent.com \
--cc=kernel-team@meta.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=nphamcs@gmail.com \
--cc=ryan.roberts@arm.com \
--cc=shakeel.butt@linux.dev \
--cc=viro@zeniv.linux.org.uk \
--cc=willy@infradead.org \
--cc=ying.huang@intel.com \
--cc=yosryahmed@google.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