On Tue, Dec 12, 2023 at 1:36 PM Nhat Pham <nphamcs@xxxxxxxxx> wrote: > > Even if such a file were to show up, I'm not convinced it should even > > include zswap as one of the tiers. Zswap isn't a regular swap backend, > > it doesn't show up in /proc/swaps, it can't be a second tier, the way > > it interacts with its backend file is very different than how two > > swapfiles of different priorities interact with each other, it's > > already controllable with memory.zswap.max, etc. > > This is honestly the thing I was originally most iffy about :) zswap > is architecturally and semantically separate from other swap options. > It gets really confusing to lump it as part of the swap tiers. The writeback option is about interacting with other swap backends. So technically it is not zswap alone. writeback = 0 will disable SSD swap as well. I am not against merging the write back. I just want to make sure 1) better alternatives can be developed 2) zswap.writeback can obsolete if a better alternative is available. > > > > > I'm open to discussing usecases and proposals for more fine-grained > > per-cgroup backend control. We've had discussions about per-cgroup > > swapfiles in the past. Cgroup parameters for swapon are another > > thought. There are several options and many considerations. The > > memory.swap.tiers idea is the newest, has probably had the least > > amount of discussion among them, and looks the least convincing to me. > > Definitely. zswap.writeback is a really concrete feature, with > immediate use-case, whereas swap.tiers seem a bit nebulous to me now, > the more we discuss it. I'm not against the inclusion of something > along its line though, and I'm definitely not trying to limit the use > case of other folks - I'd be happy to contribute my engineering hours > towards the discussion of the multi-tier swapping design (both > internal implementation and and public interface), as well as actual > code, when that design is fully fleshed out :) Great to hear that. I think the discussion so far shows the alternative usage cases of the swap backend/tires is real. > > > > > Let's work out the requirements first. > > > > The "conflict" with memory.zswap.writeback is a red herring - it's no > > more of a conflict than setting memory.swap.tiers to "zswap" or "all" > > and then setting memory.zswap.max or memory.swap.max to 0. > > Yup. Care to elaborate it more? I don't understand the conflict part. I do ask Johannes in my previous email for clarification. One is the superset of the other. I don't consider that as a conflict. If we can have both to choose from, obviously I would pick the one that is more general and flexible. Chris
