Re: [PATCH] mm: add zblock allocator

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

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

Hi Nhat,

On Tuesday, April 1, 2025 at 8:24:15 pm +02:00, Nhat Pham <nphamcs@gmail.com> wrote:
>> 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 substantially higher than z3fold and zbud
>> (though lower than zmalloc's).

>> Do we have data for comparison here?

Yeah, for instance we normally run *stress-ng --vm 4 --vm-bytes 4G --vm-keep --timeout 10m --metrics-brief*

zblock:
stress-ng: metrc: [499] stressor bogo ops real time usr time sys time bogo ops/s bogo ops/s
stress-ng: metrc: [499] (secs) (secs) (secs) (real time) (usr+sys time)
stress-ng: metrc: [499] vm 43755994 600.53 2382.34 15.19 72861.92 18250.50

zsmalloc:
stress-ng: metrc: [491] stressor bogo ops real time usr time sys time bogo ops/s bogo ops/s
stress-ng: metrc: [491] (secs) (secs) (secs) (real time) (usr+sys time)
stress-ng: metrc: [491] vm 41769859 601.37 2381.85 16.56 69457.56 17415.62

which gives just a little short of 5% of advantage for zblock.

>> with regard to average performance and worst execution times, thus
>> allowing for better response time and real-time characteristics of the
>> whole system.

>> By performance, do you mean latency or throughput or storage density?

Latency and throughput. It's hard to compete with zsmalloc in storage density indeed.

~Vitaly




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