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

[Shakeel Butt <shakeel.butt@linux.dev>]

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.