From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-187.mta1.migadu.com (out-187.mta1.migadu.com [95.215.58.187]) (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 4E70E418A58 for ; Fri, 17 Jul 2026 14:27:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=95.215.58.187 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784298434; cv=none; b=ZIQ6WhxwEMqhaVd/pbX98U/MsA57QekE6XM4G6k6XamUnPu3Yh8lU7rUrF27M6Qbw5yldoTUbDrVb4UAMgXSivYdLJ5R5gEDndKnB1UWPZ4L1P3Onfr5Rb+uSN0fz0iXJNRUFdoRa9g6JMZ/KwIxa4FNnVmlV+bmgSjTeBTo2ig= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784298434; c=relaxed/simple; bh=6i9WQe9sEmQRREuga690uEB0erpcbJm2/PpoSXsfj4k=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=ZXBainqKTwEsEBs606oNXfDjP1uBOlkxqfrxF2TffPflVFZtcKJTf7y+VexHJwgGRISEOxqmGVLmAO1/FRs12V40s9KuvahN3iq3/K60nLAL9/wor7KI2T9h1mIph24227Um9ozwgSDNXgkNeZSQNEkWkXu3+ry1CPiw0dqMnW0= 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=C6Yr8VoP; arc=none smtp.client-ip=95.215.58.187 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="C6Yr8VoP" Date: Fri, 17 Jul 2026 22:27:02 +0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1784298430; 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=JwUlLLKebphfCZUI9OSd5TG1SsZvmuLzd82pDv18lMs=; b=C6Yr8VoPlS770QJmaqAuRHD/59NVlN8Si9z7X7ViOB5SCH29GsqRZnrhM3MUgM1LjfvsGR TbmRSEQYunl/+F6l1kGJPnzq/8BS4ZVfxLZaGb7C+4CSSf06FckT+ztdos9Vh+8dJDRHcI ZNXv+TgO5D5vwjtx1bi1KLcQebsetUQ= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Baoquan He To: Nhat Pham Cc: Chris Li , linux-mm@kvack.org, akpm@linux-foundation.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 On 07/16/26 at 09:49am, Nhat Pham wrote: > On Wed, Jul 15, 2026 at 4:04 PM Chris Li wrote: > > > > On Wed, Jul 15, 2026 at 9:18 AM Nhat Pham wrote: > > > > > > On Wed, Jul 15, 2026 at 7:19 AM Baoquan He wrote: > > > > > > > > On 07/15/26 at 07:21pm, Baoquan He wrote: > > > > > 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. > > > > > > Yes, it's a big patch series. But as you pointed out earlier, it > > > solves a larger problem with a single coherent design :) > > > > > > > > > > > > > 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 > > > > > > The problem is not the lack of writeback support per se. I understand > > > that sometimes pieces of a design can be deferred to a follow-up patch > > > series. > > > > > > I'm more concerned that the ghost direction so far does not seriously > > > take it into account in the design at all, which might make it either > > > impossible or very hard to redesign around down the line. I don't want > > > to rip a huge chunk of it out down the line later - we just avoided it > > > with the swap table with Kairui's proposal. > > > > > > > > > > > Part of above sentence is missing. I meant if you agree on the ghost > > > > solution, you can change to take its way and continue, just add me to > > > > CC. Or we can work together. > > > > > > How about this - let's solve one piece of the puzzle together, one at a time. > > > > > > First, your optimization patch series. Have you taken a look at my > > > proposal ([1])? I believe that design should be cleaner, while still > > > allowing you to put it all you want to get (elimination of xarray > > > being the chief benefit), without requiring you to modify swap cache > > > and swap count operations (since you don't have to move the metadata > > > in and out of struct zswap_entry). It does require a bit more code to > > > dynamically allocated the backend array, but should be trivial IMHO. > > > > > > [1]: https://lore.kernel.org/all/CAKEwX=OvR7GbU_9f2h_MtU4m0g6s-esHmNQKYNhJz610M0P3Sw@mail.gmail.com/ > > > > Hi Nhat, > > > > Sorry for the late reply. I've been busy and just saw this. First > > impression looks promising, it is better than any previous version of > > VS. Thanks for incorporating Kairui's feedback. Please give me some > > time to sleep on it. I will get back to you on that. > > Please take a look. I was waiting for your response as well :) > > The patch series is large, yes, but it's an RFC meant to show case the > final end design. > > > > > > Next, if you just want pure ghost swapfile without writeback support, > > > maybe something similar to the first 2 patches in my RFC? i.e up to > > > this patch: > > > > > > https://lore.kernel.org/all/20260612193738.2183968-3-nphamcs@gmail.com/ > > > > > > I'm sure you could find issues/bugs in it too with some extensive > > > testing (a lot of my performance testing is done on the entire series > > > as a whole), but from a design point of view it should achieve what us > > > both want, no? It's literally just a ghost swap device - most of the > > > other design elements of vswap (the new charging behavior, rmap, > > > support for writeback) comes in latter patches. I think the difference > > > is: > > > > > > 1. It's transparently dynamic, whereas in your RFC it's driven by a > > > userspace knob. Do you think there are inherent values in a userspace > > > knob? > > > > > > 2. The address space can also shrink when swap usage drops at runtime. > > > > > > 3. The dynamic address space is backed by an xarray. Note that it's > > > structured differently than zswap's one (it's an xarray pointing to > > > clusters). If you have rationales or numbers to show that vmalloc > > > array is superior (while still support the kernel-driven expansion and > > > shrink), please let me know. > > > > > > If you have no faith in me and do not like my code, you can take the > > > code as a starting point, or just the idea, and drive it yourself. Or > > > let me know if you're unhappy with any piece of it - we can discuss > > > further. > > > > > > > > > > > > Otherwise, please continue to push virtual swap forward. I'll stop and > > > > > wait. > > > > > > Look man, I care about the problems being solved and I'm a sucker for > > > good ideas, but I'm not married to anything, be it my code or my > > > ideas. > > > > > > I have literally dropped my old code and adopted Kairui's suggestions > > > after playing with it and liking it, to make sure every party's > > > concern is met. > > > > > > If you have concerns, please let me know, or keep sending code if you > > > > May I add one wishlist item related to ghost swapfile here? I will > > reply to your VS thread for other feedback. > > > > For the ghost swapfile usage case (no writeback). Can VS support this > > usage case while maintaining per-swap-slot metadata usage comparable > > to the ghost swapfile implementation? If we have to put a number to > > it, let's say the increase in metadata is less than 1 byte per swap > > slot compared to the ghost swapfile implementation. > > > > We have large deployments of ghost swapfile in the fleet. I want an > > upstream aligned solution that does not increase the existing memory > > overhead compared to the current ghost swapfile deployment, for that > > usage. As you know, memory pricing and optimization pressure are high. > > The ghost swapfile patch itself is relatively simple. If VS can > > address this usage case, it will remove a lot of incentive to explore > > ghost swapfile-like solutions. > > Hi Chris. I have some thoughts on this - let me know what you think. > > I understand the memory overhead discussion here. In the case where > vswap slot is backed by a real swapfile, I have not figured out a way > to make the overhead disappear yet. The damn rmap is very annoying - I > have some strategies to get around it for certain operations, but none > of it can be done without a full fledged patch series of its own. > > However, with the ghost zswap swapfile backend specifically, I think > the overhead is going to be negligible compared to the status quo > upstream (things might be different internally at Google - please let > me know!). This is because the main remaining per-slot overhead comes > in the form of one per-cluster array to store the "backend", here it's > going to store struct zswap_entry pointers. This is not extra overhead > though, because it basically replaces the xarray (that you added all > those years ago)! > > The rest is small stuff here and there that is not O(slot) but rather > O(cluster). For example one struct rcu_head per cluster, xarray > overhead for the dynamicization - note that this xarray manages > cluster, not slot. I think that's all, unless I miss something. > > So if you don't writeback, i.e no physical swapfile, then I think > there is negligible overhead (no rmap and all that jazz). > > Does this sound acceptable to you? > > Baoquan, what do you think? Thanks for the thoughtful reply and the very constructive proposal. Your suggestion about moving forward in small, incremental steps in last mail is really appealing — I think that's the right way to make progress on this. I need a little time to think it through more carefully before giving you a proper response. Will get back to you soon. Thanks Baoquan