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

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

Please don't send a new version of the series before concluding the discussion
on the previous one.

On Fri, Feb 13, 2026 at 12:58:40PM +0900, YoungJun Park wrote:
> > 
> > One of the LPC feedback you missed is to not add memcg interface for
> > this functionality and explore BPF way instead.
> > 
> > We are normally very conservative to add new interfaces to cgroup.
> > However I am not even convinced that memcg interface is the right way to
> > expose this functionality. Swap is currently global and the idea to
> > limit or assign specific swap devices to specific cgroups makes sense
> > but that is the decision for the job orchestator or node controller.
> > Allowing workloads to pick and choose swap devices do not make sense to
> > me.
> 
> Apologies for overlooking the feedback regarding the BPF approach. Thank you
> for the suggestion.

No need for apologies. These things take time and multiple iterations.

> 
> I agree that using BPF would provide greater flexibility, allowing control not
> just at the memcg level, but also per-process or for complex workloads.
> (As like orchestrator and node controller)

Yes it provides the flexibility but that is not the main reason I am pushing for
it. The reason I want you to first try the BPF approach without introducing any
stable interfaces. Show how swap tiers will be used and configured in production
environment and then we can talk if a stable interface is needed. I am still not
convinced that swap tiers need to be controlled hierarchically and the non-root
should be able to control it.

> 
> However, I am concerned that this level of freedom might introduce logical
> contradictions, particularly regarding cgroup hierarchy semantics.
> 
> For example, BPF might allow a topology that violates hierarchical constraints
> (a concern that was also touched upon during LPC)

Yes BPF provides more power but it is controlled by admin and admin can shoot
their foot in multiple ways.

> 
>   - Group A (Parent): Assigned to SSD1
>   - Group B (Child of A): Assigned to SSD2
> 
> If Group A has a `memory.swap.max` limit, and Group B swaps out to SSD2, it
> creates a consistency issue. Group B consumes Group A's swap quota, but it is
> utilizing a device (SSD2) that is distinct from the Parent's assignment. This
> could lead to situations where the Parent's limit is exhausted by usage on a
> device it effectively doesn't "own" or shouldn't be using.
> 
> One might suggest restricting BPF to strictly adhere to these hierarchical
> constraints.

No need to constraint anything.

Taking a step back, can you describe your use-case a bit more and share
requirements?

You have multiple swap devices of different properties and you want to assign
those swap devices to different workloads. Now couple of questions:

1. If more than one device is assign to a workload, do you want to have
   some kind of ordering between them for the worklod or do you want option to
   have round robin kind of policy?

2. What's the reason to use 'tiers' in the name? Is it similar to memory tiers
   and you want promotion/demotion among the tiers?

3. If a workload has multiple swap devices assigned, can you describe the
   scenario where such workloads need to partition/divide given devices to their
   sub-workloads?

Let's start with these questions. Please note that I want us to not just look at
the current use-case but brainstorm more future use-cases and then come up with
the solution which is more future proof.

thanks,
Shakeel