From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qt1-f180.google.com (mail-qt1-f180.google.com [209.85.160.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 324164E0B97 for ; Mon, 21 Sep 2026 17:02:58 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.160.180 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790010180; cv=none; b=PlRsLX2IKQweWK6kTSnWwZOAjCi2McEdhyj4BgffmwaDi/JD74SFuKrcK3jEmZk3n9KHmZsIs6UUHdOcAlvpsU2TXgjOuNHXKvCtfv1WCrPvgSIm40UkLt+J6EPa5SVRs1X53rCsq3mUGvcKCV0wKKq/QgSZ+xIljjYX9gJoCrs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790010180; c=relaxed/simple; bh=0oQTC/1nit8xtttyPLngZa2mAS9b958j3IlvELrn/tI=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=OjjGEiSyVXCp7jKZc3QTXO8/acbmBwNDZDQAMvrci6g3n6dEL3jUTHSVkgoCV20O17arsQ0jHaJ7Jod0VXjIErSSnrF3TgMuYtsNKhjrku/7y1YkqkYNqSZdP1/A42u+ljPjVVKbhf0voSTPCgndEDUL7oMerUNxpWFQqfaQbJA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=gourry.net; spf=pass smtp.mailfrom=gourry.net; dkim=pass (2048-bit key) header.d=gourry.net header.i=@gourry.net header.b=IVfebPCd; arc=none smtp.client-ip=209.85.160.180 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=gourry.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gourry.net Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gourry.net header.i=@gourry.net header.b="IVfebPCd" Received: by mail-qt1-f180.google.com with SMTP id d75a77b69052e-52fa9c055b5so662111cf.1 for ; Mon, 21 Sep 2026 10:02:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gourry.net; s=google; t=1790010178; x=1790614978; darn=vger.kernel.org; h=in-reply-to:content-transfer-encoding:content-disposition :content-type:mime-version:references:message-id:subject:cc:to:from :date:from:to:cc:subject:date:message-id:reply-to:content-type; bh=zam1HuieMGo4IVtIDS9XVWJbvXE11Q3uTiDlxDLMxb4=; b=IVfebPCdcxu7JEGtSeXhDXopipg/6dGmEihMBn6DRAhhLr93waBxOZpRz8WpFs/x6K tS8FuLAnwSpudbK6M9LS9GCaXFtJ1XJwjcq6FDssRMGBWp8tFZ1wvMXipcSDn8lgurFd p4c9oC2HiZTO3MIkFlDQIY+VeEQVkEksw1Rm1CdlS0FIJCE1m5UNcH0Kge9KgAn70p9x VUpZl2V8ajpitWDr6M0kg3NPC3ZRnqDm8gm0JqsjgdvpoZg9JoPvxzjRtHqhNXI12ygp w29whUsrb5bGAi7JO/lWjiyVBAZ2yMAFDNzZ0IqHE6Egp83TSzwEOEbRgTlbM+VxQqD3 D30A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790010178; x=1790614978; h=in-reply-to:content-transfer-encoding:content-disposition :content-type:mime-version:references:message-id:subject:cc:to:from :date:x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to:content-type; bh=zam1HuieMGo4IVtIDS9XVWJbvXE11Q3uTiDlxDLMxb4=; b=yID62meS5ujXgWRmgReQAnErUNUDRYnV5Tm8lWwV16OErkNlIfmzdBlKXPpLWDe6vH Y8ofVNefARPWtYXGFnDS4PeDspwEaL4K/g3wTZv1i2fghkKdPTJ256+oP4UIuazeSqAS eE5xwlVFKYwjJltmHrxdMa0N2PFBF/Hhl3mzCA9VlSpGhD3AVeLqNTSZXusgHU74tF40 p+69mP+A81yn6V0jpoU+YuhaoQX4mymwBmw3CnKmNTZRbFJfNfEJZozPTZxu6RYqiUy7 79Jjf9bAuM+HZBwBmMxPR42Idh+qlEaZ84ylXDq8AcfbVg5TIoYlsWyXPPj9mgTIEDly Jngw== X-Forwarded-Encrypted: i=1; AKwUvByVzRLF9ejGCBVcSpAd66fkJfxrRPj+M6jrSLgMt0OGW1Hbwx5CIuRa5H3EW8vfL6DNSq6fVqJStE0=@vger.kernel.org X-Gm-Message-State: AFuF++kFE9BxibeKMGLasHm2fgwGHtjph2HWQO1ldzdz0rontCTNcQud RGk3SKy4PzAvlXnyJIX3wFKSa5PHyh0ir/anxIN1hUGoZukOpmP1rYbBvL6Jboex/N4= X-Gm-Gg: AYBFou0KaRNzpUUyL4hofF+aKrvqMbED1lWySnzS910iUem0DROh1bBq0ZZWP1zSmJK M8nRIySq3J+PcKs0ZazOfPVobZg59/d1OD98rN1zU5nYv/r1DGA4CfYhWjDo6TzixtH+5kEpLpf KR+m/YWd2y/q2fnvJP/tae+WWv49F6WArtOceIVfaUxmEk10Mab+UdXSwkf1kht2xkxTmKPHEE4 yoVF+CHSTNfZG/GNSJYLc0pjS8UMQFmlDtcj6eZ4Qhnh74rl+USN3crKGjI3EHcw3028RvkYDfS sjz7V0kx65n3yKN5zZsfhQbe/0ZLYi+qWrH8s1dEauBehAudOXQ2HpKGu6GtM9Exnl1nN00SoRC dZa677vS1yVlCw6cOhXP76SZWKYBQbFG8UghDE1sQGvhRWoU9RrtKk8Izbh0BSCa8QtASqPP1AP yH1u6BEbgcWXt89IrW/l9bOw+ezRfLevW/38EPhnnL9kNRLcsiLDpIdPVHKrB8npVkAEXWoQxs4 tLR4g8+7M13G2A3n2PQrv8= X-Received: by 2002:a05:622a:6110:b0:530:fbd3:2038 with SMTP id d75a77b69052e-532db89fda7mr2849411cf.26.1790010177750; Mon, 21 Sep 2026 10:02:57 -0700 (PDT) Received: from gourry-fedora-PF4VCD3F ([152.186.177.174]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-532ae618698sm68095611cf.16.2026.09.21.10.02.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 21 Sep 2026 10:02:57 -0700 (PDT) Date: Mon, 21 Sep 2026 13:02:10 -0400 From: Gregory Price To: Chris Li Cc: Kairui Song , Johannes Weiner , Baoquan He , Nhat Pham , Michal Hocko , Roman Gushchin , Shakeel Butt , Yosry Ahmed , David Hildenbrand , Muchun Song , Kemeng Shi , Barry Song , YoungJun Park , Chengming Zhou , "Lorenzo Stoakes (Oracle)" , "Liam R. Howlett" , "Vlastimil Babka (SUSE)" , Mike Rapoport , Suren =?utf-8?B?QmFnaGRhc2FyeWFu77+8?= , Qi Zheng , Axel Rasmussen , Yuanchu Xie , Wei Xu , Rik van Riel , Wenchao Hao , Jonathan Corbet , Hugh Dickins , Baolin Wang , Tejun Heo , Michal =?utf-8?Q?Koutn=C3=BD?= , Shuah Khan , Kunwu Chan , Meta kernel team , Linux Memory Management List , Linux Kernel Mailing List , linux-doc@vger.kernel.org, "open list:CONTROL GROUP - MEMORY RESOURCE CONTROLLER (MEMCG)" , Andrew Morton , Joshua Hahn Subject: Re: Path forward for Virtualized Swap? 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, Sep 21, 2026 at 06:32:56AM -1000, Chris Li wrote: > On Mon, Sep 21, 2026 at 3:27 AM Gregory Price wrote: > > > > This would preserve the existing memory.swap semantics while allowing > > both backing resources to be constrained independently. > > It sounds like you want memory.tiers have limit enforced. > > I suppose it is possible. Again I want to see how people would > actually use this feature. > Possible, but arguably not needed. the swap and zswap counters already work for this existing interaction. As I pointed to in my response to Rik, in every reasonable use of pswap+zswap the global swap counter is pointless. So then pswap=swap and we're left with zswap and swap. And I'm not convinced your reading of the swap counter as a limit on the *logical* memory allowed to be swapped out is actually accurate. memory.swap.current The total amount of swap currently being used by the cgroup and its descendants. memory.swap.max Swap usage hard limit. If a cgroup's swap usage reaches this limit, anonymous memory of the cgroup will not be swapped out. There is no documentation I can find that has ever documented these counters as "the amount of memory requiring a fault". If you put a compression system in front of physical swap - the counters as-described would still be accurate, while your reading would be broken. "swap" here is highly implied to mean "storage" as opposed to memory, which is why "zswap" defines its limits in terms of memory. memory.zswap.current The total amount of memory consumed by the zswap compression backend. memory.zswap.max Zswap usage hard limit. If a cgroup's zswap pool reaches this limit, it will refuse to take any more stores before existing entries fault back in or are written out to disk. If you're presently using swap.max to mean the "logical amount of memory allowed to be swapped" - then your usage does not meet the definition of the knob. You need to justify that your use case cannot be expressed via memory.min/low controls: memory.min Hard memory protection. If the memory usage of a cgroup is within its effective min boundary, the cgroup's memory won't be reclaimed under any conditions. If there is no unprotected reclaimable memory available, OOM killer is invoked. Above the effective min boundary (or effective low boundary if it is higher), pages are reclaimed proportionally to the overage, reducing reclaim pressure for smaller overages. That's an SLO interface. memory.swap is a provisioning interface. As it stands, I'm left viewing zswap's counter inclusion in swap as more of a bug than a feature - they account for different things (memory vs storage usage). ~Gregory