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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <6nuc6oijrfn3aejkzr74vuzipijuyodgqc56y526sv6d75kiwk@mmxi65rmj3yn>
Date: Fri, 7 Mar 2025 14:19:23 +0900
From: Sergey Senozhatsky <senozhatsky@...omium.org>
To: Herbert Xu <herbert@...dor.apana.org.au>
Cc: Yosry Ahmed <yosry.ahmed@...ux.dev>, 
	Sergey Senozhatsky <senozhatsky@...omium.org>, Andrew Morton <akpm@...ux-foundation.org>, 
	Johannes Weiner <hannes@...xchg.org>, Nhat Pham <nphamcs@...il.com>, 
	Chengming Zhou <chengming.zhou@...ux.dev>, Minchan Kim <minchan@...nel.org>, 
	Thomas Gleixner <tglx@...utronix.de>, Peter Zijlstra <peterz@...radead.org>, linux-mm@...ck.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH mm-unstable 3/5] mm: zpool: Remove object mapping APIs

On (25/03/07 10:38), Herbert Xu wrote:
> On Thu, Mar 06, 2025 at 04:55:07PM +0000, Yosry Ahmed wrote:
> >
> > The zswap and zsmalloc look good and the code is simpler. I am fine with
> > this approach if Sergey is fine with it, although I wonder if we should
> > update Sergey's patches in mm-unstable do this directly. Currently we
> > are switching from mapping APIs to read/write APIs, and then quickly to
> > the pinning APIs. The history will be confusing.
> > 
> > Sergey, do you prefer if we keep things as-is, or if you update your
> > series to incorporate Herbert's changes for zsmalloc/zram, then I can
> > update my series to incorporate the changes in zswap?
> > 
> > We can also combine the series into a single updated one with
> > zsmalloc/zram/zswap changes.
> > 
> > Let me know what you prefer.
> 
> This patch is only illustrating what zswap would look like once we
> move to an SG-based interface.  So I'm not actually submitting it
> for inclusion at this time.

Ah, OK, that's good to know, I was also a bit puzzled.
Perhaps next time we can label such patches as "POC" or
something.

> Sergey has volunteed to add parameter support to acomp.  Let's
> wait for that before making these changes to zsmalloc/zswap.

Yup, I'll keep you posted (once I have something.)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ