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

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

On Mon, Mar 02, 2026 at 01:27:31PM -0800, Shakeel Butt wrote:
>
> Hi YoungJun,
>
> Sorry for the late response.

Hi Shakeel, No problem :)

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

Thanks for the summary! Yes, that describes our use case accurately.

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

I agree with the value and flexibility of BPF, but there is still some debate
on whether it should be the mandatory prerequisite for this feature.

While I understand your point that BPF is reasonable for complex environments,
requiring BPF solely for this feature in resource-constrained embedded systems
(where it might be disabled by default) is a significant hurdle. This trade-off
is a key reason why I am advocating for the memcg interface.

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

Yes, effectively, if BPF is applied, it opens up the possibility to control
swap logic at various levels (process unit, cgroup unit, etc.), so it would
likely become a superset of other mechanisms.

However, despite BPF's benefits, I would like to propose proceeding with a more
restricted memcg approach, which I will detail below.

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

Understood. My suggestion regarding the CONFIG option was to mark it as
'experimental' to allow usage for specific cases like ours while reserving
broader API stabilization for later, but I accept your point about API breakage
rules.

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

So, just to clarify, are you open to discussing this restricted direction?

To reiterate, this would mean enforcing a uniform policy for all children
within a memcg where the swap tier is configured.

For our use case, this is currently sufficient.

We deal with memcg's tree itself as one workload. 
This workload can use its specific swap device selectively.
This is my view.

Chris, would you be okay with proceeding in this direction as a starting point?

> Beside, give a bit more thought on potential future features e.g. demotion and
> reason about how you would incorporate those features.

Regarding demotion (assuming you refer to migration based on swap device
tiers), I don't foresee issues if we apply tiered swap devices per memcg.

In fact, the 'tier' concept was proposed specifically as an abstraction layer
to structure hierarchical swap devices. Since the current direction treats it
as a unified tier view configured by the parent memcg, features like demotion
should fit naturally.

Regarding future extensibility, I would like to add:

1. From the memcg perspective:
Applying memcg in this restricted manner minimizes complexity. While future
expansions (such as complex tier inheritance rules or handling setting
differences between parent and child) will require careful discussion, the
restricted approach avoids immediate conflicts and side effects.

2. The swap tier abstraction itself:
The introduction of swap tiers primarily enables swap device assignment.
However, this abstraction also opens the door for extended use cases such as
inter-tier migration (demotion), round-robin policies between tiers, tier-based
VMA swap, or even per-process swap controls in the future.

I believe this patch set is acceptable as it introduces this foundational
concept and applies a specific use case that does not contradict core memcg
principles.

Best regards,
Youngjun Park