From: YoungJun Park <youngjun.park@lge.com>
To: ksummit@lists.linux.dev
Cc: youngjun.park@lge.com, chrisl@kernel.org, gunho.lee@lge.com,
taejoon.song@lge.com
Subject: [TECH TOPIC] Per-cgroup Swap Device Control
Date: Fri, 22 Aug 2025 17:14:51 +0900 [thread overview]
Message-ID: <aKgm+wisMipLqnL4@yjaykim-PowerEdge-T330> (raw)
Abstract:
Enabling cgroup-level control over swap devices for diverse workloads
Proposal:
I am developing on a restricted internal platform where there is a
technical requirement to use idle devices as extended memory.
One motivating scenario discussed was to configure background processes
to use slow swap (network) while foreground processes use fast swap
(local storage).
Currently, the kernel does not provide per-process or per-cgroup swap
selection, making this idea unachievable. To meet this usage need, and
after reviewing alternatives, I reached the conclusion that swap
devices must be controllable on a per-cgroup basis.
I would like to present the motivation, implementation progress, and
directions of this work, and invite discussion and feedback from the
community. Through prior exchanges with Chris Li[1], I also recognized
that this topic has already triggered meaningful technical debate, and
I believe a broader discussion at Kernel Summit would be valuable.
Agenda:
1. Motivation for per-cgroup swap priority [2]
- Comparison with alternative approaches
2. Implementation reviews and problem solving
- Changes in percpu clusters & swap [3]
- Consistency with cgroup parent-child semantics [4]
- Challenges with NUMA autobind and swap priority [5]
3. Criticism and alternative ideas
- Technical concerns raised by Chris Li [6]
- Introduction of the swap tier approach
4. Further discussion
- Topics expected to arise in ongoing reviews before Plumbers
These agenda items reflect issues that have emerged through the ongoing
RFC → PATCH development process. The presentation aims to summarize
these discussions, share the current direction, and invite further
feedback and open discussion from the community.
[1] https://lore.kernel.org/linux-mm/CAF8kJuMo3yNKOZL9n5UkHx_O5cTZts287HOnQOu=KqQcnbrMdg@mail.gmail.com/
[2] https://lore.kernel.org/linux-mm/20250612103743.3385842-1-youngjun.park@lge.com/
[3] https://lore.kernel.org/linux-mm/CAMgjq7BJE9ALFG4N8wb-hdkC+b-8d1+ckXL9D6pbbfgiXfuzPA@mail.gmail.com/
[4] https://lore.kernel.org/linux-mm/rivwhhhkuqy7p4r6mmuhpheaj3c7vcw4w4kavp42avpz7es5vp@hbnvrmgzb5tr/
[5] https://lore.kernel.org/linux-mm/jrkh2jy2pkoxgsxgsstpmijyhbzzyige6ubltvmvwl6fwkp3s7@kzc24pj2tcko/
[6] https://lore.kernel.org/linux-mm/CAF8kJuMo3yNKOZL9n5UkHx_O5cTZts287HOnQOu=KqQcnbrMdg@mail.gmail.com/
next reply other threads:[~2025-08-22 8:14 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-22 8:14 YoungJun Park [this message]
2025-08-22 16:58 ` Matthew Wilcox
2025-08-22 17:10 ` Steven Rostedt
2025-08-22 17:43 ` Matthew Wilcox
2025-08-22 18:13 ` Chris Li
2025-08-22 18:26 ` Steven Rostedt
2025-08-23 0:42 ` 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=aKgm+wisMipLqnL4@yjaykim-PowerEdge-T330 \
--to=youngjun.park@lge.com \
--cc=chrisl@kernel.org \
--cc=gunho.lee@lge.com \
--cc=ksummit@lists.linux.dev \
--cc=taejoon.song@lge.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