linux-kernel - Re: [PATCH 00/15] add zpdesc memory descriptor for zswap.zpool

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: Tue, 25 Jun 2024 14:02:44 -0700
From: Yosry Ahmed <yosryahmed@...gle.com>
To: Nhat Pham <nphamcs@...il.com>
Cc: Alex Shi <seakeel@...il.com>, alexs@...nel.org, 
	Vitaly Wool <vitaly.wool@...sulko.com>, Miaohe Lin <linmiaohe@...wei.com>, 
	Andrew Morton <akpm@...ux-foundation.org>, linux-kernel@...r.kernel.org, 
	linux-mm@...ck.org, minchan@...nel.org, willy@...radead.org, 
	senozhatsky@...omium.org, david@...hat.com, 42.hyeyoo@...il.com, 
	Shakeel Butt <shakeel.butt@...ux.dev>, Johannes Weiner <hannes@...xchg.org>
Subject: Re: [PATCH 00/15] add zpdesc memory descriptor for zswap.zpool

On Tue, Jun 25, 2024 at 10:22 AM Nhat Pham <nphamcs@...il.com> wrote:
>
> On Tue, Jun 25, 2024 at 3:32 AM Yosry Ahmed <yosryahmed@...gle.com> wrote:
> >
> > On Tue, Jun 25, 2024 at 1:11 AM Alex Shi <seakeel@...il.com> wrote:
> > >
> > > Thanks a lot for the info and comments! It's my stupid w/o checking the email list before work on it.
> > > Anyway don't know if z3fold would be removed, jut left this tested patchset here if someone need it.
> >
> > It's partially our fault for leaving z3fold knowing that it is headed
> > toward deprecation/removal. FWIW, I tried to remove it or mark it as
> > deprecated, but there was some resistance :/
> >
> Our apologies, Alex. Thank you for your contribution regardless!
>
> Regarding zbud and z3fold, this is the second time this conversation
> has come up within a week or so. Chengming was trying to revert the
> multiple zpool changes. zsmalloc (after we re-introduce the class
> locks) does not seem to regress (at least based on benchmarking), but
> z3fold and zbud suffer. I think we are starting to pay the price of
> maintaining z3fold and zbud:
>
> 1. Future improvement to related subsystems now hurts z3fold.
> Developers/maintainers have to spend extra mental capacity to consider
> this, and users could potentially see worse performance if they select
> z3fold/zbud unknowingly.
>
> 2. Contributors are confused on where they should spend their effort
> on improving.
>
> Can we at least have a roadmap for deprecating these 2? Something
> along the line of:

100% agreed. I think we can start with z3fold given that it doesn't
offer significant advantages over zbud in my testing, and zbud is
probably more popular since it was the default zpool for a while.

Then we should be able to remove zbud as well after we take care of
the MMU dependency in zsmalloc. After that, if no new allocators show
up in a while, we can drop the zpool abstraction entirely.

Just my 2c.