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

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

On Sun, Feb 22, 2026 at 09:56:13PM -0800, Shakeel Butt wrote:

While I await your response on the other thread, 
I thought I would answer these questions first :)

> Hi YoungJun,
> 
> I see you have sent a separate email on BPF specific questions to which I will
> respond separately, here I will respond to other questions/comments.
> 
> On Sat, Feb 21, 2026 at 11:30:59PM +0900, YoungJun Park wrote:
> > On Fri, Feb 20, 2026 at 07:47:22PM -0800, Shakeel Butt wrote:
> [...]
> > 
> > > Taking a step back, can you describe your use-case a bit more and share
> > > requirements?
> > 
> > Our use case is simple at now. 
> > We have two swap devices with different performance
> > characteristics and want to assign different swap devices to different
> > workloads (cgroups).
> 
> If you don't mind, can you share a bit more about the cgroup hierarchy structure
> of your deployment. Do you use cgroup v1 or v2 on your production environment?

We are primarily targeting Cgroup v2 at now.

> > >
> > For some background, when I initially proposed this, I suggested allowing
> > per-cgroup swap device priorities so that it could also accommodate the
> > broader scenarios you mentioned. However, since even our own use case
> > does not require reversing swap priorities within a cgroup, we pivoted
> > to the "swap tier" mechanism that Chris proposed.
> > 
> > > 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?
> > 
> > Both. If devices are in the same tier with the same priority, round robin.
> > If they are in the same tier with different priorities, or in different
> > tiers, ordering applies. The current tier structure should be able to
> > satisfy either preference.
> 
> I assume this is the same swap priorities as of today, right? You want similar
> priority behavior within a tier.

That is correct; the swap priority behavior remains unchanged. 

While this is slightly tangential, I see a potential use case for swap tiers to
improve the current swap device selection logic, which is currently tightly
coupled with priority.

> > > 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?
> > 
> > This was originally Chris's idea. I think he explained the rationale
> > well in his reply.
> > 
> > > 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?
> > 
> > One possible scenario is reducing lock contention by partitioning swap
> > devices between parent and child cgroups.
> 
> The lock contention is orthogonal (and distraction here).

Understood. It was just a hypothetical scenario where I thought there might be
an additional benefit, but I agree we can set it aside for now.

> > 
> > > 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.
> > 
> > We have clear production use cases from both us and Chris, and I also
> > presented a deployment example in the cover letter.
> > 
> > I think it is hard to design concretely for future use cases at this
> > point. When those needs become clearer, BPF with its flexibility
> > would be a better fit then. I see BPF as a natural extension path
> > rather than a starting point.
> > 
> > For now, guarding the memcg & tier behind a CONFIG option would
> > let us move forward without committing to a stable interface, and
> > we can always pivot to BPF later if needed
> 
> I think your use-case is very clear. Before committing to any options, I want us
> to brainstorm all options and gather pros/cons and then make an informed

This relates to my response in the other email thread, and I think it would be
good to discuss it further there.

It seems the concern is that distributing swap devices using the memcg
hierarchy might be seen as over-engineering (overspec) since there isn't a
concrete use case for it yet. I have included a proposal to mitigate this
concern in the other thread.

> decision. Anyways I will respond to your other email (in a day or two).

Sounds good. I look forward to your explanation.

Best regards,
Youngjun Park