Re: [PATCH RFC v3 0/4] mTHP-friendly compression in zsmalloc and zram based on multi-pages

[Sergey Senozhatsky <senozhatsky@chromium.org>]

On (24/11/22 11:25), Barry Song wrote:
> When large folios are compressed at a larger granularity, we observe
> a notable reduction in CPU usage and a significant improvement in
> compression ratios.
>
> This patchset enhances zsmalloc and zram by adding support for dividing
> large folios into multi-page blocks, typically configured with a
> 2-order granularity. Without this patchset, a large folio is always
> divided into `nr_pages` 4KiB blocks.
>
> The granularity can be set using the `ZSMALLOC_MULTI_PAGES_ORDER`
> setting, where the default of 2 allows all anonymous THP to benefit.

I can't say that I'm in love with this part.

Looking at zsmalloc stats, your new size-classes are significantly
further apart from each other than our tradition size classes.
For example, with ZSMALLOC_CHAIN_SIZE of 10, some size-classes are
more than 400 (that's almost 10% of PAGE_SIZE) bytes apart

// stripped
   344  9792
   348 10048
   351 10240
   353 10368
   355 10496
   361 10880
   368 11328
   370 11456
   373 11648
   377 11904
   383 12288
   387 12544
   390 12736
   395 13056
   400 13376
   404 13632
   410 14016
   415 14336

Which means that every objects of size, let's say, 10881 will
go into 11328 size class and have 447 bytes of padding between
each object.

And with ZSMALLOC_CHAIN_SIZE of 8, it seems, we have even larger
padding gaps:

// stripped
   348 10048
   351 10240
   353 10368
   361 10880
   370 11456
   373 11648
   377 11904
   383 12288
   390 12736
   395 13056
   404 13632
   410 14016
   415 14336
   418 14528
   447 16384

E.g. 13632 and 13056 are more than 500 bytes apart.

> swap-out time(ms)       68711              49908
> swap-in time(ms)        30687              20685
> compression ratio       20.49%             16.9%

These are not the only numbers to focus on, really important metrics
are: zsmalloc pages-used and zsmalloc max-pages-used.  Then we can
calculate the pool memory usage ratio (the size of compressed data vs
the number of pages zsmalloc pool allocated to keep them).

More importantly, dealing with internal fragmentation in a size-class,
let's say, of 14528 will be a little painful, as we'll need to move
around 14K objects.

As, for the speed part, well, it's a little unusual to see that you
are focusing on zstd.  zstd is slower than any from the lzX family,
sort of a fact, zstsd sports better compression ratio, but is slower.
Do you use zstd in your smartphones?  If speed is your main metrics,
another option might be to just use a faster algorithm and then utilize
post-processing (re-compression with zstd or writeback) for memory
savings?

Do you happen to have some data (pool memory usage ratio, etc.) for
lzo or lzo-rle, or lz4?