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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <CACePvbUsTjkwYZ+JbDuYDpjsTp9tTScsb3omzLKvAN1nTibxeg@mail.gmail.com>
Date: Wed, 3 Dec 2025 01:01:34 +0400
From: Chris Li <chrisl@...nel.org>
To: Nhat Pham <nphamcs@...il.com>
Cc: Baoquan He <bhe@...hat.com>, Barry Song <21cnbao@...il.com>, Kairui Song <ryncsn@...il.com>, 
	Andrew Morton <akpm@...ux-foundation.org>, Kemeng Shi <shikemeng@...weicloud.com>, 
	Johannes Weiner <hannes@...xchg.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 Tue, Dec 2, 2025 at 9:53 PM Nhat Pham <nphamcs@...il.com> wrote:
> > > Apologies — let me raise a question that may be annoying.
> > > I understand that people may already be feeling tense and sensitive.
> > >
> > > Despite the benefit of compatibility with /etc/fstab, we still need to provide
> > > a physical file on disk (or elsewhere), even if it contains only a header.
> > > Personally, this feels a bit odd to me. Is it possible to avoid having a
> > > “ghost” swap file altogether and instead implement all "ghost" functionality
> > > entirely within the kernel? Ideally, we wouldn’t need to introduce a new
> > > “ghost” concept to users at all.
> > >
> > > In short, we provide the functionality of a ghost swap file without actually
> > > having any file or “ghost” at all.
> >
> > That's actually what I would like to see. Just to make that we may need
> > change syscall swapon, to specify the flag to mark it and initial size.
> > People may complain about adjustment in syscall swapon.
>
> Yeah that's another design goal with virtual swap - minimizing the
> operational overhead.
>
> With my design/RFC, all you need to do is:
>
> 1. Enable zswap at the host level (/sys/module/zswap/parameters/enabled).
>
> 2. Enable zswap at the cgroup level, through memory.zswap.max (you can
> also size per-cgroup zswap limit here, if you so choose).

>From the kernel point of view, managing swap entry without swapfile
poses some challenges.
1) how does the swap_full() and swap cache reclaim work in your world?
Will you create more holes not filling and fragments?
2) Do you internally have only one si->lock? You will  not able to
take advantage of the swap device round robin behavior.

> and it *just works*. Out of the box. No need to create a new swapfile,
That is a user space thing, existing user space tools.
> /etc/fstab, etc.

Able to continue using /etc/fstab is a good thing. Now you are forcing
distros to insert swap on for zswap which do the above init sequence.
It puts more burden on the distro.
That is not the main reason I did not go this route. Mostly I want the
patch to be simple and easy to review. Keep it simple. I see virtual
devices have drawbacks on si->locks and other user space changes
required.

> If you're unsure about your workload's actual zswap usage, you can
> keep it unlimited too - it will just grows and shrinks with memory
> usage dynamics.

How do you cap your swap cache in that case? I feel a lot of
discussion is very hand waving.
Having a landable patch will get more of my attention.

Chris

>
> One design for every host type and workload characteristics
> (workingset, memory access patterns, memory compressibility).