Message-ID: <56507d9b9210ef5f67715b81efd96fd809021a44.camel@surriel.com>
Date: Wed, 26 Nov 2025 21:34:17 -0500
From: Rik van Riel <riel@...riel.com>
To: Chris Li <chrisl@...nel.org>
Cc: Yosry Ahmed <yosry.ahmed@...ux.dev>, Johannes Weiner
 <hannes@...xchg.org>,  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>, 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 Thu, 2025-11-27 at 06:07 +0400, Chris Li wrote:
> On Thu, Nov 27, 2025 at 1:59 AM Rik van Riel <riel@...riel.com>
> wrote:
> > 
> > On Tue, 2025-11-25 at 22:50 +0400, Chris Li wrote:
> > > 
> > > > - We still cannot do swapoff efficiently as we need to walk the
> > > > page
> > > >   tables (and some swap tables) to find and swapin all entries
> > > > in a
> > > >   swapfile. Not as important as other things, but worth
> > > > mentioning.
> > > 
> > > That need rmap for swap entries. It It is an independent issue.
> > > 
> > 
> > Wouldn't rmap for swap entries be more expensive than
> > simply always having indirection for swap entries that
> > are in use?
> 
> It might be, to be frank. I consider this pretty far and late in the
> stage of the game to evaluate the rmap and its alternatives. Do you
> agree?
> 
> I might or might not try the rmap for swap entry. Right now I don't
> have many data points nor insights.

On the contrary. I think we should at least do some
back of the envelope calculations to estimate the
overhead of the different proposed solutions.

With both Nhat's vswap, and your proposal to always
have swap indirection with a separate front end, and
several back ends, there is no need for swap rmap.

This is a good thing, because a single swap slot
could be referenced by dozens, hundreds, or even
thousands of page table entries, in the case of
forking servers. This creates complexity which is
probably best avoided.

Conceptually, Nhat's vswap, and your idea of having
always-on swap indirection seem to be the same thing.
> 
> > This sounds like an uncommon scenario, but it is
> > functionally identical to what is done to pages
> > during zswap writeback, where the page table entries
> > stay unchanged, and the swap page is simply moved
> > to another backend location.
> > 
> > Why implement two things, when we can have one
> > thing that does both, with no extra complexity
> > over what zswap writeback needs?
> 
> Let me ask you a clarifying question, then.
> 
> 1) What exactly are you trying to propose here in what project? VS or
> swap the pony?

In the past, when faced with competing code bases
like this, one thing that has worked well is for both
developers to send their code to the list, and then
for both developers to send each other suggestions
(or diffs) to improve each other's code.

Vswap and your always-on indirection seem to do
exactly the same thing. This seems like a good
opportunity to work together, and come up with
code that is better than any one person's code.

> 2) What stage of the code change do you have in mind should this
> change apply to?

I think it makes sense to get the hard design
problems resolved before committing to one
particular code design.

Spending months to resolve subtle bugs in a
code base, only to discover later that it does
not do exactly what is needed, is not the
greatest way to make progress.

> 
> I can't speak for VS,  I am open to embrace what you suggest in order
> to swap the pony project, that is after I understand it first.
> 
Once both Nhat and you understand each other's code,
and have suggestions for each other on how to improve
it, we will likely end up with a code base that looks
nicer than either of you would have done by yourselves.

The more perspectives, the better.


-- 
All Rights Reversed.

Powered by blists - more mailing lists