Re: [PATCH v4] mm: add zblock allocator

[David Hildenbrand <david@redhat.com>]

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?


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

-- 
Cheers,

David / dhildenb