From: Johannes Weiner <hannes@cmpxchg.org>
To: Chris Li <chrisl@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Kairui Song <kasong@tencent.com>,
Kemeng Shi <shikemeng@huaweicloud.com>,
Nhat Pham <nphamcs@gmail.com>, Baoquan He <bhe@redhat.com>,
Barry Song <baohua@kernel.org>,
Yosry Ahmed <yosry.ahmed@linux.dev>,
Chengming Zhou <chengming.zhou@linux.dev>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
pratmal@google.com, sweettea@google.com, gthelen@google.com,
weixugc@google.com
Subject: Re: [PATCH RFC] mm: ghost swapfile support for zswap
Date: Tue, 25 Nov 2025 16:31:26 -0500 [thread overview]
Message-ID: <20251125213126.GB135004@cmpxchg.org> (raw)
In-Reply-To: <CACePvbVJEWd64r-o8ezh+0QByYbWjYVKiLgxNiBJOjfRWP__sw@mail.gmail.com>
On Tue, Nov 25, 2025 at 11:27:04PM +0400, Chris Li wrote:
> On Mon, Nov 24, 2025 at 11:33 PM Johannes Weiner <hannes@cmpxchg.org> wrote:
> > > > Do you have a link to that proposal?
> > >
> > > My 2024 LSF swap pony talk already has a mechanism to redirect page
> > > cache swap entries to different physical locations.
> > > That can also work for redirecting swap entries in different swapfiles.
> > >
> > > https://lore.kernel.org/linux-mm/CANeU7QnPsTouKxdK2QO8Opho6dh1qMGTox2e5kFOV8jKoEJwig@mail.gmail.com/
> >
> > I looked through your slides and the LWN article, but it's very hard
> > for me to find answers to my questions in there.
>
> Naturally, the slide is only intended to cover what is in the current
> swap table may be phase VII.
> But it does have the physical location pointer consideration.
>
> > In your proposal, let's say you have a swp_entry_t in the page
> > table. What does it describe, and what are the data structures to get
> > from this key to user data in the following scenarios:
>
> Please keep in mind that I don't have every detail design laid out. I
> follow the first principles that redirect a swap entry page should
> only take an additional 4 byte per swap entry. VS blow up the swap
> entry size by something like 24 bytes?
Nhat can lay this out in more detail, but there isn't much new stuff
in the virtual swap descriptor. It's mostly just a consolidation of
state we currently track elsewhere - swap count, swapcache pointer,
cgroup ownership etc.
The actual indirection is just a word for the backend type,offset.
That indirection is the tradeoff for swapped pages. In turn you're
getting back all that other stuff for swap slots that *aren't*
currently used. This is a win for the vast majority of users.
Since you mentioned first principles - the dynamically sized swap
space is also much more suitable for compressed pools, which are the
dominant form of swap setups nowadays. Again a win for the majority.
And the worst-case is reasonable. I don't see the giant gulf you seem
to see there. I don't know where it's supposed to be coming from.
next prev parent reply other threads:[~2025-11-25 21:31 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-21 9:31 Chris Li
2025-11-21 10:19 ` Nhat Pham
2025-11-22 1:52 ` Chris Li
2025-11-24 14:47 ` Nhat Pham
2025-11-25 18:26 ` Chris Li
2025-11-21 11:40 ` Johannes Weiner
2025-11-22 1:52 ` Chris Li
2025-11-22 10:29 ` Kairui Song
2025-11-24 15:35 ` Nhat Pham
2025-11-24 16:14 ` Rik van Riel
2025-11-24 17:26 ` Chris Li
2025-11-24 17:42 ` Rik van Riel
2025-11-24 17:58 ` Chris Li
2025-11-24 17:27 ` Johannes Weiner
2025-11-24 18:24 ` Chris Li
2025-11-24 19:32 ` Johannes Weiner
2025-11-25 19:27 ` Chris Li
2025-11-25 21:31 ` Johannes Weiner [this message]
2025-11-26 19:22 ` Chris Li
2025-11-26 21:52 ` Rik van Riel
2025-11-27 1:52 ` Chris Li
2025-11-27 2:26 ` Rik van Riel
2025-11-27 19:09 ` Chris Li
2025-11-28 20:46 ` Nhat Pham
2025-11-29 20:38 ` Chris Li
2025-12-01 16:43 ` Johannes Weiner
2025-12-01 19:49 ` Kairui Song
2025-12-02 17:02 ` Johannes Weiner
2025-12-02 20:48 ` Chris Li
2025-12-02 19:58 ` Chris Li
2025-12-01 23:37 ` Nhat Pham
2025-12-02 19:18 ` Chris Li
2025-12-02 18:18 ` Nhat Pham
2025-12-02 21:07 ` Chris Li
2025-11-24 19:32 ` Yosry Ahmed
2025-11-24 20:24 ` Nhat Pham
2025-11-25 18:50 ` Chris Li
2025-11-26 21:58 ` Rik van Riel
2025-11-27 2:07 ` Chris Li
2025-11-27 2:34 ` Rik van Riel
2025-11-25 18:14 ` Chris Li
2025-11-25 18:55 ` Johannes Weiner
2025-11-21 15:14 ` Yosry Ahmed
2025-11-22 1:52 ` Chris Li
2025-11-24 14:57 ` Nhat Pham
2025-11-22 9:59 ` Kairui Song
2025-11-22 13:58 ` Baoquan He
2025-12-02 2:56 ` Barry Song
2025-12-02 6:31 ` Baoquan He
2025-12-02 17:53 ` Nhat Pham
2025-12-02 21:01 ` Chris Li
2025-12-03 8:37 ` Yosry Ahmed
2025-12-03 20:02 ` Chris Li
2025-12-04 6:16 ` Yosry Ahmed
2025-12-04 10:11 ` Chris Li
2025-12-04 20:55 ` Yosry Ahmed
2025-12-05 8:56 ` 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=20251125213126.GB135004@cmpxchg.org \
--to=hannes@cmpxchg.org \
--cc=akpm@linux-foundation.org \
--cc=baohua@kernel.org \
--cc=bhe@redhat.com \
--cc=chengming.zhou@linux.dev \
--cc=chrisl@kernel.org \
--cc=gthelen@google.com \
--cc=kasong@tencent.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=nphamcs@gmail.com \
--cc=pratmal@google.com \
--cc=shikemeng@huaweicloud.com \
--cc=sweettea@google.com \
--cc=weixugc@google.com \
--cc=yosry.ahmed@linux.dev \
/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
all inboxes | Powered by JetHome®