Message-ID: <CACePvbXn3DbFbVSdqk2GUU422HhZN0ALrvsHVeT2B+vMCDgR-Q@mail.gmail.com>
Date: Wed, 3 Dec 2025 00:48:21 +0400
From: Chris Li <chrisl@...nel.org>
To: Johannes Weiner <hannes@...xchg.org>
Cc: Kairui Song <ryncsn@...il.com>, linux-mm@...ck.org, Nhat Pham <nphamcs@...il.com>, 
	Rik van Riel <riel@...riel.com>, Andrew Morton <akpm@...ux-foundation.org>, 
	Kemeng Shi <shikemeng@...weicloud.com>, Baoquan He <bhe@...hat.com>, 
	Barry Song <baohua@...nel.org>, Yosry Ahmed <yosry.ahmed@...ux.dev>, 
	Chengming Zhou <chengming.zhou@...ux.dev>, YoungJun Park <youngjun.park@....com>, 
	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:02 PM Johannes Weiner <hannes@...xchg.org> wrote:
> > It's hard to put a penthouse on a sandcastle, and maybe that's the
> > reason makes it hard to describe or layout the further implementations
> > of swap.
>
> Sure, I can understand that. However, I think the conflict is not
> necessarily about implementation strategy, it's about priorities.

Right, that is why we take the more incremental approach. Cleanup and
simplify the swap code in order to make later stage things happen.

> We have a usecase. We have a functional implementation that satisfies
> this usecase. It was sent as RFCs early on to gain consensus on the
> direction and find the best tradeoffs wrt other usecases. These RFC
> threads are the place to voice concerns and influence direction.

Speak of priority. We have a more priority approach by incrementally
landing code. The priority reflects that we are actually landing code,
improving it towards that glorified goal.

I have already expressed concern and the 2023 LSF swap abstraction
talk the community already picked the winner. Not the one VS is based
on. Rebooting that without addressing the previous concern is a waste
of everybody's time. You basically say the community picks the wrong
one. Let's retry again.

> Both Chris and you have stated that further swap table work *may* also
> enable this usecase. However, at this time, I think it's also fair to
> say that it's more of an afterthought, and no concrete design or code
> for how this would actually look like has been proposed. High-level
> ideas have been floated, but as you can see from Nhat, Rik's, Yosry's
> and my replies, they don't really meet the necessary requirements.

The VS doesn't meet the requirement of upstream and other companies
that do not unnecessarily blow up the kernel memory usage. One fight
at a time, sorry I have to get the VS out of the way before I comment
on other aspects of this patch.

> This is not some principled stance. The virtual swap patches are
> difficult to develop, especially given the current rate of change of
> the underlying swap codebase. If anybody working on vswap had seen a
> plausible way to solve these issues through incremental swap table
> improvements they would have jumped on it a long time ago.
>
> It's more about priorities. Combining compression with disk swap is
> extremely powerful, because it dramatically reduces the worst aspects
> of both: it reduces the memory footprint of compression by shedding
> the coldest data to disk; it reduces the IO latencies and flash wear
> of disk swap through the writeback cache. In practice, this reduces
> *average event rates of the entire reclaim/paging/IO stack*.
>
> These are higher-order overhead savings that are difficult to beat
> with first-order descriptor and lookup cost optimizations.
>
> We obviously want to have both, but they are orthogonal goals. You can
> see how it doesn't make sense for us to deprioritize the former for
> the latter, or why Nhat says it's an apples to oranges comparison.

My advice is that, make it incremental, come up with production
quality solutions.  Adding one layer of XArry to redirect is easy. The
hard part is how to keep the memory usage in check and perform well.
The posted VS will give you false illusion of progress because it
doesn't have a clear way to address the performance and memory usage
problem which can meet the production quality requirement for
upstream. The upstream kernel is not a toy kernel.

> It also won't work for one party to say "we will fix this, give us
> time". Everybody wants to advance the thing they primarily care about

Exactly, the same applies to VS. Even if I can spend the time
convincing you the grant vision and you are buying it. Who guarantees
that vision can be implemented without the surprise black swan
assumption that set us back to the drawing board? So landing the
actual improvement is the king. That is the real progress. If your
team want to get the result sooner, helping swap table landing would
speed up your goal. Once the code base is cleaned up. It is much
easier to move in ANY direction.

> with the least amount of detours. That's where we have to find
> compromise. Either let people pursue what's most important to them, or
> lay out an encompassing design to build consensus and organize effort.

This is just a development methodology, a personal choice. That is why
the swap table is landing as of now.

> And yes, let's please stay technical and on-topic in these
> discussions. Let's acknowledge we have interests that overlap, and
> interests that do not. Then find ways to service everybody's usecases.

Yes, I agree.

> Disagreements are part of the game. There is no need to get personal,
> pull rank, or make accusations to dismiss somebody else's clearly
> stated usecase, perspective, or objections.

Also agree.
>
> The best way to avoid this is to make technical statements, and reply
> with technical responses where those statements are made.

Yes, exactly. That is why I want to get a straight answer about the VS
slot overhead number. Writing a grant design doc is a much bigger
task.  It will put non native English speakers at a disadvantage for
writing the big design docs. A lot of us don't have the luxury of
contributing to the upstream as a day job, me included. We do it in
our spare times because we love it.

Chris

Powered by blists - more mailing lists