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] [day] [month] [year] [list]
Message-ID: <df805c0e-bf25-4cf6-9601-aac594fa0f45@linux.ibm.com>
Date: Fri, 9 May 2025 17:18:00 +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 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




Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ