From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-184.mta1.migadu.com (out-184.mta1.migadu.com [95.215.58.184]) (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 04FD93A1A27 for ; Mon, 10 Aug 2026 07:25:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=95.215.58.184 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786346727; cv=none; b=GEkpdedqVSaDrhrs35SH8cN4MDOiFKuUFUq/dvmys/t8paSxfEBPo9lHUUhDalOudqnJdzTCUtlbi1QOUzIVTTv9x4h2THlCWJyUk+UE4wiRrCUwR+ZnZJ0iGhJgkDLYbU+HhCo2jCVoclFq4uL2dV3q9R/KPo11T65J9+8W+so= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786346727; c=relaxed/simple; bh=/67w8XDu1qgQa2ssTsIkkGzmnL/g3kLnk+Fb0eBr710=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=pr18J+UUeH++pie92ly0LQ8enunmGoKJcVXQjrTwE4ifkLO4T3TYTusNYcRCvxowK5ZVyE5QQq+eIiQ3I7d8Q45m5PKPpDEAToLx8/edtjlbI9Rw35iqHBKQTd3JeVQYblRlPOfzZV0Boy6zLfhAY+gQfdvFz2+YyVPGFvNY/Mo= 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=CUjwXl6y; arc=none smtp.client-ip=95.215.58.184 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="CUjwXl6y" Date: Mon, 10 Aug 2026 15:25:07 +0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1786346722; 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=W4ew6lRFtkLA6JTCFVYpe5QpkYXzgq7mhDYzpmtX1sw=; b=CUjwXl6yS8F+/qptE3/yP4p6HUJ/aD2fbpPZKn/k+EvMtr3o7fbrnEhPKipwpnkVFhg5Z1 b9lZ36a5UFpAgGb3xwhKkNypRzHb5VVO8jJ+VXdkDhKZqNL6p19viwA1dzH0H+s34n/amu IXx4mexVtBlx/B3hCdfo92V0R11LOrQ= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Baoquan He To: Youngjun Park Cc: Johannes Weiner , linux-mm@kvack.org, chrisl@kernel.org, nphamcs@gmail.com, kasong@tencent.com, baohua@kernel.org, yosry@kernel.org, david@kernel.org, shikemeng@huaweicloud.com, chengming.zhou@linux.dev, linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH v2 01/10] mm: xswap support for zswap Message-ID: References: <20260805075336.3579395-1-baoquan.he@linux.dev> <20260805075336.3579395-2-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 08/10/26 at 10:49am, Youngjun Park wrote: > On Fri, Aug 07, 2026 at 05:11:05PM +0800, Baoquan He wrote: > > Hi Johannes, > > > > On 08/05/26 at 10:17am, Johannes Weiner wrote: > > > On Wed, Aug 05, 2026 at 03:53:24PM +0800, Baoquan He wrote: > > > > From: Chris Li > > > > > > > > Introduce extendable (virtual) swap device support ??? xswap. > > > > > > > > The current zswap requires a backing swapfile. The swap slot used > > > > by zswap is not able to be used by the swapfile, wasting swapfile > > > > space. > > > > > > > > An xswap device is a swapfile that only contains the swap header, > > > > with the header indicating the size of the virtual swap space. There > > > > is no swap data section, therefore no waste of swapfile space. Any > > > > write to an xswap device will fail. To prevent accidental read or > > > > write, bdev of swap_info_struct is set to NULL. Xswap devices set > > > > the SSD flag because there is no rotational disk access when using > > > > zswap. > > > > > > > > Zswap writeback is disabled if all swapfiles in the system are > > > > xswap devices (tracked via nr_real_swapfiles). > > > > > > > > How to create an xswap device: > > > > touch swap.1G > > > > truncate -s 1G swap.1G > > > > mkswap swap.1G > > > > dd if=swap.1G of=xswap.1G bs=4096 count=1 > > > > # xswap.1G is 4K on disk but reports 1G capacity > > > > swapon xswap.1G > > > > > > Sigh. > > > > > > Why does the user have to go through this dance? > > > > > > Why does the user have to decide in advance what size the space needs > > > to be? > > > > > > You point out no inherent limit to how much can be compressed, so > > > there is no reason to make userspace decide on an arbitrary one. > > > > > > There is no reason to tie an address space that can be managed > > > transparently inside the kernel to TWO named files on disk. > > > > Thanks for looking into this. > > > > The file-based creation dance is there only because this is RFC — > > I wanted to reuse the existing swapon path so the core grow/shrink > > machinery could be measured and tested without also designing a new > > userspace interface. I agree it's not the right final interface. > > > > The direction I'm thinking for the next revision: > > > > - Drop the file requirement entirely. An xswap device has no backing > > store, so there is no reason it needs a file. > > > > - Use totalram_pages as the initial per-device size. Chris suggested > > this, and it's a natural bound: if all anonymous memory is swapped > > out, that is the maximum number of swap entries zswap will ever need, > > assuming a reasonable compression ratio. The hard upper limit could > > be 2 times of system RAM, or the max system RAM memory hotplug can > > add to. > > > > Doing this because we need consider swap.tier support. A single global > > xswap device in swap.tier would mean all memcgs compress into the > > same device — there is only one swap entry namespace. With per-device > > xswap instances, swap.tier can bind different memcgs to different xswap > > devices, giving each its own swap slot namespace. Total isolation on slot > > usage, no cross-memcg interference. > > Hello Baoquan :) Thanks for the thoughtful input, Youngjun. > > Is there concrete user scenario isolation is needed? Hmm, not yet, it just comes from my personal understanding and thinking. I will exlain later. > > > ----- > > Hi Chris, Joungjun, > > Please correct me if I misunderstood the swap.tier concept and xswap > > use case in there.) > > > ----- > > Anysway, if we want to use xswap isolation like below, > > xswap t1 xswap t2 tier1 tier2 > | x1 | | x2 | | dev1 | | dev2 | > > then each memcg may have its own xswap front-end and backing tie > > memcg1: xswap t1 + tier1 > memcg2: xswap t2 + tier2 > > However, with the current tier design, the root cgroup needs to see the > whole tier layout. In that case, I think the root view may become unclear > if there are multiple xswap instances. From the root cgroup point of > view, it may be better to see xswap as one logical tier, not as two > separate tiers. > > For example, the layout could be like this: > > xswap tier tier1 tier2 > | xswap1 xswap2 | | dev1 | | dev2 | Exactly, this is what I am thinking about. Unless we assign each xswap different memory tier or memory type in the future. Otherwise, all xswap instances should share the same tier. > > Then each memcg can have its own mapping or policy: > > memcg1: xswap tier + tier1 (xswap1 + dev1) > memcg2: xswap tier + tier2 (xswap2 + dev2) > > With this model, the root cgroup can keep one simple global view of the > xswap tier. At the same time, each memcg can still use a specific xswap > area and a specific backing swap tier. Exactly. This is what per xswap device is trying to do. > > P.s I am thinking about multiple xswap usecase on tier. > (this is just mind map. I don't know whether it is right or not) > > Another possible layout may be to use xswap as a RAM buffer for each > tier > > tier1 tier2 > | xswap + fast dev | | xswap + slow dev | > > We can use xswap as a simple buffering layer? > In that case, we would need a clear policy > for how xswap is assigned to each tier, and how the backing swap device is > selected for each tier. I may not get your point. Do you mean kernel will decide how to assign each xswap to tier and how to select back device via policy, but not user? > > So why I am saying this is that, > if xswap is managed as part of swap tiers, it would > be helpful to define a more concrete layout and policy for xswap > assignment. > > This would make the isolation use case much clearer Here let me explain why I think per-device xswap is the right starting point. The primary scenario I have in mind is cloud environments where different containers need different swap tier chains: memcg A (latency-sensitive service): xswap-A → NVMe tier (fast writeback, small capacity) memcg B (batch processing): xswap-B → HDD tier (slow writeback, large capacity) memcg C (best-effort): xswap-C → no backend (compression only, never write to disk) With a single global xswap, all three memcgs share the same backend. If memcg B triggers heavy writeback to HDD, memcg A's swap-in path is unaffected in the IO sense, but the shared slot namespace means A and B compete for swap entries. Per-device xswap gives each its own slot pool and its own backing device — full isolation. Beyond IO and slot isolation, per-device xswap also makes per-memcg swap statistics straightforward: slot usage, compressed page count, and writeback throughput are naturally scoped to each device. Futhermore, the existing swap subsystem is already per-device — each swapon allocates an independent swap_info_struct with its own cluster table, slot namespace, statistics, and teardown path. Per-device xswap inherits all of this for free: - Slot allocation via the existing per-CPU cluster allocator (no new locking) - Per-device statistics already exposed in /proc/swaps and sysfs - Device lifecycle via swapon/swapoff with no new management interface - swap.tier naturally binds tiers to per-device instances Thanks Baoquan