From: Vitaly Wool <vitaly.wool@konsulko.se>
To: David Hildenbrand <david@redhat.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>,
linux-mm@kvack.org, akpm@linux-foundation.org,
linux-kernel@vger.kernel.org, Nhat Pham <nphamcs@gmail.com>,
Shakeel Butt <shakeel.butt@linux.dev>,
Igor Belousov <igor.b@beldev.am>
Subject: Re: [PATCH v4] mm: add zblock allocator
Date: Fri, 18 Apr 2025 12:56:02 +0200 [thread overview]
Message-ID: <4CECDD1E-5227-4719-B826-F6AFC77D4D75@konsulko.se> (raw)
In-Reply-To: <1ed925bd-897e-44b6-ad20-7d61c8c57aa8@redhat.com>
> 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).
~Vitaly
>
>
> [1] https://lore.kernel.org/linux-mm/CAKEwX=Ma9phmURz5nyJm0MQrWmXGFLFBPwr8-Cx=zbc473rx9A@mail.gmail.com/
>
> --
> Cheers,
>
> David / dhildenb
>
next prev parent reply other threads:[~2025-04-18 10:56 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-12 15:42 Vitaly Wool
2025-04-12 19:25 ` Igor Belousov
2025-04-16 12:09 ` Johannes Weiner
2025-04-16 20:10 ` Vitaly
2025-04-17 14:16 ` Johannes Weiner
2025-04-18 7:43 ` Vitaly Wool
2025-04-18 10:52 ` David Hildenbrand
2025-04-18 10:56 ` Vitaly Wool [this message]
2025-04-18 11:03 ` David Hildenbrand
2025-04-22 10:46 ` Yosry Ahmed
2025-04-23 19:53 ` Vitaly Wool
2025-04-30 12:27 ` Yosry Ahmed
2025-05-01 12:41 ` Vitaly Wool
2025-05-01 23:43 ` Sergey Senozhatsky
2025-05-06 13:04 ` Yosry Ahmed
2025-06-11 17:11 ` Vitaly Wool
2025-05-01 23:49 ` Sergey Senozhatsky
2025-05-03 8:27 ` Vitaly
2025-05-04 9:26 ` Andrew Morton
2025-07-20 2:56 ` Andrew Morton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4CECDD1E-5227-4719-B826-F6AFC77D4D75@konsulko.se \
--to=vitaly.wool@konsulko.se \
--cc=akpm@linux-foundation.org \
--cc=david@redhat.com \
--cc=hannes@cmpxchg.org \
--cc=igor.b@beldev.am \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=nphamcs@gmail.com \
--cc=shakeel.butt@linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox