From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lgeamrelo07.lge.com (lgeamrelo07.lge.com [156.147.51.103]) (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 8733E244687 for ; Tue, 16 Jun 2026 01:03:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=156.147.51.103 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781571800; cv=none; b=kOFEyPOa/5gyK8t1Qt5GqzVVWe+PPFdbGqTjR7DyPzrItcKpwyb7OZ0vJFSzkaimGLFoEb1qZ8SVGDGv+QibEH/T1jH9O5IpgKEtHoHKX9B/2BOZjpmGQON8SE87hmvIPhJQcHw4zcUKpMygdSpRkqiyZvmykFxCLj3wsIsT5Go= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781571800; c=relaxed/simple; bh=jX1mm1IOeJgFXgCq9BYe2NIXn5ungu7YN8snXelcbu8=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=rreFPRwA+YQij6xMgeW/YLw9JoDbDHwSisJeDwqhC1WN6zdYCMmNIIvzrMeMoKxzJZJQYesKKxXSdaTkzWCrT8OQR4sc0QzUROyjifS2DiPXqwceIvh0rJTLZu0vwAcE4kellM0akIbwmiSYuL2Xr75Otiebk9wffczcApQHCm8= 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.103 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.103 with ESMTP; 16 Jun 2026 10:03:09 +0900 X-Original-SENDERIP: 10.177.112.156 X-Original-MAILFROM: youngjun.park@lge.com Date: Tue, 16 Jun 2026 10:03:08 +0900 From: YoungJun Park To: Yosry Ahmed Cc: Shakeel Butt , 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: Re: [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=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Mon, Jun 15, 2026 at 12:55:09PM -0700, Yosry Ahmed wrote: > > In that case, the internal logic could stay roughly the same rather > > than counting via a page counter. Something like: > > > > 1. Change the interface shell: tier.*.max — allow only 0 ~ max. > > What about a single interface as I suggested to remain consistent with > memory tiering? Hello Yosry! I agree. As I was implementing the interface for seeing feasibility , I reconsidered it. Since swap tiers can be added or removed at runtime, having static memory."tier_name".max files seems unnatural. A single interface like `swap.tiers.max` would be better. We can use a flat-keyed format (similar to io.weight. same as you suggested) echo ["tier_name"] ["0 or max"] > swap.tiers.max I am now leaning towards this is a better direction than what I initially suggested (memory.swap.tiers and memory.swap.tiers.effective). Considering other reviews and Shakeel's reply, I will update my swap tier patch accordingly. > > 2. Keep the internal logic as is: 0 disables the mask (child memcgs > > off too), max enables it (child memcgs on too). > > I think a child should be able to disable a swap tier enabled by the > parent, but not vice versa. Yes, we are on the same page. I missed a part in my explanation. I meant that the child's selected tiers should be a subset of the parent's (which is how the current swap tier suggestion works). A child cannot enable a tier that the parent has disabled. > > 3. memory.zswap.max integrates naturally (it's memory."tier_name".max). > > Not really. memory.zswap.max is in terms of memory usage (compressed > size), not swap usage (uncompressed size). I see, memory.zswap.max needs to be maintained separately. I will look closer into its semantics. I might have misunderstood this part! > [..] > > Let me clarify a part I wrote confusingly. Handling > > memory.zswap.writeback via tiers is possible, but I don't think the > > interface itself would be replaced even if memory.swap.tiers is adopted. > > > > Selecting only zswap in memory.swap.tiers would not just disable > > writeback.it would also block regular swap entirely, which differs > > slightly from the current semantic. (... "Per the cgroup v2 docs: a > > zswap-only tier setting is subtly different from setting > > memory.swap.max to 0, since it still allows pages to be written to the > > zswap pool; this has no effect if zswap is disabled, and swapping is > > allowed unless memory.swap.max is set to 0.") > > I don't understand. How is disabling zswap writeback not equivalent to > only enabling zswap as a tier? Isn't there a case where zswap_store() fails and pages fall back to the backing swap device? - "zswap tier only": Only zswap is allowed. Fallback to other swap is blocked. - "zswap writeback disabled": zswap is allowed, but if zswap_store() fails, pages can still fall back to other swap devices. Because of this slight semantic difference, I thought they couldn't be fully unified. If my understanding is correct, we could extend the zswap tier to select the target swap device for writeback, but replacing the writeback interface entirely might be difficult. > Do you just mean the fact that disabling zswap writeback is a noop of > zswap is disabled? It's a different interface so I think a small Yes, I think so too. > semantic difference is okay. In practice, I doubt that zswap is being > disabled at runtime. I thought disabling zswap at runtime might have some use cases, but we can discuss this further when we talk about the patch extending the zswap tier. Best regards, Youngjun