linux-kernel - Re: [PATCH 0/3] mm: remove 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]

Message-ID: <u2kujkv47egugef25at3rykkwuztel6tg6rjqqadacv2nj3pkg@qmxkftyzmayd>
Date: Tue, 16 Sep 2025 12:29:51 +0900
From: Sergey Senozhatsky <senozhatsky@...omium.org>
To: Vitaly Wool <vitaly.wool@...sulko.se>
Cc: Yosry Ahmed <yosry.ahmed@...ux.dev>, 
	Sergey Senozhatsky <senozhatsky@...omium.org>, Vlastimil Babka <vbabka@...e.cz>, hannes@...xchg.org, 
	linux-kernel@...r.kernel.org, linux-mm@...ck.org, Andrew Morton <akpm@...ux-foundation.org>, 
	Christoph Hellwig <hch@...radead.org>
Subject: Re: [PATCH 0/3] mm: remove zpool

On (25/09/13 15:55), Vitaly Wool wrote:
> >>> I can confirm that android uses zram+zsmalloc.  As of 16K pages, there
> >>> was a way to toggle 16k pages on android (via system settings), I don't
> >>> know if this is the default now.
> >> 
> >> While I don't know what zsmalloc struggles Vitaly is referring to in
> >> particular, off the top of my head, zsmalloc does memcpy()'s for objects
> >> that span multiple pages, when zsmalloc kmap()'s both physical pages and
> >> memcpy()'s chunks of the object into a provided buffer. With 16K pages
> >> we can have rather larger compressed objects, so those memcpy() are likely
> >> more visible.  Attacking this would be a good idea, I guess.
> > 
> > Yeah I personally think attacking whatever problems zsmalloc has with
> > 16K pages is the way to go.
> 
> Well, there is a way out for 16+K pages, that being:
> * restricting zsmalloc to not have objects spanning across 2 pages

Yeah, the big problem with spanning objects is memcpy()-s, which we
currently need to do because zsmalloc() users expect linear address
from zs_map().  This doesn't need to be so, however [1], as zsmalloc()
can return SG-list instead and then upper layers (crypto/zcomp) should
handle that.

I have to admit, I haven't looked at zblock, so I don't know how
zblock handles it.  I'll try to look at it.

> * reworking size_classes based allocation to have uneven steps

If I understand you correctly, I thought about it briefly while
working on configurable zspage chain size [2], I think I even briefly
chatted with Minchan on "should we open code size classes instead?".
Then I looked at clustering (size_classes grouping and distribution)
and it wasn't too bad.  However, I don't think I looked at 16K setups,
things might be sad there.  Another thing in my to-look-at list.

While looking at size-classes clustering, I also sort of thought
about limiting zspages to one single page, so that zspages would
be a collection of fixed size chunks and each zspage would maintain
a bitmap of used/unused chinks, so that we can pack any objects into
zspage instead of "one particular size class".  But this has never
been materialized in any way,

> * as a result of the above, organising binary search for the right size object
>
> This will effectively turn zsmalloc into zblock, with some extra cruft that makes it far less comprehensible.

Is v4 [3] the most recent zblock version?

[1] https://lore.kernel.org/all/Z8K10w-6fIpDhYc6@gondor.apana.org.au
[2] https://lore.kernel.org/all/20230118005210.2814763-4-senozhatsky@chromium.org
[3] https://lore.kernel.org/all/20250412154207.2152667-1-vitaly.wool@konsulko.se