Re: [PATCHv7 10/24] zram: add zlib compression backend support

[Zaslonko Mikhail <zaslonko@linux.ibm.com>]

Hello,

On 09.05.2025 03:38, Sergey Senozhatsky wrote:
> Hello,
> 
> On (25/05/08 16:19), Zaslonko Mikhail wrote:
> [..]
>>> +#include "backend_deflate.h"
>>> +
>>> +/* Use the same value as crypto API */
>>> +#define DEFLATE_DEF_WINBITS		11
>>> +#define DEFLATE_DEF_MEMLEVEL		MAX_MEM_LEVEL
>>> +
> [..]
>> The comment line says 'Use the same value as crypto API'...
>> could you please clarify here? Are there some memory constraints?
> 
> When zram transitioned from Crypto API (scomp) to custom compression
> API I picked the CryptoAPI deflate DEFLATE_DEF_WINBITS value:
> 
> crypto/deflate.c: DEFLATE_DEF_WINBITS	11
> 
> which is then passed to zlib_deflateInit2() and zlib_inflateInit2().
> 
>> I tried to build the kernel with DEFLATE_DEF_WINBITS set to 15 and
>> verified that s390 hardware deflate acceleration works for zram devices
>> with a deflate compression.
> 
> If we define it as 15 on non-s390 machines, will there be any
> consequences?  Increased memory usage?  By how much?

On s390, setting windowBits to 15 would lead to zlib workarea size
increased by 120K (0x24dc8 -> 0x42dc8) per compression stream,
i.e. per online CPU. 
On non-s390 machine, that impact will be about 115K per stream. 
Increasing window size should improve deflate compression,
although the compression speed might be affected. Couldn't find any
relevant zlib benchmarks though.

Not sure what other consequences might there be for zram. Do you see any?

> 
Thanks,
Mikhail