[TECH TOPIC] Per-cgroup Swap Device Control

[TECH TOPIC] Per-cgroup Swap Device Control

[YoungJun Park]

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/

Re: [TECH TOPIC] Per-cgroup Swap Device Control

[Matthew Wilcox]

On Fri, Aug 22, 2025 at 05:14:51PM +0900, YoungJun Park wrote:
> 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.

I don't think this is appropriate for the maintainer summit.  You
can submit it to the Plumbers MM microconf [1] or LSFMM in May.

[1] https://lpc.events/event/19/contributions/1995/

Also you should have cc'd linux-mm for this kind of thing, adding
it now.  Preserving the rest of the proposal for those who are
interested.

> 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/

Re: [TECH TOPIC] Per-cgroup Swap Device Control

[Steven Rostedt]

On Fri, 22 Aug 2025 17:58:16 +0100
Matthew Wilcox <willy@infradead.org> wrote:

> > Proposal:
> > I am developing on a restricted internal platform where there is a
> > technical requirement to use idle devices as extended memory.  
> 
> I don't think this is appropriate for the maintainer summit.  You
> can submit it to the Plumbers MM microconf [1] or LSFMM in May.
> 
> [1] https://lpc.events/event/19/contributions/1995/
> 
> Also you should have cc'd linux-mm for this kind of thing, adding
> it now.  Preserving the rest of the proposal for those who are
> interested.

From Ted's original email: https://lore.kernel.org/all/20250805144357.GA762104@mit.edu/

  Related to the Maintainer's Summit, the Kernel Summit is organized as a
  track which is run in parallel with the other tracks at the Linux
  Plumbers Conference (LPC), and is open to all registered attendees of
  LPC.  The goal of the Kernel Summit track will be to provide a forum to
  discuss specific technical issues that would be easier to resolve in
  person than over e-mail.  The program committee will also consider
  "information sharing" topics if they are clearly of interest to the wider
  development community (i.e., advanced training in topics that would be
  useful to kernel developers).

  To suggest a topic for the Kernel Summit, please do two things. by
  September 10th, 2025. First, please send e-mail with a subject prefix of
  [TECH TOPIC] to ksummit@lists.linux.dev.  As before, please use a
  separate e-mail for each topic.

So this appears to be appropriate.

-- Steve

Re: [TECH TOPIC] Per-cgroup Swap Device Control

[Matthew Wilcox]

On Fri, Aug 22, 2025 at 01:10:22PM -0400, Steven Rostedt wrote:
> On Fri, 22 Aug 2025 17:58:16 +0100
> Matthew Wilcox <willy@infradead.org> wrote:
> 
> > > Proposal:
> > > I am developing on a restricted internal platform where there is a
> > > technical requirement to use idle devices as extended memory.  
> > 
> > I don't think this is appropriate for the maintainer summit.  You
> > can submit it to the Plumbers MM microconf [1] or LSFMM in May.
> > 
> > [1] https://lpc.events/event/19/contributions/1995/
> > 
> > Also you should have cc'd linux-mm for this kind of thing, adding
> > it now.  Preserving the rest of the proposal for those who are
> > interested.
> 
> From Ted's original email: https://lore.kernel.org/all/20250805144357.GA762104@mit.edu/
> 
>   Related to the Maintainer's Summit, the Kernel Summit is organized as a
>   track which is run in parallel with the other tracks at the Linux
>   Plumbers Conference (LPC), and is open to all registered attendees of
>   LPC.  The goal of the Kernel Summit track will be to provide a forum to
>   discuss specific technical issues that would be easier to resolve in
>   person than over e-mail.  The program committee will also consider
>   "information sharing" topics if they are clearly of interest to the wider
>   development community (i.e., advanced training in topics that would be
>   useful to kernel developers).
> 
>   To suggest a topic for the Kernel Summit, please do two things. by
>   September 10th, 2025. First, please send e-mail with a subject prefix of
>   [TECH TOPIC] to ksummit@lists.linux.dev.  As before, please use a
>   separate e-mail for each topic.
> 
> So this appears to be appropriate.

My mistake.  I thought tech topics were part of maintainer summit, not
part of the kernel track.  It'll be up to the kernel track organiser(s)
whether to accept it to that track or whether they think it'll be more
appropriate in the MM microconf.

Re: [TECH TOPIC] Per-cgroup Swap Device Control

[Chris Li]

On Fri, Aug 22, 2025 at 10:43 AM Matthew Wilcox <willy@infradead.org> wrote:
>
> On Fri, Aug 22, 2025 at 01:10:22PM -0400, Steven Rostedt wrote:
> > On Fri, 22 Aug 2025 17:58:16 +0100
> > Matthew Wilcox <willy@infradead.org> wrote:
> >
> > > > Proposal:
> > > > I am developing on a restricted internal platform where there is a
> > > > technical requirement to use idle devices as extended memory.
> > >
> > > I don't think this is appropriate for the maintainer summit.  You
> > > can submit it to the Plumbers MM microconf [1] or LSFMM in May.
> > >
> > > [1] https://lpc.events/event/19/contributions/1995/
> > >
> > > Also you should have cc'd linux-mm for this kind of thing, adding
> > > it now.  Preserving the rest of the proposal for those who are
> > > interested.
> >
> > From Ted's original email: https://lore.kernel.org/all/20250805144357.GA762104@mit.edu/
> >
> >   Related to the Maintainer's Summit, the Kernel Summit is organized as a
> >   track which is run in parallel with the other tracks at the Linux
> >   Plumbers Conference (LPC), and is open to all registered attendees of
> >   LPC.  The goal of the Kernel Summit track will be to provide a forum to
> >   discuss specific technical issues that would be easier to resolve in
> >   person than over e-mail.  The program committee will also consider
> >   "information sharing" topics if they are clearly of interest to the wider
> >   development community (i.e., advanced training in topics that would be
> >   useful to kernel developers).
> >
> >   To suggest a topic for the Kernel Summit, please do two things. by
> >   September 10th, 2025. First, please send e-mail with a subject prefix of
> >   [TECH TOPIC] to ksummit@lists.linux.dev.  As before, please use a
> >   separate e-mail for each topic.
> >
> > So this appears to be appropriate.
>
> My mistake.  I thought tech topics were part of maintainer summit, not
> part of the kernel track.  It'll be up to the kernel track organiser(s)
> whether to accept it to that track or whether they think it'll be more
> appropriate in the MM microconf.

That is partly my fault as well. I suggest to YoungJun for the LPC
2025 in this email:

https://lore.kernel.org/linux-mm/CAF8kJuMo3yNKOZL9n5UkHx_O5cTZts287HOnQOu=KqQcnbrMdg@mail.gmail.com/

What I have in mind is extract as you said, the MM track Micro
Conference, and CC the linux-mm mail list as well. I forgot to mention
the details of the MM Micro Conference track part in my suggestion
email.

Anyway, is there any conflict to apply to LPC MM Micro Conference
track as well? Of course which conference to apply to is a decision
for YoungJun to make. I am just curious what options are available
now.

Hi, YoungJun,

If you decide to apply for LPC MM MC track as well, don't forget to
register yourself as a speaker on the LPC website.
https://lpc.events/event/19/abstracts/
The lower right of the page, there is a button "Submit a new abstract",
Click on that to start the process. Don't forget to select the pull
down menu MM Micro conference.

Hopefully see you in LPC then.

Chris

Re: [TECH TOPIC] Per-cgroup Swap Device Control

[Steven Rostedt]

On Fri, 22 Aug 2025 11:13:41 -0700
Chris Li <chrisl@kernel.org> wrote:

> Anyway, is there any conflict to apply to LPC MM Micro Conference
> track as well? Of course which conference to apply to is a decision
> for YoungJun to make. I am just curious what options are available
> now.

Note that MC topics are more discussion focused than either the Refereed or
Kernel Summit tracks. A MC topic is between 15 to 30 minutes which does not
give much time for presentations. A Track topic is longer and allows more
presentation of the topic. Also, acceptance to a Track talk gives a pass to
Plumbers, whereas acceptance to an MC topic does not guarantee one.

> 
> Hi, YoungJun,
> 
> If you decide to apply for LPC MM MC track as well, don't forget to
> register yourself as a speaker on the LPC website.
> https://lpc.events/event/19/abstracts/
> The lower right of the page, there is a button "Submit a new abstract",
> Click on that to start the process. Don't forget to select the pull
> down menu MM Micro conference.

The part I left out of Ted's email was:

   Secondly, please create a topic at the Linux Plumbers Conference
   proposal submission site and target it to the Kernel Summit track:

        https://lpc.events/event/19/abstracts

   Please do both steps.  I'll try to notice if someone forgets one or the
   other, but your chances of making sure your proposal gets the necessary
   attention and consideration are maximized by submitting both to the
   mailing list and the web site.


So YoungJun has already signed up to the website and proposed a Kernel
Summit track. It can be switched over to a MM MC topic by editing the
submitted abstract and switch the Track over to:

  "Kernel Memory Management MC"

-- Steve

Re: [TECH TOPIC] Per-cgroup Swap Device Control

[YoungJun Park]

On Fri, Aug 22, 2025 at 02:26:50PM -0400, Steven Rostedt wrote:
> On Fri, 22 Aug 2025 11:13:41 -0700
> Chris Li <chrisl@kernel.org> wrote:
> 
> > Anyway, is there any conflict to apply to LPC MM Micro Conference
> > track as well? Of course which conference to apply to is a decision
> > for YoungJun to make. I am just curious what options are available
> > now.
> 
> Note that MC topics are more discussion focused than either the Refereed or
> Kernel Summit tracks. A MC topic is between 15 to 30 minutes which does not
> give much time for presentations. A Track topic is longer and allows more
> presentation of the topic. Also, acceptance to a Track talk gives a pass to
> Plumbers, whereas acceptance to an MC topic does not guarantee one.
> 
> > 
> > Hi, YoungJun,
> > 
> > If you decide to apply for LPC MM MC track as well, don't forget to
> > register yourself as a speaker on the LPC website.
> > https://lpc.events/event/19/abstracts/
> > The lower right of the page, there is a button "Submit a new abstract",
> > Click on that to start the process. Don't forget to select the pull
> > down menu MM Micro conference.
> 
> The part I left out of Ted's email was:
> 
>    Secondly, please create a topic at the Linux Plumbers Conference
>    proposal submission site and target it to the Kernel Summit track:
> 
>         https://lpc.events/event/19/abstracts
> 
>    Please do both steps.  I'll try to notice if someone forgets one or the
>    other, but your chances of making sure your proposal gets the necessary
>    attention and consideration are maximized by submitting both to the
>    mailing list and the web site.
> 
> 
> So YoungJun has already signed up to the website and proposed a Kernel
> Summit track. It can be switched over to a MM MC topic by editing the
> submitted abstract and switch the Track over to:
> 
>   "Kernel Memory Management MC"
> 
> -- Steve

Thanks everyone for the clarifications and helpful guidance.  
I have updated my submission and switched the track to
"Kernel Memory Management MC"

Best Regards,
Youngjun Park.