From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 6D3EC33939D for ; Sun, 27 Sep 2026 06:23:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790490207; cv=none; b=T5ixBS2zzCXtgOA8mVYZ+iVsfMwOu1zCZpBteEOJ/qR4UbcKUeS51Cx9FFJ0oPkUBDI6yqBJatyttYd5KeWEx5E2ZxC80q79HucPh+06FXP3Gydmwjfy7fPa+Tv9FQh5PO6qHOu6tmDmhmUjIR0oKQmHrWc37TXmcQrBg0jA8AI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790490207; c=relaxed/simple; bh=abQ20sTrkthDKubL8xH9f1qWTFEmLog2Xb7FTeV5HhQ=; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=hm72dLbb18xvNHNJCynJTo+zBGJPxhDN22WQAFGhpkYRwDlAW+G83XxprPnP//BxRiGJ7BM/x1LmAK/kwVwyoUmvqsnefv/UsW1yg82NIc2hxHr86/rMKJeN3avdUEcWp5BNcNzoHAmHTIbk7ILKR4b27kKZFKqY2zmDJSuicro= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=MgjDRlH+; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="MgjDRlH+" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3B9E91F008BF for ; Sun, 27 Sep 2026 06:23:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1790490206; bh=abQ20sTrkthDKubL8xH9f1qWTFEmLog2Xb7FTeV5HhQ=; h=References:In-Reply-To:From:Date:Subject:To:Cc; b=MgjDRlH+sYmzPaCjMSbcE3B7aimF1q17Fn2czcyRyuRVJvOzNSF8TW+yv5wT+RqVw +as3k2Liyt0WODzu2xA+ywYIuPUStXP1ftIHnpEO1ihWgyMUvRrTaDEy83uwIWflSE yazikBOTHeYgknkYOEjPgxXexwFhLUtOFJiSQRg1QmO6RDSWDco07eJ6BtSvuapDfP ZTSKUxftQ5D/UMB4DkBvI0EEoXYn0mvU2SQpYmZgggkdd+IQcjPDDHKhwkVKv2RgNY PLcnJUUbx+/g9aIvUufLV3c0kyfnzvA/9tirNo/F0zZ1+IdGDBo/f9wnneb7cwi0Pu ErqEqM5pQjFlg== Received: by mail-ej2-f17.google.com with SMTP id a640c23a62f3a-c29d50b7cf9so310506566b.2 for ; Sat, 26 Sep 2026 23:23:26 -0700 (PDT) X-Forwarded-Encrypted: i=1; AKwUvBxAPyTKgU6SC7wTmi02xqOn9yhqhmEDsa57lLo/SJBNiflm1LtAe1WX6+pW2lQ8IdUxO7Pgt3vmTUiLGKE=@vger.kernel.org X-Gm-Message-State: AFuF++kuLHYwzo/4bbEH39aVzme5Q9KgIKFiKXYusKrspJvQbgWZRDU9 F/XQDQ84Twe1NqCR1jxojlNTUqUtGSqwfwRCto7k1ybyo1AcZL9dSpGTbAyYzJkDYqrkxgyk2Nd suk4daeNifs00BCbqpIpa5eZGE7aL1K0Gs7aW3WnI0w== X-Received: by 2002:a17:907:d408:b0:c29:3821:ae6c with SMTP id a640c23a62f3a-c2ac2606943mr866958866b.37.1790490204956; Sat, 26 Sep 2026 23:23:24 -0700 (PDT) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: <7ee199ddee81bf8026688def82f78ad9db09be9e.camel@surriel.com> <9499bc084e30df4d10bc069ed26d576e4dd3de80.camel@surriel.com> In-Reply-To: <9499bc084e30df4d10bc069ed26d576e4dd3de80.camel@surriel.com> From: Chris Li Date: Sat, 26 Sep 2026 20:23:13 -1000 X-Gmail-Original-Message-ID: X-Gm-Features: AclHuK9XVPbdEdRuFYnT3RhuHd6CxK6iuGG39DZDVhwy7Jj_A42gkqdamTqXRIk Message-ID: Subject: Re: Path forward for Virtualized Swap? To: Rik van Riel Cc: Johannes Weiner , Kairui Song , Nhat Pham , Baoquan He , Shakeel Butt , Kairui Song , Michal Hocko , Roman Gushchin , 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 , =?UTF-8?Q?Suren_Baghdasaryan=EF=BF=BC?= , Qi Zheng , Axel Rasmussen , Yuanchu Xie , Wei Xu , Gregory Price , Wenchao Hao , Jonathan Corbet , Hugh Dickins , Baolin Wang , Tejun Heo , =?UTF-8?Q?Michal_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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Sep 26, 2026 at 2:59=E2=80=AFPM Rik van Riel wro= te: > > On Sat, 2026-09-26 at 11:27 -1000, Chris Li wrote: > > On Fri, Sep 25, 2026 at 5:41=E2=80=AFAM Johannes Weiner > > wrote: > > > > > > > > (2) The use case we have. Use memory.swap.max to divide a finite > > > space > > > in storage. We only have so much space on disk, and we need to > > > manage > > > fair access. Note that this isn't about speed. We have a mix of > > > containers where some use writeback and others do not. The ones who > > > write back to the swapfile need to be able to get their fair share > > > - > > > not more, not less. Including something that doesn't actually > > > consume > > > > Just want to make sure I understand correctly. Do you mean the fair > > share of compressed memory used in the zswap case? > > > Compressed zswap memory is already accounted for > under cgroup.memory.max. Ack. > > Compressed zswap memory sits under memory.max > together with anonymous, file, and slab cache > memory. I understand that. > We do not need or want another limit there, > though I understand other people do. Ack. > The fair resource use from memory.swap.max > is to control how much of the fixed swap file > (or swap partition) space each cgroup gets. That is the part I am not sure I understand correctly. Fair in what sense? Using the swap file proportional to the memory limit of the cgroup? Do you have an example of perfectly fair swap file usage for a cgroup with an 8G memory limit versus one with a 1G limit? Sorry I am a bit slow grasping what exactly the fair behavior is. Chris