From: Rik van Riel <riel@surriel.com>
To: Gregory Price <gourry@gourry.net>, Kairui Song <ryncsn@gmail.com>
Cc: "Chris Li" <chrisl@kernel.org>,
"Johannes Weiner" <hannes@cmpxchg.org>,
"Baoquan He" <baoquan.he@linux.dev>,
"Nhat Pham" <nphamcs@gmail.com>,
"Michal Hocko" <mhocko@kernel.org>,
"Roman Gushchin" <roman.gushchin@linux.dev>,
"Shakeel Butt" <shakeel.butt@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>,
"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: Mon, 21 Sep 2026 11:27:53 -0400 [thread overview]
Message-ID: <f3af5902412b9ff1c1a37211eeeb9c0ffc22f814.camel@surriel.com> (raw)
In-Reply-To: <arEotFqE7ZZoxMHd@gourry-fedora-PF4VCD3F>
On Mon, 2026-09-21 at 09:27 -0400, Gregory Price wrote:
>
> In short:
>
> memory.swap = logical swap - workload/SLO limit
> memory.pswap = physical swap - storage limit
> memory.zswap = compressed memory - RAM limit
>
> This would preserve the existing memory.swap semantics while allowing
> both backing resources to be constrained independently.
>
My first thought was "this is confusing", but
after a minute I realized that most users will
never set those options to anything other than
"0" or "max", and the few who do only need to
touch one of them.
Some people may want to limit a particular
workload to having no more than 8 GB in a
place that is not directly accessible.
They would set memory.swap = 8G
Other people may want to limit how much
memory is used for the zswap pool.
They use memory.zswap.
Yet other people may want to limit how much
physical swap space is used for a particular
cgroup. They use memory.pswap.
Almost nobody would use all three.
Which one you use depends on your use case.
--
All Rights Reversed.
next prev parent reply other threads:[~2026-09-21 15:33 UTC|newest]
Thread overview: 69+ 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-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-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-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-21 10:01 ` Kairui Song
2026-09-21 13:27 ` Gregory Price
2026-09-21 15:27 ` Rik van Riel [this message]
2026-09-21 15:48 ` Gregory Price
2026-09-21 16:32 ` Chris Li
2026-09-21 17:02 ` Gregory Price
2026-09-21 18:11 ` Nhat Pham
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=f3af5902412b9ff1c1a37211eeeb9c0ffc22f814.camel@surriel.com \
--to=riel@surriel.com \
--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=chrisl@kernel.org \
--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=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=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®