On Tue, Feb 23, 2021 at 03:31:19PM +0800, Huang Jianan via Linux-erofs wrote:
> lz4 uses LZ4_DISTANCE_MAX to record history preservation. When
> using rolling decompression, a block with a higher compression
> ratio will cause a larger memory allocation (up to 64k). It may
> cause a large resource burden in extreme cases on devices with
> small memory and a large number of concurrent IOs. So appropriately
> reducing this value can improve performance.
>
> Decreasing this value will reduce the compression ratio (except
> when input_size <LZ4_DISTANCE_MAX). But considering that erofs
> currently only supports 4k output, reducing this value will not
> significantly reduce the compression benefits.
>
> The maximum value of LZ4_DISTANCE_MAX defined by lz4 is 64k, and
> we can only reduce this value. For the old kernel, it just can't
> reduce the memory allocation during rolling decompression without
> affecting the decompression result.
>
> Signed-off-by: Huang Jianan <huangjia...@oppo.com>
> Signed-off-by: Guo Weichao <guoweic...@oppo.com>
> ---
>
> change since v2:
> - use z_erofs_load_lz4_config to calculate lz4_distance_pages
> - add description about the compatibility of the old kernel version
> - drop useless comment
>
> fs/erofs/decompressor.c | 22 ++++++++++++++++++----
> fs/erofs/erofs_fs.h | 3 ++-
> fs/erofs/internal.h | 7 +++++++
> fs/erofs/super.c | 2 ++
> 4 files changed, 29 insertions(+), 5 deletions(-)
>
> diff --git a/fs/erofs/decompressor.c b/fs/erofs/decompressor.c
> index 1cb1ffd10569..0bb7903e3f9b 100644
> --- a/fs/erofs/decompressor.c
> +++ b/fs/erofs/decompressor.c
> @@ -28,6 +28,18 @@ struct z_erofs_decompressor {
> char *name;
> };
>
> +int z_erofs_load_lz4_config(struct erofs_sb_info *sbi,
> + struct erofs_super_block *dsb)
> +{
> + u16 distance = le16_to_cpu(dsb->lz4_max_distance);
> +
> + sbi->lz4_max_distance_pages = distance ?
> + (DIV_ROUND_UP(distance, PAGE_SIZE) + 1)
> :
Unneeded parentheses here (I'll update it when applying).
Otherwise it looks good to me.
Reviewed-by: Gao Xiang <hsiang...@redhat.com>
Thanks,
Gao Xiang
