On Thu, Dec 14, 2023 at 09:34:06AM -0800, Christopher Li wrote: > On Thu, Dec 14, 2023 at 9:11 AM Johannes Weiner <hannes@xxxxxxxxxxx> wrote: > > > > Hi Johannes, > > > > > > I haven't been following the thread closely, but I noticed the discussion > > > about potential use cases for zram with memcg. > > > > > > One interesting idea I have is to implement a swap controller per cgroup. > > > This would allow us to tailor the zram swap behavior to the specific needs of > > > different groups. > > > > > > For example, Group A, which is sensitive to swap latency, could use zram swap > > > with a fast compression setting, even if it sacrifices some compression ratio. > > > This would prioritize quick access to swapped data, even if it takes up more space. > > > > > > On the other hand, Group B, which can tolerate higher swap latency, could benefit > > > from a slower compression setting that achieves a higher compression ratio. > > > This would maximize memory efficiency at the cost of slightly slower data access. > > > > > > This approach could provide a more nuanced and flexible way to manage swap usage > > > within different cgroups. > > > > That makes sense to me. > > > > It sounds to me like per-cgroup swapfiles would be the easiest > > solution to this. Then you can create zram devices with different > > configurations and assign them to individual cgroups. > > Ideally you need zram then following swap file after the zram. That > would be a list of the swap files rather than just one swapfile per > cgroup. > > > This would also apply to Kairu's usecase: assign zrams and hdd backups > > as needed on a per-cgroup basis. > > Same there, Kairui's request involves ZRAM and at least one extra swap > file. In other words, you really need a per cgroup swap file list. Why is that a problem? swapon(zram, cgroup=foo) swapon(hdd, cgroup=foo) > > In addition, it would naturally solve scalability and isolation > > problems when multiple containers would otherwise be hammering on the > > same swap backends and locks. > > > > It would also only require one, relatively simple new interface, such > > as a cgroup parameter to swapon(). > > > > That's highly preferable over a complex configuration file like > > memory.swap.tiers that needs to solve all sorts of visibility and > > namespace issues and duplicate the full configuration interface of > > every backend in some new, custom syntax. > > If you don't like the syntax of memory.swap.tiers, I am open to > suggestions of your preferred syntax as well. The essicents of the > swap.tiers is a per cgroup list of the swap back ends. The names imply > that. I am not married to any given syntax of how to specify the list. > Its goal matches the above requirement pretty well. Except Minchan said that he would also like different zram parameters depending on the cgroup. There is no way we'll add a memory.swap.tiers with a new configuration language for backend parameters.
