linux-kernel - Re: [PATCH RFC] mm: ghost swapfile support for zswap

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CACePvbXXDaOY-E-nZ3n44w0StBc=n59+v5V-X2fw-V+roH=Qyw@mail.gmail.com>
Date: Fri, 21 Nov 2025 17:52:09 -0800
From: Chris Li <chrisl@...nel.org>
To: Johannes Weiner <hannes@...xchg.org>
Cc: Andrew Morton <akpm@...ux-foundation.org>, Kairui Song <kasong@...cent.com>, 
	Kemeng Shi <shikemeng@...weicloud.com>, Nhat Pham <nphamcs@...il.com>, 
	Baoquan He <bhe@...hat.com>, Barry Song <baohua@...nel.org>, Yosry Ahmed <yosry.ahmed@...ux.dev>, 
	Chengming Zhou <chengming.zhou@...ux.dev>, linux-mm@...ck.org, linux-kernel@...r.kernel.org, 
	pratmal@...gle.com, sweettea@...gle.com, gthelen@...gle.com, 
	weixugc@...gle.com
Subject: Re: [PATCH RFC] mm: ghost swapfile support for zswap

On Fri, Nov 21, 2025 at 3:40 AM Johannes Weiner <hannes@...xchg.org> wrote:
>
> On Fri, Nov 21, 2025 at 01:31:43AM -0800, Chris Li 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.
>
> Zswap is primarily a compressed cache for real swap on secondary
> storage. It's indeed quite important that entries currently in zswap
> don't occupy disk slots; but for a solution to this to be acceptable,
> it has to work with the primary usecase and support disk writeback.

Well, my plan is to support the writeback via swap.tiers.

> This direction is a dead-end. Please take a look at Nhat's swap
> virtualization patches. They decouple zswap from disk geometry, while
> still supporting writeback to an actual backend file.

Yes, there are many ways to decouple zswap from disk geometry, my swap
table + swap.tiers design can do that as well. I have concerns about
swap virtualization in the aspect of adding another layer of memory
overhead addition per swap entry and CPU overhead of extra xarray
lookup. I believe my approach is technically superior and cleaner.
Both faster and cleaner. Basically swap.tiers + VFS like swap read
write page ops. I will let Nhat clarify the performance and memory
overhead side of the swap virtualization.

I am not against swap entry redirection. Just the swap virtualization
series needs to compare against the alternatives in terms of memory
overhead and throughput.
Solving it from the swap.tiers angle is cleaner.

> Nacked-by: Johannes Weiner <hannes@...xchg.org>

I take that the only relevant part is you are zswap maintainer and I
am the swap maintainer. Fine. I got the message. I will leave the
zswap alone. I will find other ways to address the memory base swap
tiers in swap.tiers.

Chris