Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp2137844pxb; Mon, 22 Feb 2021 22:22:17 -0800 (PST) X-Google-Smtp-Source: ABdhPJxkAqRJ2dEJCkVHxZUd212xBhNfqo9/cOM0/Z38UQ3B63+vwYXFV8LtejG09ExkZqQ48WT1 X-Received: by 2002:a17:906:400a:: with SMTP id v10mr4581839ejj.83.1614061337382; Mon, 22 Feb 2021 22:22:17 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1614061337; cv=none; d=google.com; s=arc-20160816; b=SkuyQjS0Ela3+h+5/BhNuY8VrP5OfeOjD31UZCex5niUTstX0fun7Z9zuB7zVyGXfe DzlYMW3iB5z6NxEaYnoWyiaTJpwVAuFfnITl+dCHeVpr8kCKy1NwGVKgGHMrH87FbyMF h3Zti7fDRJm9Y2eqzxvC67AqKOlC24kkHfFIgukQUko8H7bily6FqnDDtNay/pTdm3gH QLpUId2gXj309mBCRG5BCcTynsLhQzDKxNRKMUk/c1GTqV/N/hkksSjeDeOtIgc5c9qe Ax+4fbQgSSOUx0sHt9PBDtfxKe9zisK0ap4pkngQKF1MkKHP/tTNgxG7YH/jx/ifXeRO lRzQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=nRY4EIG8QWABwtBIFNtzKLvglOXNCK9nv/ZZ50jZYQw=; b=qm2wOn+M8VdMYJeyYSGc398YjWA2tV9p7baK46SeTtrEI9dhUucAhLaN7xpr2a3ZWE h5tonRN61+qZ4FApfv5gLrxMB3j+E5Dl9F0NWkifmz/TGJHY7+eU/PpDZuoDmL5g2j/X 9T3j661XH8yr1lOSoUZsqdiBLjfAMvHGCSD5yb4Ym+YzXibjblZR1vFegJq+K8GL8PPr TeTs9nkQCBBNph0FaV+YGID5iD85+66fvrSLqb7wQ+WLh/86csBQzELR9klWChZ8foYV 3JBOz034Ltvf7Nksd79c5pUU0x8CYl8I/f1gp5ewEK9Mh8KqNx4oxADEg9EjjO0sIL8f 9pNA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=L8BO77TZ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id i20si13684973edg.156.2021.02.22.22.21.43; Mon, 22 Feb 2021 22:22:17 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=L8BO77TZ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230306AbhBWFVL (ORCPT + 99 others); Tue, 23 Feb 2021 00:21:11 -0500 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:26691 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229961AbhBWFVJ (ORCPT ); Tue, 23 Feb 2021 00:21:09 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1614057580; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=nRY4EIG8QWABwtBIFNtzKLvglOXNCK9nv/ZZ50jZYQw=; b=L8BO77TZy/i8nHJmO3Iscu2F2EgMDR68osiWYgq7MPlbENyUrxvF+U0kQNmUP6colFj6sE a7iFK0pVIvzBOiOdLB7CUQBJTp44vg/A3Quqad3SbRHusfS3T2gj+e7qhbsohTainrwKLs fjJxI7FPE33U4Xi4RV+nO+wb8/HdlaU= Received: from mail-pl1-f199.google.com (mail-pl1-f199.google.com [209.85.214.199]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-471-Dc5uS8fMO1qCHULUSgeysA-1; Tue, 23 Feb 2021 00:19:37 -0500 X-MC-Unique: Dc5uS8fMO1qCHULUSgeysA-1 Received: by mail-pl1-f199.google.com with SMTP id p15so9492289plq.8 for ; Mon, 22 Feb 2021 21:19:37 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=nRY4EIG8QWABwtBIFNtzKLvglOXNCK9nv/ZZ50jZYQw=; b=HKMVOuB5zGyKsr67cVH4w9AvHw9hLKKITjLQ737V59JQ77Dge5vgZdMiRqDGDGH9LQ 42mInShxW5DdKtzNLymbHU6XXcjrz8z95Gtx9kf0YOImP6lswOKYCEo2DGFYHhX3/th/ s+UP9uSWjAAct0xPyll/5oVDeKQgbwoHRiN/B3N8LKPx4w9yJzx1yJXCz+LvIz25/N/o PDliv7H1Y1PYe/hdyYlUb8Xh/rP0/Uc2phGJIa9dAm/uY9+Yc7fKCabwYddBSXBmZIfi wxqow/js4DY1hgWrHdpjAiqHwrMZGSSfC0k0GLvA5fQnK/SarzZR7W4e9eK4km0MM4jO AvAg== X-Gm-Message-State: AOAM5315K4er1+yl2E5sYZwzOiIymKxBjGOTlI8Se8UNU/csWILeagXC xY3ta2vbs0UuBZapJOaYB6OF63v3kKqqoNTPTTERIm86zFEqtdZsx1FzoFx3mrVooQqv8PXdGxv UAcYxMuIwspmO7dx0UQAceoLC X-Received: by 2002:a17:902:c083:b029:e3:ef59:5a15 with SMTP id j3-20020a170902c083b02900e3ef595a15mr10198803pld.83.1614057576771; Mon, 22 Feb 2021 21:19:36 -0800 (PST) X-Received: by 2002:a17:902:c083:b029:e3:ef59:5a15 with SMTP id j3-20020a170902c083b02900e3ef595a15mr10198786pld.83.1614057576508; Mon, 22 Feb 2021 21:19:36 -0800 (PST) Received: from xiangao.remote.csb ([209.132.188.80]) by smtp.gmail.com with ESMTPSA id f7sm1293346pjh.45.2021.02.22.21.19.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 22 Feb 2021 21:19:36 -0800 (PST) Date: Tue, 23 Feb 2021 13:19:26 +0800 From: Gao Xiang To: Huang Jianan Cc: linux-erofs@lists.ozlabs.org, linux-kernel@vger.kernel.org, guoweichao@oppo.com, zhangshiming@oppo.com Subject: Re: [PATCH v2] erofs: support adjust lz4 history window size Message-ID: <20210223051926.GB1225203@xiangao.remote.csb> References: <20210223043634.36807-1-huangjianan@oppo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20210223043634.36807-1-huangjianan@oppo.com> User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Feb 23, 2021 at 12:36:34PM +0800, Huang Jianan via Linux-erofs wrote: > From: huangjianan > > 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 currently only supports 4k output, reducing this value will not > significantly reduce the compression benefits. It'd be better to add some description words here to explain why old kernels could use such new adjusted images (because we only decrease the sliding window size, and LZ4_MAX_DISTANCE in principle is 64kb due to the length limitation of "offset" field for each lz4 sequence.) > > Signed-off-by: Huang Jianan > Signed-off-by: Guo Weichao > --- > > changes since previous version > - change compr_alg to lz4_max_distance > - calculate lz4_max_distance_pages when reading super_block > > fs/erofs/decompressor.c | 12 ++++++++---- > fs/erofs/erofs_fs.h | 3 ++- > fs/erofs/internal.h | 3 +++ > fs/erofs/super.c | 5 +++++ > 4 files changed, 18 insertions(+), 5 deletions(-) > > diff --git a/fs/erofs/decompressor.c b/fs/erofs/decompressor.c > index 1cb1ffd10569..fb2b4f1b8806 100644 > --- a/fs/erofs/decompressor.c > +++ b/fs/erofs/decompressor.c > @@ -36,22 +36,26 @@ static int z_erofs_lz4_prepare_destpages(struct z_erofs_decompress_req *rq, > struct page *availables[LZ4_MAX_DISTANCE_PAGES] = { NULL }; > unsigned long bounced[DIV_ROUND_UP(LZ4_MAX_DISTANCE_PAGES, > BITS_PER_LONG)] = { 0 }; > + unsigned int lz4_max_distance_pages = LZ4_MAX_DISTANCE_PAGES; How about directly unsigned int lz4_max_distance_pages = EROFS_SB(rq->sb)->lz4_max_distance_pages here... (and see below.) > void *kaddr = NULL; > unsigned int i, j, top; > > + if (EROFS_SB(rq->sb)->lz4_max_distance_pages) > + lz4_max_distance_pages = EROFS_SB(rq->sb)->lz4_max_distance_pages; > + > top = 0; > for (i = j = 0; i < nr; ++i, ++j) { > struct page *const page = rq->out[i]; > struct page *victim; > > - if (j >= LZ4_MAX_DISTANCE_PAGES) > + if (j >= lz4_max_distance_pages) > j = 0; > > /* 'valid' bounced can only be tested after a complete round */ > if (test_bit(j, bounced)) { > - DBG_BUGON(i < LZ4_MAX_DISTANCE_PAGES); > - DBG_BUGON(top >= LZ4_MAX_DISTANCE_PAGES); > - availables[top++] = rq->out[i - LZ4_MAX_DISTANCE_PAGES]; > + DBG_BUGON(i < lz4_max_distance_pages); > + DBG_BUGON(top >= lz4_max_distance_pages); > + availables[top++] = rq->out[i - lz4_max_distance_pages]; > } > > if (page) { > diff --git a/fs/erofs/erofs_fs.h b/fs/erofs/erofs_fs.h > index 9ad1615f4474..5eb37002b1a3 100644 > --- a/fs/erofs/erofs_fs.h > +++ b/fs/erofs/erofs_fs.h > @@ -39,7 +39,8 @@ struct erofs_super_block { > __u8 uuid[16]; /* 128-bit uuid for volume */ > __u8 volume_name[16]; /* volume name */ > __le32 feature_incompat; > - __u8 reserved2[44]; > + __le16 lz4_max_distance; /* lz4 max distance */ > + __u8 reserved2[42]; > }; > > /* > diff --git a/fs/erofs/internal.h b/fs/erofs/internal.h > index 67a7ec945686..7457710a763a 100644 > --- a/fs/erofs/internal.h > +++ b/fs/erofs/internal.h > @@ -70,6 +70,9 @@ struct erofs_sb_info { > > /* pseudo inode to manage cached pages */ > struct inode *managed_cache; > + > + /* lz4 max distance pages */ > + u16 lz4_max_distance_pages; > #endif /* CONFIG_EROFS_FS_ZIP */ > u32 blocks; > u32 meta_blkaddr; > diff --git a/fs/erofs/super.c b/fs/erofs/super.c > index d5a6b9b888a5..3a3d235de7cc 100644 > --- a/fs/erofs/super.c > +++ b/fs/erofs/super.c > @@ -174,6 +174,11 @@ static int erofs_read_superblock(struct super_block *sb) > sbi->islotbits = ilog2(sizeof(struct erofs_inode_compact)); > sbi->root_nid = le16_to_cpu(dsb->root_nid); > sbi->inos = le64_to_cpu(dsb->inos); > +#ifdef CONFIG_EROFS_FS_ZIP > + if (dsb->lz4_max_distance) > + sbi->lz4_max_distance_pages = > + DIV_ROUND_UP(le16_to_cpu(dsb->lz4_max_distance), PAGE_SIZE) + 1; > +#endif How about adding a new helper e.g. z_erofs_load_lz4_config(sb, dsb) in decompressor.c, and int z_erofs_load_lz4_config(sb, dsb) { if (dsb->lz4_max_distance) sbi->lz4_max_distance_pages = DIV_ROUND_UP ... else sbi->lz4_max_distance_pages = LZ4_MAX_DISTANCE_PAGES; return 0; } Also add a declaration in internal.h: #ifdef CONFIG_EROFS_FS_ZIP int z_erofs_load_lz4_config..... #else static inline int z_erofs_load_lz4_config() { return 0; } #endif Thanks, Gao Xiang > > sbi->build_time = le64_to_cpu(dsb->build_time); > sbi->build_time_nsec = le32_to_cpu(dsb->build_time_nsec); > -- > 2.25.1 >