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

Message-Id: <98B3AFB0-EBD5-4779-A5DB-FFA6717E83C3@konsulko.se>
Date: Sat, 13 Sep 2025 15:55:16 +0200
From: Vitaly Wool <vitaly.wool@...sulko.se>
To: Yosry Ahmed <yosry.ahmed@...ux.dev>
Cc: 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 Sep 9, 2025, at 10:12 PM, Yosry Ahmed <yosry.ahmed@...ux.dev> wrote:
> 
> On Mon, Sep 08, 2025 at 09:18:01PM +0900, Sergey Senozhatsky wrote:
>> On (25/09/06 14:25), Sergey Senozhatsky wrote:
>>> On (25/09/05 19:57), Yosry Ahmed wrote:
>>>> I think Android uses zram+zsmalloc with 16K pages. Perhaps Sergey could
>>>> confirm.
>>> 
>>> I'm not working on android directly,
>>> 
>>> 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
* reworking size_classes based allocation to have uneven steps
* 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.

Another option would be to leave zsmalloc do its job on 4K pages and use zblock for bigger pages. But it is not possible at the moment because zpool api has been removed. Thats’s why I NACK’ed the zpool removal, at least until we have a replacement for it ready.

~Vitaly