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

Shakeel Butt
2026-02-23T05:56:24Z

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?

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

>
> > 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).

>
> > 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
decision. Anyways I will respond to your other email (in a day or two).

Shakeel