lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <CAF8kJuO4-yQY9DkKm+1dvqA+QzPyCtCStoLJ4MEVNwbrBQRTLw@mail.gmail.com> Date: Tue, 12 Dec 2023 16:29:08 -0800 From: Chris Li <chrisl@...nel.org> To: Nhat Pham <nphamcs@...il.com> Cc: Johannes Weiner <hannes@...xchg.org>, akpm@...ux-foundation.org, tj@...nel.org, lizefan.x@...edance.com, cerasuolodomenico@...il.com, yosryahmed@...gle.com, sjenning@...hat.com, ddstreet@...e.org, vitaly.wool@...sulko.com, mhocko@...nel.org, roman.gushchin@...ux.dev, shakeelb@...gle.com, muchun.song@...ux.dev, hughd@...gle.com, corbet@....net, konrad.wilk@...cle.com, senozhatsky@...omium.org, rppt@...nel.org, linux-mm@...ck.org, kernel-team@...a.com, linux-kernel@...r.kernel.org, linux-doc@...r.kernel.org, david@...t.cz, Kairui Song <kasong@...cent.com>, Minchan Kim <minchan@...gle.com>, Zhongkun He <hezhongkun.hzk@...edance.com> Subject: Re: [PATCH v6] zswap: memcontrol: implement zswap writeback disabling On Tue, Dec 12, 2023 at 1:36 PM Nhat Pham <nphamcs@...il.com> 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
Powered by blists - more mailing lists