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

YoungJun Park
2026-03-10T02:14:24Z

On Mon, Mar 02, 2026 at 01:27:31PM -0800, Shakeel Butt wrote:
>
> Hi YoungJun,
>
> Sorry for the late response.
>
> On Sun, Feb 22, 2026 at 10:16:04AM +0900, YoungJun Park wrote:
> [...]
>
> Let me summarize our discussion first:
>
> You have a use-case where they have systems running multiple workloads and
> have multiple swap devices. Those swap devices have different performance
> capabilities and they want to restrict/assign swap devices to the workloads. For
> example assigning a low latency SSD swap device to latency sensitive workload
> and slow disk swap to latency tolerant workload. (please correct me if
> I misunderstood something).
>
> The use-case seems reasonable to me but I have concerns related to adding an
> interface to memory cgroups. Mainly I am not clear how hierarchical semantics on
> such interface would look like. In addition, I think it would be too rigid and
> will be very hard to evolve for future features. To me enabling this
> functionality through BPF would give much more flexibility and will be more
> future proof.
>
> >
> > After reading the reply and re-think more of it.
> >
> > I have a few questions regarding the BPF-first approach you
> > suggested, if you don't mind. Some of them I am re-asking
> > because I feel they have not been clearly addressed yet.
> >
> > - We are in an embedded environment where enabling additional
> > kernel compile options is costly. BPF is disabled by
> > default in some of our production configurations. From a
> > trade-off perspective, does it make sense to enable BPF
> > just for swap device control?
>
> To me, it is reasonable to enable BPF for environment running multiple
> workloads and having multiple swap devices.
>
> >
> > - You suggest starting with BPF and discussing a stable
> > interface later. I am genuinely curious, are there actual
> > precedents where a BPF prototype graduated into a stable
> > kernel interface?
>
> After giving some thought, I think once we have BPF working, adding another
> interface for the same feature would not be an option. So, we have decide
> upfront which route to take.
>
> >
> > - You raised that stable interfaces are hard to remove. Would
> > gating it behind a CONFIG option or marking it experimental
> > be an acceptable compromise?
>
> I think hiding behind CONFIG options do not really protect against the usage and
> the rule of no API breakage usually apply.
>
> >
> > - 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.
>
> Beside, give a bit more thought on potential future features e.g. demotion and
> reason about how you would incorporate those features.
Hello Shakeel, Chris Li,

Just sending a gentle ping on my previous reply. :D

To quickly summarize the main points:
(I might wrongly undestand your intentaion, then correct me please :) )

* Regarding Shakeel's BPF approach, stable interface movement would be difficult,
so we need to choose a direction. I prefer adding it to memcg for immediate
usage, and if it proves highly effective, we can consider transitioning
entirely to BPF later.

* Shakeel seemed somewhat positive about matching all child tiers from the
parent if tiers are applied to a specific cgroup use case, and I would like
to start the discussion from here. Chris, I would appreciate your thoughts
on whether you agree with this direction of unifying all swap tiers within
the hierarchy as a first step.

Here are some additional thoughts I had after my last reply:
(Thanks for the insight and discussion. Hyungjun Cho)

* Cgroup distribution:
A direct use case where cgroup A distributes a portion to A' is hard to
imagine, but the following scenario is possible:

swap: +SSD +HDD +NET
cgroup hierarchy:
/
A : +HDD +NET
A'(app 1) +HDD, A''(app 2) +NET

Cgroup A has two interdependent apps, and +SSD is excluded for more critical
services. App1 (A') avoids reclaim with a large hot working set using fast
+HDD, while App2 (A'') has a cold working set using slow/large +NET.

* Promotion / Demotion:
Unlike memory tiers, swap tiers are directly assigned by the user, providing
flexibility beyond just speed. Since swap priority is already a user choice,
this design makes perfect sense.

With this arbitrary assignment, we can support higher-to-slower tier
allocation, similar to current memory tiers, if user properly bind the tier.
(more flexible as I think)

Within the same tier (meaning we define it as equal speed(tier)), we could apply round-robin or other
distribution policies via an additional tier layer interface. The current
equal-priority round-robin policy could also be elevated to the tier layer.

Best regards,
Youngjun Park