linux-kernel - Re: [RFC PATCH 2/2] zsmalloc: chain-length configuration should consider other metrics

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]

Message-ID: <e62r7pj6622u6oko7i7b5qtzil75mwjnpat2q2stk7m4e7zmn3@enmdxmq7zt4f>
Date: Mon, 12 Jan 2026 20:56:52 +0000
From: Yosry Ahmed <yosry.ahmed@...ux.dev>
To: Sergey Senozhatsky <senozhatsky@...omium.org>
Cc: Herbert Xu <herbert@...dor.apana.org.au>, 
	Andrew Morton <akpm@...ux-foundation.org>, Nhat Pham <nphamcs@...il.com>, Minchan Kim <minchan@...nel.org>, 
	Johannes Weiner <hannes@...xchg.org>, Brian Geffon <bgeffon@...gle.com>, linux-kernel@...r.kernel.org, 
	linux-mm@...ck.org
Subject: Re: [RFC PATCH 2/2] zsmalloc: chain-length configuration should
 consider other metrics

On Mon, Jan 12, 2026 at 02:07:24PM +0900, Sergey Senozhatsky wrote:
> On (26/01/12 13:01), Herbert Xu wrote:
> > On Fri, Jan 09, 2026 at 04:02:51PM +0000, Yosry Ahmed wrote:
> > > 
> > > Herbert, do you mind taking a look at this? It looks sane to me except
> > > for one question below.
> > 
> > Looks alright to me too.
> > 
> > > > +		size_t sizes[2];
> > > > +
> > > > +		/* this object spans two pages */
> > > > +		sizes[0] = PAGE_SIZE - off;
> > > > +		sizes[1] = mem_len - sizes[0];
> > > > +
> > > > +		sg_init_table(sg, 2);
> > > > +		sg_set_page(sg, zpdesc_page(zpdesc), sizes[0], off);
> > > > +
> > > > +		zpdesc = get_next_zpdesc(zpdesc);
> > > > +		sg = sg_next(sg);
> > > 
> > > Is this stateful? Will the SG list be returned pointing at the second
> > > page now?
> > 
> > It makes no difference because we just called sg_init_table(sg, 2),
> > so sg_next(sg) is equivalent to &sg[1].
> 
> I did it this way for (sort of) consistency: sg next follows zpdesc next.

Makes sense, I think I confused myself earlier. Do you plan to switch
the existing interfaces to use SG lists for both zswap and zram? Or does
zram still need the old interfaces?