Message-ID: <20251202170222.GD430226@cmpxchg.org>
Date: Tue, 2 Dec 2025 12:02:22 -0500
From: Johannes Weiner <hannes@...xchg.org>
To: Kairui Song <ryncsn@...il.com>
Cc: linux-mm@...ck.org, Chris Li <chrisl@...nel.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 02, 2025 at 03:49:22AM +0800, Kairui Song wrote:
> From my perspective, Chris did co-developed, suggested, reviewed or
> authored many of the implementation details around the swap-table
> idea, and he implemented the swap cluster allocator in 6.11, which
> unlocked a bunch of follow-on optimizations.
> 
> I’ve been working on swap for a while as well and have rewritten and
> refactored large parts of the swap, swap allocator and swap cache
> (mm/swapfile.c, mm/swap_state.c, swap.h, swap_table.h). Maybe, yeah,
> I’m not a kernel vet with decades of patches yet, but I do think I'm
> familiar enough with swap. I think Chris' work, words or code, has
> been looking good in the end results.

I have absolute respect for your work. And if you say Chris was
instrumental to getting it done, I will take your word for it.

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

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.

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.

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.

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

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.

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.

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

Powered by blists - more mailing lists