Re: [PATCH v4] mm: add zblock allocator

[David Hildenbrand <david@redhat.com>]

On 18.04.25 12:56, Vitaly Wool wrote:
> 
> 
>> On Apr 18, 2025, at 12:52 PM, David Hildenbrand <david@redhat.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).

Well, there I read [2]

"This is a general NAK from me on any new allocators"

So now I am confused. But maybe that's a different NAK :)

Anyhow, I was just stumbling over this after skimming v2 when it was 
under review, and I did not find a clue about that in the version change 
info under --- (e.g., NAK addressed because of Y).

Have to leave now for the long weekend, Happy Easter / Happy Holidays!

[2] https://lore.kernel.org/linux-mm/20250408195533.GA99052@cmpxchg.org/

-- 
Cheers,

David / dhildenb