Re: [RFC PATCH v11 0/4] mm/swap: priority-based swap tiers with per-cgroup selection

[Youngjun Park]

On 2026-09-23 13:15, Johannes Weiner wrote:
> On Mon, Sep 21, 2026 at 01:20:11AM +0900, Youngjun Park wrote:
> > On 2026-09-16 16:04, Johannes Weiner wrote:
> > > On Thu, Sep 17, 2026 at 03:34:33AM +0900, Youngjun Park wrote:
> > > > Per-cgroup swap in debugfs
> > > > ==========================
> > > > 
> > > > Patches 3 and 4 let a memory cgroup choose its tiers through debugfs.
> > > > 
> > > >   # swapon -p 100 /dev/nvme0n1p2
> > > >   # swapon -p 50 /dev/sdb2
> > > >   # cat /sys/kernel/debug/swap/tiers
> > > >   Idx   Prio
> > > >   0     100
> > > >   1     50
> > > >   # echo "/batch 0x2" > /sys/kernel/debug/swap/memcg_tiers
> > > > 
> > > > Bit i of the mask is tier i, so /batch swaps only to sdb2. A tier keeps
> > > > its index for its lifetime, so the mask keeps selecting the same tier
> > > > across swapon and swapoff.
> > >
> > 
> > Hello Johannes,
> > 
> > Sorry for the late reply on a good suggestion :)
> 
> No worries, and same ^_^
> 
> > > Can the cgroup be given a priority limit? That would have pretty
> > > obvious inheritance semantics:
> > > root
> > > `- batch (memory.swap.prio.max = 20)
> > >    `- task (memory.swap.prio.max = max)
> > >    `- logs (memory.swap.prio.max = 10)
> > > `- interactive (memory.swap.prio.max = max)
> > >    `- task (memory.swap.prio.max)
> > 
> > Right, the inheritance is clear and easy to understand, and with this I
> > can pre-define the limit without knowing the mask value.
> >
> > But first, let me check the intent. Is the point that capping batch keeps
> > it from taking the faster tiers, so they are left for interactive?
> 
> Yes, basically, that's what I tried to express. Interactive has access
> to all available capacity. Batch only has access to lower tiers.
> 
> > If so, that matches our use case. Latency sensitive workloads get the
> > fast tiers, non-latency sensitive ones get the slow tiers. But...
> > 
> > Even then, the reverse cannot be expressed. A cap only cuts from the top,
> > so a latency sensitive workload given max can still fall back to the slow
> > tiers once the fast ones fill up. For example,
> > 
> >   tier0  tier1  tier2  tier3
> >     0     10     20     30
> > 
> > there is no way to say "use tier0 and tier1, but never fall back to tier2
> > or tier3". To cover that, the interface would also need a min value, or
> > some way to express a range.
> 
> Correct, this isn't covered by the above.
> > And even a range is not enough. Excluding only tier2 leaves a hole in the
> > middle, which no min/max pair can express. That needs per-tier selection,
> > which is what the mask,  and what I'd carry over to the memcg
> > interface later (Currently memcg.swap.tiers.max).
> > 
> > How do you think?
> 
> I think it could help to aggregate the usecases in the cover
> letter. Your cover letter describes how it works, which is great, but
> it would be good to understand better what the constraints are, how it
> fits in with other existing control surface and broader usage models.
> 
> With the above, yes, you can restrict who gets access to the
> privileged tiers top down, but not bottom up. Is that an issue? Keep
> in mind the alternative is cutting privileged groups OFF from certain
> available capacity. This seems somewhat counter-intuitive to me, and
> doesn't reflect a clean privilege hierarchy anymore.

Thanks for the explanation.

I thought about it many times and concluded you are right.
The reason is simple. the two cases the mask can express but prio.max
cannot (holes and bottom-up restriction) are possible with the mask,
but there is no real use case that needs them.

Therefore I see no reason to keep the
mask interface I proposed. prio.max can be extended naturally when needed.

For the record, the interface semantics have evolved as below, and
this discussion changes them once more.

  1. Per-cgroup swap priority for our usecase (initial proposal)
  2. Fixed ordering across cgroups (swap tier concept introduced)
  3. Child tiers as a subset of the parent's (after LPC)
  4. Switch to the memory.swap.tier.max interface
  5. Agreement to add the memcg interface after virtual swap lands
  6. Express tiers by swap priority, proposed as a debugfs interface
     until the memcg interface is added
  7. memory.swap.prio.max: cap the fastest tier a cgroup may use,
     i.e. top-down restriction (this discussion)

I agree with this direction. I'll describe the discussion history and
the resulting constraints more clearly in the cover letter.

Here are the next steps.

  - Change the debugfs interface to take a maximum priority instead
    of a tier mask.
  - Introduce memory.swap.prio.max after virtual swap lands.

Please let me know if you have further comments.

Thanks,
Youngjun