Re: [PATCH v2] mm: add zblock allocator

[Igor Belousov <igor.b@beldev.am>]

Hi Johannes,

>> Sure. zstd/8 cores/make -j32:
>> 
>> zsmalloc:
>> real	7m36.413s
>> user	38m0.481s
>> sys	7m19.108s
>> Zswap:            211028 kB
>> Zswapped:         925904 kB
>> zswpin 397851
>> zswpout 1625707
>> zswpwb 5126
>> 
>> zblock:
>> real	7m55.009s
>> user	39m23.147s
>> sys	7m44.004s
>> Zswap:            253068 kB
>> Zswapped:         919956 kB
>> zswpin 456843
>> zswpout 2058963
>> zswpwb 3921
> 
> So zstd results in nearly double the compression ratio, which in turn
> cuts total execution time *almost in half*.
> 
> The numbers speak for themselves. Compression efficiency >>> allocator
> speed, because compression efficiency ultimately drives the continuous
> *rate* at which allocations need to occur. You're trying to optimize a
> constant coefficient at the expense of a higher-order one, which is a
> losing proposition.

Actually there's a slight bug in zblock code for 4K page case which 
caused storage inefficiency for small (== well compressed) memory 
blocks. With that one fixed, the results look a lot brighter for zblock:

1. zblock/zstd/8 cores/make -j32 bzImage
real	7m28.290s
user	37m27.055s
sys	7m18.629s
Zswap:            221516 kB
Zswapped:         904104 kB
zswpin 425424
zswpout 2011503
zswpwb 4111

2a. zblock/zstd/16 cores/make -j16 modules
real	15m53.119s
user	199m45.722s
sys	36m21.544s
zswpin 26600
zswpout 287021
zswpwb 0
Zswap:            205908 kB
Zswapped:         858516 kB

2b. zsmalloc/zstd/16 cores/make -j16 modules
real	16m31.052s
user	207m3.612s
sys	37m49.891s
zswpin 27044
zswpout 296763
zswpwb 61
Zswap:            198740 kB
Zswapped:         868020 kB

So what we see is:
* on 4K pages, zblock matches zsmalloc with regard to storage density on 
longer tests and gives better performance in virtually all scenarios
* on 16K pages, zblock is superior to zsmalloc in terms of both 
performance and storage density.

> This is a general NAK from me on any new allocators that cannot match
> or outdo zsmalloc storage density in common scenarios. I'm sorry, but
> I really don't see any reason to do this.

Given the above, I sincerely hope that you reconsider.

Thanks,
Igor