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] [thread-next>] [day] [month] [year] [list]

Date: Tue, 25 Jun 2024 10:22:18 -0700
From: Nhat Pham <nphamcs@...il.com>
To: Yosry Ahmed <yosryahmed@...gle.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 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:

1. Deprecate either zbud or z3fold. We do not really need both of them.

2. Make zsmalloc independent of MMU, somehow (IIRC, compaction was one
reason right? maybe making zsmalloc compaction dependent on MMU
availability?).

3. Deprecate the remaining one - zsmalloc can be used in all deployments now.

4. (Optional) Maybe adding another allocator for the edge cases that
zsmalloc does not handle well? I'd need to see numbers to be convinced
that this is the case. I think I saw somewhere that Vitaly was working
on zblock - look forward to seeing this :)