linux-kernel - Re: [PATCH v4] mm: add zblock allocator

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: <4CECDD1E-5227-4719-B826-F6AFC77D4D75@konsulko.se>
Date: Fri, 18 Apr 2025 12:56:02 +0200
From: Vitaly Wool <vitaly.wool@...sulko.se>
To: David Hildenbrand <david@...hat.com>
Cc: Johannes Weiner <hannes@...xchg.org>,
 linux-mm@...ck.org,
 akpm@...ux-foundation.org,
 linux-kernel@...r.kernel.org,
 Nhat Pham <nphamcs@...il.com>,
 Shakeel Butt <shakeel.butt@...ux.dev>,
 Igor Belousov <igor.b@...dev.am>
Subject: Re: [PATCH v4] mm: add zblock allocator



> On Apr 18, 2025, at 12:52 PM, David Hildenbrand <david@...hat.com> wrote:
> 
> On 16.04.25 14:09, Johannes Weiner wrote:
>> On Sat, Apr 12, 2025 at 05:42:07PM +0200, Vitaly Wool wrote:
>>> zblock is a special purpose allocator for storing compressed pages.
>>> It stores integer number of same size objects per its block. These
>>> blocks consist of several physical pages (2**n, i. e. 1/2/4/8).
>>> 
>>> With zblock, it is possible to densely arrange objects of various sizes
>>> resulting in low internal fragmentation. Also this allocator tries to
>>> fill incomplete blocks instead of adding new ones, in many cases
>>> providing a compression ratio comparable to zmalloc's.
>>> 
>>> zblock is also in most cases superior to zsmalloc with regard to
>>> average performance and worst execution times, thus allowing for better
>>> response time and real-time characteristics of the whole system.
>> Is there a reason not to use this allocation scheme in zsmalloc then?
>> I'm curious what others think, but I'm still not convinced a second
>> allocator makes sense. It's maintenance overhead, a permanent struggle
>> to match feature parity, and it fragments development and testing base.
>> Not long ago several slab allocators were removed for those
>> reasons. Likewise, we just deleted zbud and z3fold because they didn't
>> get any attention and bitrotted, but not before years of inflicting
>> pain through the zpool interface, users accidentally making very
>> suboptimal choices, reporting the same bugs over and over again etc.
>> If you discovered a better allocation scheme, that's excellent. But I
>> don't see why it warrants forking the entire allocator.
> 
> Just curious, I see a review on v4 happening on something that was nacked by two people in v2 [1].
> 
> Do these nack's still apply or were something clarified and they no longer apply?

The reasons for both NAKs are no longer valid (since v3).

~Vitaly

> 
> 
> [1] https://lore.kernel.org/linux-mm/CAKEwX=Ma9phmURz5nyJm0MQrWmXGFLFBPwr8-Cx=zbc473rx9A@mail.gmail.com/
> 
> -- 
> Cheers,
> 
> David / dhildenb
>