From: Youngjun Park <her0gyugyu@gmail.com>
To: Lian Wang <lianux.mm@gmail.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>,
akpm@linux-foundation.org, chrisl@kernel.org, linux-mm@kvack.org,
cgroups@vger.kernel.org, linux-kernel@vger.kernel.org,
kasong@tencent.com, mhocko@kernel.org, roman.gushchin@linux.dev,
shakeel.butt@linux.dev, muchun.song@linux.dev,
shikemeng@huaweicloud.com, baoquan.he@linux.dev,
baohua@kernel.org, yosry@kernel.org, joshua.hahnjy@gmail.com,
taejoon.song@lge.com
Subject: Re: [RFC PATCH v11 0/4] mm/swap: priority-based swap tiers with per-cgroup selection
Date: Sun, 27 Sep 2026 00:49:40 +0900 [thread overview]
Message-ID: <arfplImR24PFlk5H@gmail.com> (raw)
In-Reply-To: <20260925065521.36340-1-lianux.mm@gmail.com>
Hi Lian!
> zram integration test, not yet a real multi-SSD performance test.
>
> One result seems relevant to this discussion: with a restricted parent
> and an unconfigured child, the child could still use the faster tier. I
I intentionally left out the parent/child hierarchy handling in this
version, since I thought it would be needed only at memcg integration
time. At this point, though, I think it is better to keep the
hierarchy even in the debugfs interface,
so after reconsideration. I'll do that in v12!
> therefore agree that an inheritable memory.swap.prio.max looks like the
> cleaner first cgroup interface. A hole in the mask worked mechanically,
> but I do not yet have a convincing hierarchical use case for it; it felt
> more like per-cgroup swap-pool membership.
I plan to proceed with v12 as Johannes suggested. (I've replied
with my thoughts in the thread.)
> For the queue integration, one possible boundary is for the tier to own
> the queue/reader and for the swap queue to become the default per-tier
> device allocation policy. I would like to align this with both of you
> before changing v2. I will also continue the real multi-SSD tests.
I'd like to hear what Kairui and Chris think as well. If they agree,
this is the direction I prefer. Honestly, beyond preference, I think
it is the right one :) instead of allocating a separate swap queue
structure, the swap tier itself can be used for it!
> If either of you has suggestions or specific test cases you would like
> to see, please let me know. I have a few test setups available and should
> be able to try some of them. I am still getting up to speed on this part
> of MM, so please correct me if I missed some context or got any detail
> wrong.
When I send v12, I'll spell out more clearly the parts where we can
collaborate and what I'd like to propose to you. If anything comes up
before then, I'll reply on the v2 thread.
Thanks,
Youngjun
next prev parent reply other threads:[~2026-09-26 15:49 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-16 18:34 Youngjun Park
2026-09-16 18:34 ` [RFC PATCH v11 1/4] mm: swap: introduce swap tier infrastructure Youngjun Park
2026-09-16 18:34 ` [RFC PATCH v11 2/4] mm: swap: allocate swap slots from swap tiers Youngjun Park
2026-09-16 18:34 ` [RFC PATCH v11 3/4] mm: swap: add a debugfs interface for memcg tier selection Youngjun Park
2026-09-16 18:34 ` [RFC PATCH v11 4/4] mm: swap: filter swap allocation by memcg tier mask Youngjun Park
2026-09-16 20:04 ` [RFC PATCH v11 0/4] mm/swap: priority-based swap tiers with per-cgroup selection Johannes Weiner
2026-09-20 16:20 ` Youngjun Park
2026-09-23 17:15 ` Johannes Weiner
2026-09-25 6:54 ` Lian Wang
2026-09-26 15:49 ` Youngjun Park [this message]
2026-09-26 15:41 ` Youngjun Park
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=arfplImR24PFlk5H@gmail.com \
--to=her0gyugyu@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=baohua@kernel.org \
--cc=baoquan.he@linux.dev \
--cc=cgroups@vger.kernel.org \
--cc=chrisl@kernel.org \
--cc=hannes@cmpxchg.org \
--cc=joshua.hahnjy@gmail.com \
--cc=kasong@tencent.com \
--cc=lianux.mm@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.org \
--cc=muchun.song@linux.dev \
--cc=roman.gushchin@linux.dev \
--cc=shakeel.butt@linux.dev \
--cc=shikemeng@huaweicloud.com \
--cc=taejoon.song@lge.com \
--cc=yosry@kernel.org \
/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®