Re: [RFC PATCH v2 0/5] mm/swap, memcg: Introduce swap tiers for cgroup based swap control

[Shakeel Butt <shakeel.butt@linux.dev>]

Hi YoungJun, sorry for the late response.

On Wed, Mar 04, 2026 at 04:27:37PM +0900, YoungJun Park wrote:
[...]
> > > - You already acknowledged the use-case for assigning
> > >   different swap devices to different workloads. Your
> > >   objection is specifically about hierarchical parent-child
> > >   partitioning. If the interface enforced uniform policy
> > >   within a subtree, would that be acceptable?
> >
> > Let's start with that or maybe comeup with concrete examples on how that would
> > look like.
> 
> So, just to clarify, are you open to discussing this restricted direction?

I am open to all options. The only thing I am looking for is we have thought
through the pros and cons of all the options and have thought about
extensibility of the interface.

> 
> To reiterate, this would mean enforcing a uniform policy for all children
> within a memcg where the swap tier is configured.

Give me an example on how this would look like.

> 
> For our use case, this is currently sufficient.
> 
> We deal with memcg's tree itself as one workload. 
> This workload can use its specific swap device selectively.
> This is my view.
> 
> Chris, would you be okay with proceeding in this direction as a starting point?
> 
> > Beside, give a bit more thought on potential future features e.g. demotion and
> > reason about how you would incorporate those features.
> 
> Regarding demotion (assuming you refer to migration based on swap device
> tiers), I don't foresee issues if we apply tiered swap devices per memcg.
> 
> In fact, the 'tier' concept was proposed specifically as an abstraction layer
> to structure hierarchical swap devices. Since the current direction treats it
> as a unified tier view configured by the parent memcg, features like demotion
> should fit naturally.
> 
> Regarding future extensibility, I would like to add:
> 
> 1. From the memcg perspective:
> Applying memcg in this restricted manner minimizes complexity. While future
> expansions (such as complex tier inheritance rules or handling setting
> differences between parent and child) will require careful discussion, the
> restricted approach avoids immediate conflicts and side effects.
> 
> 2. The swap tier abstraction itself:
> The introduction of swap tiers primarily enables swap device assignment.
> However, this abstraction also opens the door for extended use cases such as
> inter-tier migration (demotion), round-robin policies between tiers, tier-based
> VMA swap, or even per-process swap controls in the future.

These are good examples. Just show how the proposed interface will be good for
such features. No need to implement any such feature.