From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lgeamrelo03.lge.com (lgeamrelo03.lge.com [156.147.51.102]) (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 3FA41329E6C for ; Wed, 25 Mar 2026 18:36:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=156.147.51.102 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774463815; cv=none; b=g4jFX3p46KglrCwxqb+1v/D0AInTeAyPsfIebBWjV9dsox9kTfDk5P6wkvRIkZwBhhNJ1ybi0P2pes6KWGIO7lDzmUjFQSFfCSQgR7iuxIx+P+SOrbhyNnGwPuyzgw4DnvoGNcl5Sxu1EjWyQCSS6Z3ILSZQsPZjyE1g91csiv8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774463815; c=relaxed/simple; bh=caD87+u92zEtkpCjBqLx1b1xohIodhH4i7hTlROlaGc=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=lFcVyhXzQ+Wy4McbbHY6eRiQrAKQxK6qdNrpG4L/5qN4REPuu6uUrNd2NPeRya2nm3wktDYDxs/686G2lSNEJWMxiInIIFM8144MMind6RVCBJXSwaMtMDOgrAVfSkIN1krIhMk4Yk2FKesaivTpviFjX8bJgT+B7vnF0GIP7Co= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=lge.com; spf=pass smtp.mailfrom=lge.com; arc=none smtp.client-ip=156.147.51.102 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=lge.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=lge.com Received: from unknown (HELO yjaykim-PowerEdge-T330) (10.177.112.156) by 156.147.51.102 with ESMTP; 26 Mar 2026 03:36:49 +0900 X-Original-SENDERIP: 10.177.112.156 X-Original-MAILFROM: youngjun.park@lge.com Date: Thu, 26 Mar 2026 03:36:49 +0900 From: YoungJun Park To: Nhat Pham Cc: kasong@tencent.com, Liam.Howlett@oracle.com, akpm@linux-foundation.org, apopple@nvidia.com, axelrasmussen@google.com, baohua@kernel.org, baolin.wang@linux.alibaba.com, bhe@redhat.com, byungchul@sk.com, cgroups@vger.kernel.org, chengming.zhou@linux.dev, chrisl@kernel.org, corbet@lwn.net, david@kernel.org, dev.jain@arm.com, gourry@gourry.net, hannes@cmpxchg.org, hughd@google.com, jannh@google.com, joshua.hahnjy@gmail.com, lance.yang@linux.dev, lenb@kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-pm@vger.kernel.org, lorenzo.stoakes@oracle.com, matthew.brost@intel.com, mhocko@suse.com, muchun.song@linux.dev, npache@redhat.com, pavel@kernel.org, peterx@redhat.com, peterz@infradead.org, pfalcato@suse.de, rafael@kernel.org, rakie.kim@sk.com, roman.gushchin@linux.dev, rppt@kernel.org, ryan.roberts@arm.com, shakeel.butt@linux.dev, shikemeng@huaweicloud.com, surenb@google.com, tglx@kernel.org, vbabka@suse.cz, weixugc@google.com, ying.huang@linux.alibaba.com, yosry.ahmed@linux.dev, yuanchu@google.com, zhengqi.arch@bytedance.com, ziy@nvidia.com, kernel-team@meta.com, riel@surriel.com Subject: Re: [PATCH v5 00/21] Virtual Swap Space Message-ID: References: <20260320192735.748051-1-nphamcs@gmail.com> Precedence: bulk X-Mailing-List: linux-doc@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260320192735.748051-1-nphamcs@gmail.com> On Fri, Mar 20, 2026 at 12:27:14PM -0700, Nhat Pham wrote: > > This patch series is based on 6.19. There are a couple more > swap-related changes in mainline that I would need to coordinate > with, but I still want to send this out as an update for the > regressions reported by Kairui Song in [15]. It's probably easier > to just build this thing rather than dig through that series of > emails to get the fix patch :) Hi Nhat, I wanted to fully understand the patches before asking questions, but reviewing everything takes time, and I didn't want to miss the timing. So let me share some thoughts and ask about your direction. These are the perspectives I'm coming from: Pros: - The architecture is very clean. - Zero entries currently consume swap space, which can prevent actual swap usage in some cases. - It resolves zswap's dependency on swap device size. - And so on. Cons: - An additional virtual allocation step is introduced per every swap. - not easy to merge (change swap infrastructure totally?) To address the cons, I think if we can demonstrate that the benefits always outweigh the costs, it could fully replace the existing mechanism. However, if this can be applied selectively, we get only the pros without the cons. 1. Modularization You removed CONFIG_* and went with a unified approach. I recall you were also considering a module-based structure at some point. What are your thoughts on that direction? If we take that approach, we could extend the recent swap ops patchset (https://lore.kernel.org/linux-mm/20260302104016.163542-1-bhe@redhat.com/) as follows: - Make vswap a swap module - Have cluster allocation functions reside in swapops - Enable vswap through swapon I think this could result in a similar structure. An additional benefit would be that it enables various configurations: - vswap + regular swap together - vswap only - And other combinations And merge is not that hard. it is not the total change of swap infra structure. But, swapoff fastness might disappear? it is not that critical as I think. 2. Flash-friendly swap integration (for my use case) I've been thinking about the flash-friendly swap concept that I mentioned before and recently proposed: (https://lore.kernel.org/linux-mm/aZW0voL4MmnMQlaR@yjaykim-PowerEdge-T330/) One of its core functions requires buffering RAM-swapped pages and writing them sequentially at an appropriate time -- not immediately, but in proper block-sized units, sequentially. This means allocated offsets must essentially be virtual, and physical offsets need to be managed separately at the actual write time. If we integrate this into the current vswap, we would either need vswap itself to handle the sequential writes (bypassing the physical device and receiving pages directly), or swapon a swap device and have vswap obtain physical offsets from it. But since those offsets cannot be used directly (due to buffering and sequential write requirements), they become virtual too, resulting in: virtual -> virtual -> physical This triple indirection is not ideal. However, if the modularization from point 1 is achieved and vswap acts as a swap device itself, then we can cleanly establish a: virtual -> physical relationship within it. I noticed you seem to be exploring collaboration with Kairui as well. I'm curious whether you have a compromise direction in mind, or if you plan to stick with the current approach. P.S. I definitely want to review the vswap code in detail when I get the time. great work and code. Thanks, Youngjun Park