From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-189.mta0.migadu.com (out-189.mta0.migadu.com [91.218.175.189]) (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 371D835CB87 for ; Fri, 12 Jun 2026 17:02:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.189 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781283773; cv=none; b=EKTkhMyj6lDwpBpThZBObFVa5iguRs5Hap09PuLI/X5xFQctqzR69te6VejfieGtjuKZO884Dc7b4O6cqroCxyH+HO971S9jY2G0bjxKs9GWf9tx4Pkkp2alnjEYpu7ziAeWeXD3OnsgJ5Hxicees1Dl2ms4i2+FHHUKc+t9Dsc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781283773; c=relaxed/simple; bh=rVF90EP1feFJnWkM+FhLRS8x6Ybtmejaz1+0rZsoFC0=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=nXV56xFXkbRKrYrz1BHNrcO4QTO4/W8D/801s4AC/368LWZKlYCOiIerLaGT2kP/9Rux4ValUlb+kzdJKI1UuDKguUBevS6igcKnWAbIEQlM8k2iANVrokjczYmAsoIO2YHeQaWsLK7N87z6go7fWayCQ8t1ToqmkGM3bxYa7tE= 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=RhEx3Z8V; arc=none smtp.client-ip=91.218.175.189 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="RhEx3Z8V" Date: Fri, 12 Jun 2026 10:02:32 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1781283758; 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: in-reply-to:in-reply-to:references:references; bh=laE9N/rFk+g9gKLRRTmV/tr2adDTNsrG3i/u6WEqO7E=; b=RhEx3Z8Vm6DEMJrxApUrLKFqec7yFZPSFbWMn6B5zFYlCj/RA80FMvDLq9p5vbYGkxVIMa 0fPXY/x086T9BPWkMYW1P4Qo18Dotxg0tKyrVhsW4se5N46soreQ7svztZze2OhzHzpOYY Lai1OdzrkJzn0lqBQ87JQdCdx4uH498= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Shakeel Butt To: YoungJun Park Cc: Yosry Ahmed , Hao Jia , Johannes Weiner , mhocko@kernel.org, tj@kernel.org, mkoutny@suse.com, roman.gushchin@linux.dev, Nhat Pham , akpm@linux-foundation.org, chengming.zhou@linux.dev, muchun.song@linux.dev, cgroups@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, Hao Jia , chrisl@kernel.org, kasong@tencent.com, baoquan.he@linux.dev, joshua.hahnjy@gmail.com Subject: [swap tier discussion] Re: [PATCH v3 2/4] mm/zswap: Implement proactive writeback Message-ID: References: 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: X-Migadu-Flow: FLOW_OUT Changed the subject to separate the discussion on swap tiers. On Fri, Jun 12, 2026 at 04:27:37PM +0900, YoungJun Park wrote: > On Thu, Jun 11, 2026 at 12:12:40PM -0700, Shakeel Butt wrote: > > On Thu, Jun 11, 2026 at 05:45:04PM +0000, Yosry Ahmed wrote: > > > On Tue, Jun 09, 2026 at 01:19:13PM +0900, YoungJun Park wrote: > > > > On Mon, Jun 08, 2026 at 03:27:07PM -0700, Yosry Ahmed wrote: > > > > > > > > +Chris +Kairui +Baoquan > > > > > > > > Hello > > > > > > > > Thanks for inviting me to the discussion, Shakeel. > > > > > > > > > > > > Youngjun is working on swap tiers. At the moment he is more interested in > > > > > > > > allowing a specific swap device to a memcg or not. I can imagine in future there > > > > > > > > will be use-cases where there will be a need to demote data on higher tier swap > > > > > > > > to lower tier swap. What would be the appropriate interface? > > > > > > > > Speaking of my work on swap tiers, I recently submitted a patch and am > > > > currently considering memcg integration: > > > > https://lore.kernel.org/linux-mm/20260527062247.3440692-1-youngjun.park@lge.com/ > > > > > > > > The future use-cases imagined above seem to align with this > > > > direction. (BTW, I am currently waiting for reviews/feedback from the memcg > > > > folks on this patch. Any reviews would be highly appreciated!) > > > > > > > > We could potentially assign a target tier > > > > for writeback within the existing memory.zswap.writeback interface. > > > > > > > > For instance, '0' could mean disabled, while non-zero values could represent > > > > specific tiers, which would maintain backward compatibility with the current > > > > version. Alternatively, if zswap is treated as the default top tier, > > > > the `memory.swap.tiers` interface could potentially replace `memory.zswap.writeback`. > > > > > > > > Furthermore, this could be expanded so that each swap tier can demote data > > > > user-triggered demotion between swap tiers. > > > > > > > > Based on the current patch's ideas combined with my swap tiers concept: > > > > > > > > Assuming a hierarchy like: > > > > zswap -> tier1 (SSD swap) -> tier2 (HDD swap) -> tier3 (Network swap) > > > > > > > > We could configure the active tiers via a setting like `memory.swap.tiers` > > > > (tier2 enabled, tier3 enabled). > > > > > > > > For example, the concept of `echo "100M zswap_writeback_only > memory.reclaim"` > > > > could be extended. A user could run `echo "100M tier2 > memory.reclaim"` > > > > to explicitly trigger demotion from tier2 to tier3. > > > > (BTW, if we combine these features, my personal preference for the keyword > > > > format would be ` `. I think it would be > > > > better to explicitly indicate that it is a swap demotion by using a specific > > > > prefix followed by the tier name. > > > > Or make demote prefix another key is also possible) > > > > > > I am not sure if proactive demotion between swap tiers would be driven > > > by memory.reclaim, I am guessing a new interface might be more suitable. > > > But yes, you are right that it's very possible that > > > 'zswap_writeback_only' with memory.reclaim will become obsolete once > > > swap tiering matures and starts supporting things like proactive > > > demotion. > > > > > > Part of me wants to wait until the swap tiering interfaces are figured > > > out so that we don't end up with redundant interfaces, but I also don't > > > want to hold Hao's work since it doesn't directly depend on swap > > > tiering. > > However I would need zswap folks (Yosry & Nhat) help in figuring out swap tiers > > interfaces. Zswap is the current top tier swap usage in real world. I want > > zswap users to eaily (and hopefully transparently) migrate to swap tiers. > > > > Shakeel, how do you want to handle this? I think there's a few options: > > > > > > 1. Add zswap_writeback_only now, and when we have swap tiering demotion > > > it becomes a redundant interface, like memory.zswap.writeback -- or > > > maybe we try to deprecate both of them at that point. It's difficult to > > > remove interfaces tho, but maybe easier to stop supporting > > > zswap_writeback_only. > > > > > > 2. Add zswap_writeback_only behind an experimental config option, to > > > unblock development but have a line of sight to dropping support once we > > > have a swap tiering interface. > > > > > > 3. Wait until we figure out the swap tiering interfaces and then add > > > the proactive zswap writeback as part of it. > > > > > > WDYT? > > > > Is Hao's work needed for some followup work/development? The earliest Hao's > > work can is 7.3, so if we aim to figure out swap tiering interfaces in next > > couple of weeks then option 3 is the way to go. If swap tiers take more time > > then we can discuss other options as well. > > However I would need zswap folks (Yosry & Nhat) help in figuring out swap tiers > > interfaces. Zswap is the current top tier swap usage in real world. I want > > zswap users to eaily (and hopefully transparently) migrate to swap tiers. > > I am looking forward to the discussion on this interface! > > To help boost the discussion and progress, I would like to share a few of my thoughts. > We could either introduce a new interface to trigger demotion/promotion, > or we could reuse the existing one (using tier just internally) > > Based on the memcg interface currently proposed in swap_tier > (memory.swap.tiers, memory.swap.tiers.effective), I think it aligns well > with the current direction. It provides a foundation for selectively > targeting devices in tier order. Here instead of cpuset like interface, we may want more zswap like interface where you can put limit on the usage i.e. memory.swap.tier*.max. We can start with allowing only two values i.e. 0 and max which effectively will be the same as what you need. I will respond to your other points later when I have time. > > To summarize the discussions so far, the following points align well. > > - Per-cgroup swap control, as I suggested. > - Proactive zswap writeback (Hao's usecase) > - Swap device target demotion(if it wants selective, then it is more better), as you mentioned: > https://lore.kernel.org/linux-mm/aicZ-5GX9De3MAU7@linux.dev/ > - Virtual Swap on/off in the future, as Nhat mentioned: > https://lore.kernel.org/linux-mm/20260528212955.1912856-1-nphamcs@gmail.com/ > - The memory.zswap.writeback alternative (no hierarchy model conflict) > - zswap is first swap tier. > - Promotion. (Also better for selectve usage) > - tier based swap policy (e.g round-robin...) > > To accelerate this work, I believe we should reach a consensus and > merge the currently proposed swap_tier interface :) > > If the above approach is difficult, I would like to suggest an > alternative for progress with the memcg interfaces removed: > > 1) We could make zswap the first tier and create > a use case where memory.zswap.writeback internally is handled by tier logic. > > 2) Or simply merge the swap_tier infrastructure itself first. > > This would allow the swap_tier infrastructure to be merged and discussed > more easily. > > If it takes longer to adopt swap_tier anyway, by doing so we progress next step > as a experimental feature. > > - Apply per-cgroup swap as an experimental (debugfs) feature. > - Apply Hao's use case experimentally or as it is as Yosry suggested. > (future migration to swap tier) > > How do you think? > > (FYI: My emails to kernel.org are failing due to internal server issues.) > > Thank you > Youngjun Park