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

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

> Sorry for the late reply, busy days.

No worries at all. Hi Chris,

> >
> > 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.
> 
> I am very concerned about locking down the kernel user interface just
> because things might change in the future. If we need to use BPF to
> get the stable user space API, I am fine with that. Completely
> blocking the new cgroup interface because of a worry about future
> change is not justifiable IMHO. There ought to be some intermediate
> staging we can do e.g. debugfs interface to test and play with the new
> API. We should focus on designing the interface as well as possible
> right now.

I completely agree with using the cgroup interface. We have clear use cases
and have already shared many thoughts on this direction.

> > * 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.
> 
> Does that mean all children will only use the parent cgroup setting?
> Wouldn't that be more restrictive and counteract the goal of making
> the API more future-proof?
> For the record, the current Google deployment can uses a different
> swap device for the child cgroup, in the current delpyment.
> The typical setup is that the top-level cgroup is a job running on a
> VM. Then there is a second cgroup level for the VMM guest memory
> allocation; swap device selection occurs at this second level.
> There is also zswap vs SSD, the SSD is something new starting the
> deployment. So it's not just about enabling zswap or not. We also need
> to select the swap device.
> If you get the current cgroup, it will need to walk the parent cgroup
> chain to find the toplevel cgroup any way. I just think having the
> hierarchy makes more sense.

Since you confirmed the use case for allowing child cgroups to have different
swap devices from their parents, I would like to keep the current hierarchical
design. It seems Shakeel was hesitant mainly due to the lack of a known use
case for this. If Shakeel has further questions, I would appreciate it if you
could help explain the Google deployment use case.

> We need to find customers willing to use this promotion/demotion. I
> hesitate to build something while hoping to find someone to use it
> later.
> It would be good to identify someone who can immediately use and test
> this promotion/demotion feature.
> We should focus the discussion on achieving a more flexible swap
> device selection approach and reach a conclusion on the API discussion
> before discussing promotion/demotion. If we can't even have a usable
> swap tier interface, there is nothing to promote.
> 
Since I have already sent RFCv3, Patch v4
(https://lore.kernel.org/linux-mm/20260217000950.4015880-1-youngjun.park@lge.com/)_
and we seem aligned on the core direction,
I will proceed with sending v5 based on the current design.

@Shakeel: I have been waiting for your feedback longtime, but I will move forward with
v5 for now. Since Chris confirmed a solid use case for the child-parent
hierarchy, please let us know if you have any remaining concerns when I post
the v5 patch.

As a brief history, we have evolved this proposal from per-cgroup priority to
swap tiers, presented it at LPC, and are actually using it in our production
environment. I sincerely hope we can get this merged into mainline. 
and evolve this mechanism after applying it.

Thanks,
Youngjun Park