From: Chris Li <chrisl@kernel.org>
To: Nhat Pham <nphamcs@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Kairui Song <kasong@tencent.com>,
Kemeng Shi <shikemeng@huaweicloud.com>,
Baoquan He <bhe@redhat.com>, Barry Song <baohua@kernel.org>,
Johannes Weiner <hannes@cmpxchg.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: Fri, 21 Nov 2025 17:52:01 -0800 [thread overview]
Message-ID: <CACePvbUxCN_2fHz0Ds=u52mmOvdhonvRgm6mPdcJcs5qLZj55Q@mail.gmail.com> (raw)
In-Reply-To: <CAKEwX=PQM_4Mp75R4yeQ=WoqOxj7EJK=FpgcemNSYDS3fLXQLw@mail.gmail.com>
On Fri, Nov 21, 2025 at 2:19 AM Nhat Pham <nphamcs@gmail.com> wrote:
>
> On Fri, Nov 21, 2025 at 9:32 AM Chris Li <chrisl@kernel.org> wrote:
> >
> > The current zswap requires a backing swapfile. The swap slot used
> > by zswap is not able to be used by the swapfile. That waste swapfile
> > space.
> >
> > The ghost swapfile is a swapfile that only contains the swapfile header
> > for zswap. The swapfile header indicate the size of the swapfile. There
> > is no swap data section in the ghost swapfile, therefore, no waste of
> > swapfile space. As such, any write to a ghost swapfile will fail. To
> > prevents accidental read or write of ghost swapfile, bdev of
> > swap_info_struct is set to NULL. Ghost swapfile will also set the SSD
> > flag because there is no rotation disk access when using zswap.
>
> Would this also affect the swap slot allocation algorithm?
>
> >
> > The zswap write back has been disabled if all swapfiles in the system
> > are ghost swap files.
>
> I don't like this design:
>
> 1. Statically sizing the compression tier will be an operational
> nightmare, for users that have to support a variety (and increasingly
> bigger sized) types of hosts. It's one of the primary motivations of
> the virtual swap line of work. We need to move towards a more dynamic
> architecture for zswap, not the other way around, in order to reduce
> both (human's) operational overhead, AND actual space overhead (i.e
> only allocate (z)swap metadata on-demand).
Let's do it one step at a time.
> 2. This digs us in the hole of supporting a special infrastructure for
> non-writeback cases. Now every future change to zswap's architecture
> has to take this into account. It's not easy to turn this design into
> something that can support writeback - you're stuck with either having
> to do an expensive page table walk to update the PTEs, or shoving the
> virtual swap layer inside zswap. Ugly.
What are you talking about? This patch does not have any page table
work. You are opposing something in your imagination. Please show me
the code in which I do expensive PTE walks.
> 3. And what does this even buy us? Just create a fake in-memory-only
> swapfile (heck, you can use zram), disable writeback (which you can do
> both at a cgroup and host-level), and call it a day.
Well this provides users a choice, if they don't care about write
backs. They can do zswap with ghost swapfile now without actually
wasting disk space.
It also does not stop zswap using write back with normal SSD. If you
want to write back, you can still use a non ghost swapfile as normal.
It is a simple enough patch to provide value right now. It also fits
into the swap.tiers long term roadmap to have a seperate tier for
memory based swapfiles. I believe that is a cleaner picture than the
current zswap as cache but also gets its hands so deep into the swap
stack and slows down other swap tiers.
> Nacked-by: Nhat Pham <nphamcs@gmail.com>
I heard you, if you don't don't want zswap to have anything to do
with memory based swap tier in the swap.tiers design. I respect your
choice.
Chris
next prev parent reply other threads:[~2025-11-22 1:52 UTC|newest]
Thread overview: 58+ 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 [this message]
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
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-01 20:21 ` Barry Song
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='CACePvbUxCN_2fHz0Ds=u52mmOvdhonvRgm6mPdcJcs5qLZj55Q@mail.gmail.com' \
--to=chrisl@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=baohua@kernel.org \
--cc=bhe@redhat.com \
--cc=chengming.zhou@linux.dev \
--cc=gthelen@google.com \
--cc=hannes@cmpxchg.org \
--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