lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <3bd33a06-f8e2-4901-ada1-e970d18afcd4@linux.ibm.com>
Date: Tue, 13 May 2025 14:58:35 +0200
From: Zaslonko Mikhail <zaslonko@...ux.ibm.com>
To: Sergey Senozhatsky <senozhatsky@...omium.org>
Cc: Minchan Kim <minchan@...nel.org>, linux-kernel@...r.kernel.org,
        Andrew Morton <akpm@...ux-foundation.org>,
        Ilya Leoshkevich <iii@...ux.ibm.com>,
        Heiko Carstens <hca@...ux.ibm.com>, linux-s390@...r.kernel.org
Subject: Re: [PATCHv7 10/24] zram: add zlib compression backend support

Hello,

On 13.05.2025 07:41, Sergey Senozhatsky wrote:
> Sorry for the delay,
> 
> On (25/05/09 17:18), Zaslonko Mikhail wrote:
>>> 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?
> 
> The increased per-CPU memory usage is the only thing I can think of.
> I guess for zram we could turn this into a run-time parameter, but for
> Crypto API compile-time is the only option, I guess.

With 'run-time parameter' you mean adding 'windowBits' as another deflate compression
algorithm parameter for zram? Guess we could do this, using default value of 15 then.

> 
> Can you send a patch series (for zram and Crypto API) that sets
> windowBits to 15?

I can do it for zram. Not sure if Crypto should be changed as well. Or is it
supposed to have the same compression defaults as zram?

Thanks,
Mikhail

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ