From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 609E540855 for ; Mon, 17 Aug 2026 09:47:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786960052; cv=none; b=sJZ1tTsJnN/XCnhLPQ+8LyFNN97teYgSPe9kaPQDou0tEhxwcVp/zyR/CmzgS11Rbww+hjqJVa17Xsm5lXIyK1ur5CoZAn4qc+qg8gdiQMjyk3XXX0KwXeQQFiTaCtQ4krBov2LbK90yMih7P1lZo+8GZuOVbR/UxoQoV0CJXuc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786960052; c=relaxed/simple; bh=pYJz7MPTnyQIDo/kczwBdXcPxJG7w1X03FmH6z3Jdhg=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=KkqUzo59lm8YvoRlaiS3XkjNHWIHGJv/OFQRHwd3t1EEPXG3menCaIyeIUop0dHLDvO5rHYst9ZwMjOWqksANaoujixst+6ezFpIHWveoROdbnVcNqeXof9zQBTg9RiRrtKr4IfF2wUl6n6v5LxCKYgr3uKmHYsoJl7nzs3mbmM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=e+OojMUb; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="e+OojMUb" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 574121F000E9; Mon, 17 Aug 2026 09:47:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1786960050; bh=+laVLPUYkiKz1cDHXrawu2MRRkiFfpO6T9JCBPngSVU=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=e+OojMUbOgKiG73Kuwyd7AH19+YInJ8dKZEjpgH5JduL4lyRv3+1qUcPTNimrGVBI EhIC0XuzZFHG7R3+f9ePqqKO4b5UPfSPFROgYRQnrbmeK0GNgyCG1SC9o2y2aS3al6 C9IxKKv3TuKvB7nlaFQmptwgdadUwn7Y/Af62v2mYgN2Y0uiMuTyc7uQA9cI4cN+3q GSPAfCdfr4ZAt0t+PDFhAVeHkrovRhKVXugmw0UlZuyTqW7S7Z0My+YSTguDYVyTHW Q98+rHlnXTyciXwl7eNM5RCdFNU4J1wo1nxHt6QZWYj53kP/mkR3C0WxjRdIrqqn5W sL3dgMecVZbew== Date: Mon, 17 Aug 2026 17:47:24 +0800 From: Gao Xiang To: Geert Uytterhoeven Cc: Gao Xiang , Linus Torvalds , linux-erofs@lists.ozlabs.org, LKML , SJ Park , Guenter Roeck Subject: Re: [PATCH] erofs: fix EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS on some UP platforms Message-ID: Mail-Followup-To: Geert Uytterhoeven , Gao Xiang , Linus Torvalds , linux-erofs@lists.ozlabs.org, LKML , SJ Park , Guenter Roeck References: <20260812131144.30802-1-xiang@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: On Mon, Aug 17, 2026 at 11:21:33AM +0200, Geert Uytterhoeven wrote: > Hi Gao, > > On Mon, 17 Aug 2026 at 11:05, Gao Xiang wrote: > > On Mon, Aug 17, 2026 at 10:43:34AM +0200, Geert Uytterhoeven wrote: > > > > > > In principle, that would be better, but may I ask if there is some > > > > > > severe consequences out of one extra line of > > > > > > CONFIG_EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS=1? > > > > > > > > > > > > Since it has been fixed for many times, I hope if it could be improved > > > > > > later if no severe impacts, sigh.. > > > > > > > > > > It causes more churn (defconfig updates), and makes the defconfig > > > > > files larger than needed. > > > > > > > > Could you submit a formal patch directly (since you found it and > > > > suggested a version)? > > > > > > > > so I could submit it along with the pull request if you're fine with it. > > > > > > Will do, I want to do a bit more testing first... > > > > Ok, anyway, I will try to submit a PR hours later. > > if there is a patch, the worst case is that it's included in > > the follow-up pull request. > > > > > In addition, usability can be improved by hiding the prompt on UP > > > systems: > > > > > > - int "EROFS LZMA default maximum decompression streams" > > > + int "EROFS LZMA default maximum decompression streams" if SMP > > > > > > > I hope CONFIG_EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS is a user-visible > > configuration (and the Kconfig text helps too) no matter the platform > > is UP or not (but it can be omitted in .config) even there is the only > > one choice in menuconfig for example on UP platforms. > > Why do you prefer it to be a user-visible option on UP? > In general, we try not to bother the user with questions about > configuration options that do not matter for him, or that offer only > a single valid answer. > > IMHO even "if SMP && EXPERT" would make sense... I think users should not be bothered with !SMP in the beginning. CONFIG_EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS impacts the default LZMA maximum memory usage, I hope it shows the same for both SMP or !SMP (even it cannot be configured on !SMP, since it clearly shows to users the number and indicates how the default LZMA stream derives in general.) I think it's unlike something that is totally disabled in !SMP (or does't have such functionality in SMP), I think that is more sense to hide it in the configuration but here the DEFAULT_MAX_STREAM is still meaningful and is 1. Thanks, Gao Xiang > > Gr{oetje,eeting}s, > > Geert > > -- > Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org > > In personal conversations with technical people, I call myself a hacker. But > when I'm talking to journalists I just say "programmer" or something like that. > -- Linus Torvalds >