From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-188.mta1.migadu.com (out-188.mta1.migadu.com [95.215.58.188]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 512DB437853 for ; Wed, 15 Jul 2026 11:21:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=95.215.58.188 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784114519; cv=none; b=O8vW1DaoxZL0gn2mYlNihW+aAKGk7jyk6VhI6kZfNz6UHgLNdP47NBawXmcW8dOCGQAO4/ZTkKR9TeNOr41FN2KGYqM+whKh8KTXlQQ69WmlB8OgrkWxGSeW7hRZ61jxawkyQRfcZYEe4N7O6b6+2mlbBJOEGlUuWlXAr/BTU00= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784114519; c=relaxed/simple; bh=PfS9rL8zu0tzslBD3y4XoeuyDgoeL3znZpWBu2B2v8o=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=AMon6Ncz+8R1cygFFwzrMI7kKuwU9xf7Rp2rPuNeL7j/MZweF8DXFZ2VIaGEfhYWYtiV+pCD+hlM1Lh6dTUA5RcCvEmGHTaC9s4a6XaOjR5XuK3857oEzoDjnhq4xUzvOdYr1SU0AYVktHXituPzSUZRV4NyFyDnoNezLKAaSoA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=r3Q4haA0; arc=none smtp.client-ip=95.215.58.188 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="r3Q4haA0" Date: Wed, 15 Jul 2026 19:21:47 +0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1784114515; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=vuZDUV79ZgTnqtJKP5GUBOq9cZrf3SO80INLa2FcDD0=; b=r3Q4haA0HFuVl2emqUbDWIJ8/hC/gXaScj3Bw8OCGRSI5k2pNKOJw6thAY1RNIzWkgQ7ay NUnBoZLvcJFVnTEqo0qR63zh5GvdwBZh4gCnbIi92JUuI785/LSEQ1soPPuy0kDFN9I9eF 7ZADhA4EA4fWjw50DaDKkryssDljCnE= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Baoquan He To: Nhat Pham Cc: linux-mm@kvack.org, akpm@linux-foundation.org, chrisl@kernel.org, kasong@tencent.com, shikemeng@huaweicloud.com, baohua@kernel.org, youngjun.park@lge.com, hannes@cmpxchg.org, yosry@kernel.org, chengming.zhou@linux.dev, linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH 00/10] mm/swap: ghost swapfile with backend switching via Redirect entries Message-ID: References: <20260707082614.95030-1-baoquan.he@linux.dev> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Migadu-Flow: FLOW_OUT Hi Nhat, On 07/12/26 at 05:02pm, Nhat Pham wrote: > On Thu, Jul 9, 2026 at 4:39 AM Baoquan He wrote: ...snip... Sorry, I won't reply to each comment individually. I'll just leave a summary reply at the end. > > I think VSS goes beyond solving the "zswap without backing store" > > problem — it is fundamentally an architectural restructuring of the > > swap subsystem, with virtual swap as a first-class abstraction layered > > above physical devices. That is both its strength (comprehensive, > > future-proof) and its trade-off (more invasive to existing paths). > > I respect that. > > > > My goal with ghost swap is different: address the immediate pain point > > with the smallest possible change to the existing infrastructure. Both > > approaches have value, and I hope the community discussion will help > > identify the right balance. > > That's because I believe "zswap without backing store" just by itself > is a bit narrow of a problem. It's certainly nice to fix, but it's > more of a nuisance - you already have userspace hacks for it (as I > mentioned above). > > The problem I'm trying to solve is to support: > > 1. Writeback. > > 2. Dynamicity. > > 3. Decoupled backends. > > all of which are motivated by real production issues, not some > theoretical problems. I'm concerned that if we only focus on the third > goal, we'll dig ourself into a hole that prevents us from solving 1 > and 2 efficiently down the line. > > > > > Thank you again for the detailed review — it has already clarified > > which parts of the design need more thought and documentation, and will > > make the next version stronger. > > I really don't want to be antagonistic, but I hope you'd take the real > production pains that we've had (and have tried to communicate in > multiple mailing threads, across a timeline of almost 2 years at this > point) seriously. > > Collaborations should go both ways. I've gone out of my way to try to > address the concerns of various parties, from spending *multiple > weeks* testing and investigating performance regression on zram > backend (which my company does not use), to a rewrite/re-design of > virtual swap to accommodate parties who wished to opt out of virtual > swap for now. > > I hope you can extend the same good will to our needs :) I've included > you (and other swap folks such as Chris and Kairui) in my cc-lists. If > you have concerns, you could have commented. Instead, you decided to > send a patch series, which is basically just the ghost swapfile, with > a bit of afterthought to handle writeback and dynamicity, rather > inefficiently (no dedicated per-CPU caching), and not even correctly > (the lack of rmap means swapoff / swap-cache-only physical swap slot > reclaim is broken). > > I respect you and Chris very much to assume bad faith, but please work > with me rather than against me. Before I get into the technical discussion, I want to address something you raised at the end of your reply — the concern that I'm working against you rather than with you. Our paths in MM simply haven't crossed much until now. I can't think of reason why I would want to target you or your work. I respect the work you've put into VSS. I did check it. Honestly I am not fan of it. In your v2: 2244 insertions, 250 deletions, 15 files touched, a new 455-line header (vswap.h). While swap subsystem has just absorbed the swap table series. Then another 2200 lines of architectural restructuring on top is added. Not sure if anybody raise concern about your solution, or anybody suggests other directions. I posted ghost swap because I saw a concrete, narrow problem that I believed could be solved with a small change. It makes decoupling and dynamic growth with the minimum possible mechanism. Writeback is explicitly deferred — not because it's unimportant, but because it's a separate problem that shouldn't block the common case. With my shallow knowledge, it's optimal solution to the encountered problem. If you agree, you can change to Otherwise, please continue to push virtual swap forward. I'll stop and wait. Thanks Baoquan