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
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Wed, 6 Dec 2023 10:15:56 -0800
From:   Nhat Pham <nphamcs@...il.com>
To:     Chris Li <chrisl@...nel.org>
Cc:     Yosry Ahmed <yosryahmed@...gle.com>,
        Andrew Morton <akpm@...ux-foundation.org>, tj@...nel.org,
        lizefan.x@...edance.com, Johannes Weiner <hannes@...xchg.org>,
        Domenico Cerasuolo <cerasuolodomenico@...il.com>,
        Seth Jennings <sjenning@...hat.com>,
        Dan Streetman <ddstreet@...e.org>,
        Vitaly Wool <vitaly.wool@...sulko.com>,
        Michal Hocko <mhocko@...nel.org>,
        Roman Gushchin <roman.gushchin@...ux.dev>,
        Shakeel Butt <shakeelb@...gle.com>,
        Muchun Song <muchun.song@...ux.dev>,
        Hugh Dickins <hughd@...gle.com>, corbet@....net,
        Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
        senozhatsky@...omium.org, rppt@...nel.org,
        linux-mm <linux-mm@...ck.org>, kernel-team@...a.com,
        LKML <linux-kernel@...r.kernel.org>, linux-doc@...r.kernel.org,
        david@...t.cz, Minchan Kim <minchan@...gle.com>,
        Kairui Song <kasong@...cent.com>,
        Zhongkun He <hezhongkun.hzk@...edance.com>
Subject: Re: [PATCH v5] zswap: memcontrol: implement zswap writeback disabling

On Wed, Nov 22, 2023 at 7:01 AM Chris Li <chrisl@...nel.org> wrote:
>
> On Tue, Nov 21, 2023 at 5:19 PM Nhat Pham <nphamcs@...il.com> wrote:
>
> > > "all": zswap + swapfile
> > > "zswap": zswap only
> > > "no_zswap": swapfile only.
> > > "none": no swap.
> > >
> > > All keyword names are open to suggestions.
> >
> > SGTM! There might be some functionality duplication between
> > memory.swap.tiers = no_zswap and memory.zswap.max = 0, but
> > otherwise this seems reasonable to me.
> >
> > no_zswap sounds a bit awkward, but I can't come up with a better
> > name.
>
> I sleep on it a bit. I  should apply my own suggestion of using the
> positive words rather than negative one to myself.
> I actually define it as a non RAM base swap device. How about "disk"?
> It will include SSD and HDD disk.
>
> The current 4 combination will be:
>
> "all": zswap + disk swap file
> "zswap": zswap only
> "disk": disk only (including SSD and HDD)
> "none": no swap for you.
>
> Chris

Hi Chris,

I chatted with Johannes a bit more about this design. While we still
think it's potentially useful for the future, it lacks a concrete use
case at the moment. We don't even have the infrastructure for multiple
swap tiers at the moment, so adding this interface now is just making
it more confusing for the users. I think zswap.writeback is a much
more specific interface, with concrete and immediate usability (it
stems from internal chatters and requests - so the demand is already
there).

I think we should just land the change we currently have (rebased on
top of mm-unstable to resolve merge conflicts etc.). I don't think
zswap.writeback will get in the way of any swap.tiers functionality,
correct? There might be some functionality duplication, but that's not
too bad IHMO. Then we can work on swap.tiers design and implementation
as we add the support for multiple swap tiers.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ