From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-179.mta0.migadu.com (out-179.mta0.migadu.com [91.218.175.179]) (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 194A53F8EB9 for ; Mon, 27 Jul 2026 15:05:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.179 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785164735; cv=none; b=M3T2pc4ID8w6TeNYxygZafVzgJ8agqb3hbD5VXZS35DmJd2r1MrsXWxO9hcH+v3gEiyIUjdQg1jMoW9qdPjZYvEtXpQfGqXVGXmMgZ+7OrRJrT/jlcGq5eZGc4UnqMMFeFKhjgIlG+mdSpedwvWy0sSVRi8/JSokQKFXdfJbDs4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785164735; c=relaxed/simple; bh=zUEqiy6KSGHejh9tzDhL1a6xI7Cv1ERxTT+Jum+RTtk=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=mWjMH1YZCZeBEvYlW+8AYqeze0h6XlE+1wFAYMCZjvO9C+Xq9xYUkV7RLg4x5PoNP4XZl5RDhXuSL7D5ZxvsumQwRI/qtMoT/rjo0aTj7g6Cn2Hk4/gdeoSE54gObDOiYcT0F9YoeoXhLTEbWg1iXEQ79F9GP1SzDchKIeWcwn0= 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=xd5rJZHy; arc=none smtp.client-ip=91.218.175.179 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="xd5rJZHy" Date: Mon, 27 Jul 2026 23:05:24 +0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1785164730; 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=uYBEhiI4kaaYJwSscmEPR9m4XR3pwXHCX7/CBQX9k+Y=; b=xd5rJZHyx8mojleoPNx5doj5TLaJFH+tiAGVeyR2MqWqiCe1Eze5F/VXScxdcCsMa4yrQQ MORoE2NSmFk2Q/C83eZf3qJILs6vUSqCaC7FfK8hQINsGZpcKElcZvSnsn6h4EexrnxCOo bQsRoEIpMP9u1t2wBHmyWTXrb3oOMuk= 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/15/26 at 09:17am, Nhat Pham wrote: > On Wed, Jul 15, 2026 at 7:19 AM Baoquan He wrote: ...snip... > > 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. I took your suggestion to heart. I've been working on the first piece: dynamic cluster management for xswap (vswap) devices — the VM_SPARSE vmalloc approach for growing and shrinking the cluster_info array on demand. The series is 10 patches (plus Chris's xswap base patch) and I just posted it: https://lore.kernel.org/all/20260727135029.1059441-1-baoquan.he@linux.dev/ The idea is simple: instead of allocating the full cluster_info[] at swapon, we back it with a VM_SPARSE vmalloc area that maps physical pages lazily as clusters are allocated, and unmaps them from the tail when enough contiguous free clusters accumulate. Lookup stays O(1) via array indexing — no extra xarray in the cluster access path. Once the dynamic cluster management lands, you'd add the per-slot backend pointer, writeback, and rmap on top — without changing the cluster_info lookup path. The shrink is coarser than what xarray could do (full pages at a time, not individual clusters), but for the initial landing where swap usage tends to be ratchet-like, I think this is a reasonable trade-off. If the need arises, we can always revisit the shrink granularity later. Curious to hear what you think — especially whether this provides the cluster management your VS series needs. Thanks Baoquan > > 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/ > > 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 > believe you can get it done better than I do :) All I'm asking is you > take my concerns into account in your design.