linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Nhat Pham <nphamcs@gmail.com>
To: Chris Li <chrisl@kernel.org>
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 10:19:18 +0000	[thread overview]
Message-ID: <CAKEwX=PQM_4Mp75R4yeQ=WoqOxj7EJK=FpgcemNSYDS3fLXQLw@mail.gmail.com> (raw)
In-Reply-To: <20251121-ghost-v1-1-cfc0efcf3855@kernel.org>

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).

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.

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.

Nacked-by: Nhat Pham <nphamcs@gmail.com>


  reply	other threads:[~2025-11-21 10:19 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 [this message]
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
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='CAKEwX=PQM_4Mp75R4yeQ=WoqOxj7EJK=FpgcemNSYDS3fLXQLw@mail.gmail.com' \
    --to=nphamcs@gmail.com \
    --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=hannes@cmpxchg.org \
    --cc=kasong@tencent.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --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