Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp6882998ybi; Mon, 22 Jul 2019 03:20:13 -0700 (PDT) X-Google-Smtp-Source: APXvYqzNbUrm/Wz9zWJT5CDq7Lw8SnFjI4+XdXuPYwYK4pdd3+wVGyl/PbZL9rzOXw7eeFi6S86m X-Received: by 2002:a17:90a:bb01:: with SMTP id u1mr75062895pjr.92.1563790813033; Mon, 22 Jul 2019 03:20:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1563790813; cv=none; d=google.com; s=arc-20160816; b=wJWVG2KG/Vw5g7shVvggrM6ircsZ7EQY1WLMi4LpxTPPXsdi/PQaIBH6F7mecjg6aW X5N2nX3b3Izl/WuQxrm3gsN/97awWQ1Ej0KZKjYraJOuGPMVtujEwohAf6j0G32FPaxX P2wlcTlFBy/Crk2h9vi0qbvWaHBixU9oXrbfxF8opm1oqclD8DZ50NXJEWSVxJMEE4BM 1DMolhpCli84XyfsavsRoUQXHAzOOWL+VudFfotflWj5MJ/sINbOA1Zn14WngUhHwbTO 1deUHY9ujvzcvw+KmZpE9e5bZ/op3mJNsBmS8ySLU4CFQB6oVcVExoCrvJJj429H14lZ WQfw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:mail-followup-to :reply-to:message-id:subject:cc:to:from:date; bh=6k3JBVpcv5TmIQCXOe41jhBYgK8Vyhqax0YlSd7SwFI=; b=yDCojnFci0Y02kZT+HF0yLrDeMunkCP4NNkjLDiaDcmy9Mi2FdZcmDY4YzMklm4bo6 dlnJLQ/U02wYmx7NC39K1lN9OC/EPlvxxOwLcV/llEm4OjiOg5EXNZ30jjuOrfCixzjb 90vR8hfz9PKC7kLypsPh2r6vIWvKpE/vjuuqt0vuOAn86dKym4UpzkRyWWqBxFyy8GUa qKAT/kS+H+jb1tKumdnP/5Zs7fxJO7CC86YLIUreEhPSURhNF2BqXhsf8ppwIq8yvaWY p/rxe3QnTkR1/OoHu1o2DlNRUNYbhC0DtCrJrHENMuCuq79GVKWZH8tpqLEMpj0GdxO8 BWFw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g17si7920876plo.406.2019.07.22.03.19.56; Mon, 22 Jul 2019 03:20:13 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729541AbfGVKRs (ORCPT + 99 others); Mon, 22 Jul 2019 06:17:48 -0400 Received: from mx2.suse.de ([195.135.220.15]:46608 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1728569AbfGVKRr (ORCPT ); Mon, 22 Jul 2019 06:17:47 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 4BEDBB062; Mon, 22 Jul 2019 10:17:45 +0000 (UTC) Received: by ds.suse.cz (Postfix, from userid 10065) id 3FF33DA882; Mon, 22 Jul 2019 12:18:18 +0200 (CEST) Date: Mon, 22 Jul 2019 12:18:18 +0200 From: David Sterba To: Gao Xiang Cc: Alexander Viro , Greg Kroah-Hartman , Andrew Morton , Stephen Rothwell , Theodore Ts'o , Linus Torvalds , linux-fsdevel@vger.kernel.org, devel@driverdev.osuosl.org, LKML , linux-erofs@lists.ozlabs.org, Chao Yu , Miao Xie , Li Guifu , Fang Wei Subject: Re: [PATCH v3 23/24] erofs: introduce cached decompression Message-ID: <20190722101818.GN20977@twin.jikos.cz> Reply-To: dsterba@suse.cz Mail-Followup-To: dsterba@suse.cz, Gao Xiang , Alexander Viro , Greg Kroah-Hartman , Andrew Morton , Stephen Rothwell , Theodore Ts'o , Linus Torvalds , linux-fsdevel@vger.kernel.org, devel@driverdev.osuosl.org, LKML , linux-erofs@lists.ozlabs.org, Chao Yu , Miao Xie , Li Guifu , Fang Wei References: <20190722025043.166344-1-gaoxiang25@huawei.com> <20190722025043.166344-24-gaoxiang25@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190722025043.166344-24-gaoxiang25@huawei.com> User-Agent: Mutt/1.5.23.1 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jul 22, 2019 at 10:50:42AM +0800, Gao Xiang wrote: > +choice > + prompt "EROFS Data Decompression mode" > + depends on EROFS_FS_ZIP > + default EROFS_FS_ZIP_CACHE_READAROUND > + help > + EROFS supports three options for decompression. > + "In-place I/O Only" consumes the minimum memory > + with lowest random read. > + > + "Cached Decompression for readaround" consumes > + the maximum memory with highest random read. > + > + If unsure, select "Cached Decompression for readaround" > + > +config EROFS_FS_ZIP_CACHE_DISABLED > + bool "In-place I/O Only" > + help > + Read compressed data into page cache and do in-place > + I/O decompression directly. > + > +config EROFS_FS_ZIP_CACHE_READAHEAD > + bool "Cached Decompression for readahead" > + help > + For each request, it caches the last compressed page > + for further reading. > + It still does in-place I/O for the rest compressed pages. > + > +config EROFS_FS_ZIP_CACHE_READAROUND > + bool "Cached Decompression for readaround" > + help > + For each request, it caches the both end compressed pages > + for further reading. > + It still does in-place I/O for the rest compressed pages. > + > + Recommended for performance priority. The number of individual Kconfig options is quite high, are you sure you need them to be split like that? Eg. the xattrs, acls and security labels seem to be part of the basic set of features so I wonder who does not want to enable them by default. I think you copied ext4 as a skeleton for the options, but for a new filesystem it's not necessary copy the history where I think features were added over time. Then eg. the option EROFS_FS_IO_MAX_RETRIES looks like a runtime setting, the config help text does not explain anything about the change in behaviour leaving the user with 'if not sure take the defaut'. EROFS_FS_USE_VM_MAP_RAM is IMO a very low implementation detail, why does it need to be config option at all? And so on. I'd suggest to go through all the options and reconsider them to be built-in, or runtime settings. Debugging features like the fault injections could be useful on non-debugging builds too, so a separate option is fine, otherwise grouping other debugging options under the main EROFS_FS_DEBUG would look more logical.