Re: [PATCH v4] mm: add zblock allocator

["Vitaly" <vitaly.wool@konsulko.se>]

[-- Attachment #1: Type: text/plain, Size: 2805 bytes --]


On Wednesday, April 16, 2025 at 2:09:12 pm +02:00, Johannes Weiner <hannes@cmpxchg.org> wrote:

>> 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?

Introducing such a scheme in zsmalloc is theoretically possible but it appears to be more complicated than implementing it from scratch, which is exactly what was done.

> 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.

I'm not sure what pain you are talking about. There were reasons why z3fold and zbud existed. z3fold and zbud were the ones that supported page reclaim, zsmalloc wasn't quite usable with zswap until recently. When we did z3fold it was outperforming zsmalloc.

With that said, I didn't object to removing z3fold because I did understand that it made no sense to keep it at that point.

> I also don't buy the fragmentation argument. Even if you are better at
> packing during allocation time (although, citation needed), the
> workload can unmap swap pages such that they leave partial blocks
> behind indefinitely if you don't have block compaction.

We published Zswap/Zswapped values for zblock/zsmalloc after stress loads and those were on par, basically.

> Then there is the migration support, which you said is planned, but
> which would presumably require the same indirection between handle and
> the backing pages that zsmalloc has. How much will this eat into the
> performance advantage?


I don't think that will be necessary. We're working on supporting GFP_MOVABLE and minimising high order allocations
> I'd much rather you'd focus on making zsmalloc better. Improve the
> packing scheme, make expensive features optional/configurable etc.
> That would be easier on developers and users alike.

zblock's source code is almost 5x smaller in size than zsmalloc's and yet zblock works better in many cases with just a few bottlenecks. Why would you mind that we'd focus on making zblock better instead and possibly retire zsmalloc when that mission is accomplished, just like we retired z3fold a while ago?

Best regards,

Vitaly

[-- Attachment #2.1: Type: text/html, Size: 3520 bytes --]