Hello Andrew, Could you please pick this V4 btrfs patch and the other five patches from V3 patch set (https://lkml.org/lkml/2020/1/3/568). Older patches can be dropped from linux-next: * ac2aeaa0f4d3 btrfs: use larger zlib buffer for s390 hardware compression * ac19f15aea33 lib/zlib: add zlib_deflate_dfltcc_enabled() function * 3447c9a51196 s390/boot: add dfltcc= kernel command line parameter * 890060df4401 lib/zlib: add s390 hardware support for kernel zlib_inflate * 148f7d060405 s390/boot: rename HEAP_SIZE due to name collision * bfbef17740fd lib/zlib: add s390 hardware support for kernel zlib_deflate Thanks, Mikhail. -------- Forwarded Message -------- Subject: Re: [PATCH v4] btrfs: Use larger zlib buffer for s390 hardware compression Date: Tue, 14 Jan 2020 17:18:57 +0100 From: David Sterba <dsterba@xxxxxxx> Reply-To: dsterba@xxxxxxx To: Mikhail Zaslonko <zaslonko@xxxxxxxxxxxxx> CC: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>, Chris Mason <clm@xxxxxx>, Josef Bacik <josef@xxxxxxxxxxxxxx>, David Sterba <dsterba@xxxxxxxx>, Richard Purdie <rpurdie@xxxxxxxxx>, Heiko Carstens <heiko.carstens@xxxxxxxxxx>, Vasily Gorbik <gor@xxxxxxxxxxxxx>, Christian Borntraeger <borntraeger@xxxxxxxxxx>, Eduard Shishkin <edward6@xxxxxxxxxxxxx>, Ilya Leoshkevich <iii@xxxxxxxxxxxxx>, linux-s390@xxxxxxxxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx On Wed, Jan 08, 2020 at 11:51:03AM +0100, Mikhail Zaslonko wrote: > In order to benefit from s390 zlib hardware compression support, > increase the btrfs zlib workspace buffer size from 1 to 4 pages (if > s390 zlib hardware support is enabled on the machine). This brings up > to 60% better performance in hardware on s390 compared to the PAGE_SIZE > buffer and much more compared to the software zlib processing in btrfs. > In case of memory pressure, fall back to a single page buffer during > workspace allocation. > The data compressed with larger input buffers will still conform to zlib > standard and thus can be decompressed also on a systems that uses only > PAGE_SIZE buffer for btrfs zlib. > > Signed-off-by: Mikhail Zaslonko <zaslonko@xxxxxxxxxxxxx> Reviewed-by: David Sterba <dsterba@xxxxxxxx>
