From: Chris Li <chrisl@kernel.org>
To: Rik van Riel <riel@surriel.com>
Cc: "Johannes Weiner" <hannes@cmpxchg.org>,
"Kairui Song" <ryncsn@gmail.com>, "Nhat Pham" <nphamcs@gmail.com>,
"Baoquan He" <baoquan.he@linux.dev>,
"Shakeel Butt" <shakeel.butt@linux.dev>,
"Kairui Song" <kasong@tencent.com>,
"Michal Hocko" <mhocko@kernel.org>,
"Roman Gushchin" <roman.gushchin@linux.dev>,
"Yosry Ahmed" <yosry@kernel.org>,
"David Hildenbrand" <david@kernel.org>,
"Muchun Song" <muchun.song@linux.dev>,
"Kemeng Shi" <shikemeng@huaweicloud.com>,
"Barry Song" <baohua@kernel.org>,
"YoungJun Park" <youngjun.park@lge.com>,
"Chengming Zhou" <chengming.zhou@linux.dev>,
"Lorenzo Stoakes (Oracle)" <ljs@kernel.org>,
"Liam R. Howlett" <liam@infradead.org>,
"Vlastimil Babka (SUSE)" <vbabka@kernel.org>,
"Mike Rapoport" <rppt@kernel.org>,
"Suren Baghdasaryan" <surenb@google.com>,
"Qi Zheng" <qi.zheng@linux.dev>,
"Axel Rasmussen" <axelrasmussen@google.com>,
"Yuanchu Xie" <yuanchu@google.com>, "Wei Xu" <weixugc@google.com>,
"Gregory Price" <gourry@gourry.net>,
"Wenchao Hao" <haowenchao22@gmail.com>,
"Jonathan Corbet" <corbet@lwn.net>,
"Hugh Dickins" <hughd@google.com>,
"Baolin Wang" <baolin.wang@linux.alibaba.com>,
"Tejun Heo" <tj@kernel.org>, "Michal Koutný" <mkoutny@suse.com>,
"Shuah Khan" <skhan@linuxfoundation.org>,
"Kunwu Chan" <kunwu.chan@linux.dev>,
"Meta kernel team" <kernel-team@meta.com>,
"Linux Memory Management List" <linux-mm@kvack.org>,
"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
linux-doc@vger.kernel.org,
"open list:CONTROL GROUP - MEMORY RESOURCE CONTROLLER (MEMCG)"
<cgroups@vger.kernel.org>,
"Andrew Morton" <akpm@linux-foundation.org>,
"Joshua Hahn" <joshua.hahnjy@gmail.com>
Subject: Re: Path forward for Virtualized Swap?
Date: Sat, 26 Sep 2026 20:23:13 -1000 [thread overview]
Message-ID: <CACePvbWdJSUDuEbR2FXczbeWwvxP86WDGHTL-eO0A8WwMDoNRQ@mail.gmail.com> (raw)
In-Reply-To: <9499bc084e30df4d10bc069ed26d576e4dd3de80.camel@surriel.com>
On Sat, Sep 26, 2026 at 2:59 PM Rik van Riel <riel@surriel.com> wrote:
>
> On Sat, 2026-09-26 at 11:27 -1000, Chris Li wrote:
> > On Fri, Sep 25, 2026 at 5:41 AM Johannes Weiner <hannes@cmpxchg.org>
> > 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
next prev parent reply other threads:[~2026-09-27 6:23 UTC|newest]
Thread overview: 135+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-04 21:14 Nhat Pham
2026-09-07 5:51 ` Kairui Song
2026-09-08 16:36 ` Nhat Pham
2026-09-11 16:09 ` Kairui Song
2026-09-11 16:57 ` Nhat Pham
2026-09-11 18:14 ` Kairui Song
2026-09-11 19:03 ` Nhat Pham
2026-09-12 8:47 ` Kairui Song
2026-09-14 16:49 ` Nhat Pham
2026-09-08 18:30 ` Johannes Weiner
2026-09-09 16:41 ` Nhat Pham
2026-09-09 17:47 ` Nhat Pham
2026-09-12 9:00 ` Kairui Song
2026-09-12 11:51 ` Johannes Weiner
2026-09-19 7:23 ` Chris Li
2026-09-20 1:06 ` Rik van Riel
2026-09-21 0:18 ` Chris Li
2026-09-21 0:35 ` Rik van Riel
2026-09-21 0:53 ` Chris Li
2026-09-14 16:10 ` Nhat Pham
2026-09-10 23:27 ` Nhat Pham
2026-09-07 11:30 ` David Hildenbrand (Arm)
2026-09-08 16:45 ` Nhat Pham
2026-09-10 10:56 ` David Hildenbrand (Arm)
2026-09-10 16:22 ` Nhat Pham
2026-09-10 17:57 ` David Hildenbrand (Arm)
2026-09-11 16:20 ` Kairui Song
2026-09-11 16:56 ` David Hildenbrand (Arm)
2026-09-14 15:00 ` Baoquan He
2026-09-19 6:50 ` Chris Li
2026-09-21 18:55 ` Nhat Pham
2026-09-22 13:38 ` Chris Li
2026-09-22 14:43 ` Shakeel Butt
2026-09-22 14:56 ` Chris Li
2026-09-22 15:07 ` Johannes Weiner
2026-09-22 15:30 ` Chris Li
2026-09-22 15:45 ` Shakeel Butt
2026-09-23 6:44 ` Chris Li
2026-09-22 15:46 ` Johannes Weiner
2026-09-22 15:28 ` Baoquan He
2026-09-25 18:47 ` Shakeel Butt
2026-09-10 7:09 ` Baoquan He
2026-09-10 16:39 ` Shakeel Butt
2026-09-11 13:06 ` Baoquan He
2026-09-11 16:45 ` Shakeel Butt
2026-09-15 5:48 ` Baoquan He
2026-09-15 6:44 ` Baoquan He
2026-09-19 6:55 ` Chris Li
2026-09-19 16:15 ` Rik van Riel
2026-09-19 21:21 ` Chris Li
2026-09-19 22:50 ` Rik van Riel
2026-09-21 0:13 ` Chris Li
2026-09-22 17:54 ` Nhat Pham
2026-09-23 7:44 ` Chris Li
2026-09-23 16:30 ` Shakeel Butt
2026-09-24 11:27 ` Chris Li
2026-09-24 13:15 ` Shakeel Butt
2026-09-25 13:15 ` Kairui Song
2026-09-25 15:41 ` Johannes Weiner
2026-09-25 19:21 ` Kairui Song
2026-09-25 20:20 ` Johannes Weiner
2026-09-26 21:27 ` Chris Li
2026-09-27 0:58 ` Rik van Riel
2026-09-27 6:23 ` Chris Li [this message]
2026-09-27 12:29 ` Rik van Riel
2026-09-27 16:17 ` Chris Li
2026-09-25 16:11 ` Gregory Price
2026-09-25 20:44 ` Kairui Song
2026-09-25 21:30 ` Gregory Price
2026-09-25 21:53 ` Johannes Weiner
2026-09-25 16:54 ` Nhat Pham
2026-09-25 20:26 ` Kairui Song
2026-09-25 19:36 ` Shakeel Butt
2026-09-25 20:20 ` Kairui Song
2026-09-19 7:07 ` Chris Li
2026-09-10 17:03 ` Johannes Weiner
2026-09-11 12:27 ` Baoquan He
2026-09-11 16:21 ` Johannes Weiner
2026-09-19 8:45 ` Chris Li
2026-09-19 16:08 ` Gregory Price
2026-09-19 19:02 ` Chris Li
2026-09-20 1:14 ` Rik van Riel
2026-09-20 1:53 ` Gregory Price
2026-09-21 9:43 ` Chris Li
2026-09-21 12:53 ` Gregory Price
2026-09-21 16:11 ` Chris Li
2026-09-22 17:14 ` Rik van Riel
2026-09-22 17:21 ` Nhat Pham
2026-09-23 7:20 ` Chris Li
2026-09-22 17:31 ` Johannes Weiner
2026-09-23 7:32 ` Chris Li
2026-09-23 13:55 ` Johannes Weiner
2026-09-21 14:06 ` Rik van Riel
2026-09-21 16:15 ` Chris Li
2026-09-21 15:16 ` Rik van Riel
2026-09-21 16:31 ` Chris Li
2026-09-21 16:36 ` Rik van Riel
2026-09-21 18:10 ` Chris Li
2026-09-21 18:52 ` Rik van Riel
2026-09-22 13:32 ` Chris Li
2026-09-22 14:59 ` Rik van Riel
2026-09-22 15:23 ` Chris Li
2026-09-22 15:43 ` Johannes Weiner
2026-09-23 6:10 ` Chris Li
2026-09-22 15:48 ` Rik van Riel
2026-09-23 7:00 ` Chris Li
2026-09-23 14:21 ` Rik van Riel
2026-09-22 17:32 ` Nhat Pham
2026-09-23 7:37 ` Chris Li
2026-09-23 14:11 ` Johannes Weiner
2026-09-23 15:39 ` Nhat Pham
2026-09-22 15:20 ` Gregory Price
2026-09-22 15:43 ` Chris Li
2026-09-22 15:52 ` Rik van Riel
2026-09-23 7:10 ` Chris Li
2026-09-23 12:52 ` Klara Modin
2026-09-23 15:43 ` Nhat Pham
2026-09-23 17:26 ` Klara Modin
2026-09-24 5:51 ` Baoquan He
2026-09-24 7:20 ` Klara Modin
2026-09-24 7:53 ` Baoquan He
2026-09-21 10:01 ` Kairui Song
2026-09-21 13:27 ` Gregory Price
2026-09-21 15:27 ` Rik van Riel
2026-09-21 15:48 ` Gregory Price
2026-09-21 16:32 ` Chris Li
2026-09-21 17:02 ` Gregory Price
2026-09-23 9:39 ` Baoquan He
2026-09-23 12:11 ` Gregory Price
2026-09-24 11:02 ` Chris Li
2026-09-24 14:18 ` Gregory Price
2026-09-23 14:34 ` Kairui Song
2026-09-21 18:11 ` Nhat Pham
2026-09-22 17:16 ` Johannes Weiner
2026-09-10 17:16 ` Nhat Pham
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CACePvbWdJSUDuEbR2FXczbeWwvxP86WDGHTL-eO0A8WwMDoNRQ@mail.gmail.com \
--to=chrisl@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=axelrasmussen@google.com \
--cc=baohua@kernel.org \
--cc=baolin.wang@linux.alibaba.com \
--cc=baoquan.he@linux.dev \
--cc=cgroups@vger.kernel.org \
--cc=chengming.zhou@linux.dev \
--cc=corbet@lwn.net \
--cc=david@kernel.org \
--cc=gourry@gourry.net \
--cc=hannes@cmpxchg.org \
--cc=haowenchao22@gmail.com \
--cc=hughd@google.com \
--cc=joshua.hahnjy@gmail.com \
--cc=kasong@tencent.com \
--cc=kernel-team@meta.com \
--cc=kunwu.chan@linux.dev \
--cc=liam@infradead.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ljs@kernel.org \
--cc=mhocko@kernel.org \
--cc=mkoutny@suse.com \
--cc=muchun.song@linux.dev \
--cc=nphamcs@gmail.com \
--cc=qi.zheng@linux.dev \
--cc=riel@surriel.com \
--cc=roman.gushchin@linux.dev \
--cc=rppt@kernel.org \
--cc=ryncsn@gmail.com \
--cc=shakeel.butt@linux.dev \
--cc=shikemeng@huaweicloud.com \
--cc=skhan@linuxfoundation.org \
--cc=surenb@google.com \
--cc=tj@kernel.org \
--cc=vbabka@kernel.org \
--cc=weixugc@google.com \
--cc=yosry@kernel.org \
--cc=youngjun.park@lge.com \
--cc=yuanchu@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®