Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp1033787pxb; Tue, 9 Nov 2021 04:09:38 -0800 (PST) X-Google-Smtp-Source: ABdhPJyGN6+10LrizVAZVe4Rf0zzi3p7Dq1qCvbt4Jz0gABfkngu9e83kbgi6wAKvJ1TJgG14aNK X-Received: by 2002:a05:6e02:12ec:: with SMTP id l12mr4703977iln.16.1636459778558; Tue, 09 Nov 2021 04:09:38 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1636459778; cv=none; d=google.com; s=arc-20160816; b=fdfUsh3JBCPCuLT2USXrUjxuPKcUKIHxEpon6Mb5JDp8oXtOus8GpT49AxujS8YuIw lPXwnFwnQsTV8Qw2xkg2JQF20Ia80IpV/l10kbVI3mXN6a3O1DTcKEwG414DaJm9eTyl 1UKs7CNgEnXoFFxXUnubIwdq7KfvDumdffDOLkhhqmGozUKLmO4OPPEBRNylGibUUPi0 BuP0ci9mDQhgdCXMhDwBGd5GjPxn9aIkeRWetZ3g1eDSsORlZ93+fZT86bqm2Mh4jQS4 KQIcbFkSCln/g9PrRt0zhGkyGxcRiXPOMCwRrvT1mBpo+tUoqJpmt+ovuM+MpAqqE0rH Titg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=7lDfejxLILrfUX8f3XwBVRc+dDbtUdbj0bed847Rin4=; b=vGS1FKxGk2/+IV7MG2VeCkf9A8Ce9ciJ9QXatq1BeJ0diYOtjDP6Q1nLU7iaytu7Az qYxxNY46v7SJkW20iC+RBIKXxsrLqjnmjirDPYfaYLjn7lMu1gYjy3/bk2um6xuN6WB4 CXdshjFgUkKhOUcfVZTKNyiJwgI5gPIcLED5TEifLVUEyu7mU30T1BiTmgxkG5FpTZJD Mr+VjZsUJ9WkmT8HSIyNRVmcFiYs0FbmChnUMma0ejkq48yv6B3klixXepN7//bL4LYz kz9+hi0eg+UqGUgvMR6n2y5wFbEcm1/h/bG9P8aE7H/Eg3bNirC/pVXKKqJFROPFSuOM p2Pg== ARC-Authentication-Results: i=1; mx.google.com; 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=fail (p=NONE sp=NONE dis=NONE) header.from=alibaba.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id x14si42322536iov.30.2021.11.09.04.09.24; Tue, 09 Nov 2021 04:09:38 -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; 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=fail (p=NONE sp=NONE dis=NONE) header.from=alibaba.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236589AbhKIDTi (ORCPT + 99 others); Mon, 8 Nov 2021 22:19:38 -0500 Received: from out30-56.freemail.mail.aliyun.com ([115.124.30.56]:57300 "EHLO out30-56.freemail.mail.aliyun.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231910AbhKIDTg (ORCPT ); Mon, 8 Nov 2021 22:19:36 -0500 X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R171e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=e01e04423;MF=hsiangkao@linux.alibaba.com;NM=1;PH=DS;RN=7;SR=0;TI=SMTPD_---0Uvj108s_1636427808; Received: from B-P7TQMD6M-0146.local(mailfrom:hsiangkao@linux.alibaba.com fp:SMTPD_---0Uvj108s_1636427808) by smtp.aliyun-inc.com(127.0.0.1); Tue, 09 Nov 2021 11:16:49 +0800 Date: Tue, 9 Nov 2021 11:16:47 +0800 From: Gao Xiang To: Huang Jianan Cc: linux-erofs@lists.ozlabs.org, zhangshiming@oppo.com, linux-kernel@vger.kernel.org, yh@oppo.com, guanyuwei@oppo.com, guoweichao@oppo.com Subject: Re: [PATCH 2/2] erofs: add sysfs node to control sync decompression strategy Message-ID: References: <20211109025445.12427-1-huangjianan@oppo.com> <20211109025445.12427-2-huangjianan@oppo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20211109025445.12427-2-huangjianan@oppo.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Nov 09, 2021 at 10:54:45AM +0800, Huang Jianan via Linux-erofs wrote: > Although readpage is a synchronous path, there will be no additional > kworker scheduling overhead in non-atomic contexts. So we can add a > sysfs node to allow disable sync decompression. > > Signed-off-by: Huang Jianan > --- > fs/erofs/internal.h | 2 +- > fs/erofs/super.c | 2 +- > fs/erofs/sysfs.c | 6 ++++++ > fs/erofs/zdata.c | 9 ++++----- > 4 files changed, 12 insertions(+), 7 deletions(-) > > diff --git a/fs/erofs/internal.h b/fs/erofs/internal.h > index d0cd712dc222..1ab96878009d 100644 > --- a/fs/erofs/internal.h > +++ b/fs/erofs/internal.h > @@ -60,7 +60,7 @@ struct erofs_mount_opts { > #ifdef CONFIG_EROFS_FS_ZIP > /* current strategy of how to use managed cache */ > unsigned char cache_strategy; > - /* strategy of sync decompression (false - auto, true - force on) */ > + /* strategy of sync decompression (false - disable, true - force on) */ Please leave false - auto. > bool readahead_sync_decompress; > > /* threshold for decompression synchronously */ > diff --git a/fs/erofs/super.c b/fs/erofs/super.c > index abc1da5d1719..26585d865503 100644 > --- a/fs/erofs/super.c > +++ b/fs/erofs/super.c > @@ -423,7 +423,7 @@ static void erofs_default_options(struct erofs_fs_context *ctx) > #ifdef CONFIG_EROFS_FS_ZIP > ctx->opt.cache_strategy = EROFS_ZIP_CACHE_READAROUND; > ctx->opt.max_sync_decompress_pages = 3; > - ctx->opt.readahead_sync_decompress = false; > + ctx->opt.readahead_sync_decompress = true; Please leave readahead_sync_decompress = false 'auto' by default. I don't like .readpage() applies async decompression since it's actually a sync way, otherwise, it will cause more scheduling overhead, see: https://lore.kernel.org/r/20201016160443.18685-1-willy@infradead.org https://lore.kernel.org/r/20201102184312.25926-16-willy@infradead.org Thanks, Gao Xiang