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

[YoungJun Park <youngjun.park@lge.com>]

On Tue, Mar 17, 2026 at 08:54:11PM -0700, Shakeel Butt wrote:
> 
> 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.

Thank you for the feedback. I understand your point.
I have already replied to the other comments as well. Since this
thread has become quite cluttered with various topics, I believe
it would be better to address this in the upcoming v5 patchset.

I will decide on the implementation and design based on our
discussions (including the ones with Chris). I will also provide
an explanation of the reasoning and future extensibility in the
v5 cover letter. It would be great to continue our discussion
and make a decision in the new v5 thread.

Best regards,
Youngjun Park