From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 27AFFC38150 for ; Fri, 5 Jul 2024 12:46:08 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A35226B0099; Fri, 5 Jul 2024 08:46:07 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9E40A6B009A; Fri, 5 Jul 2024 08:46:07 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 885106B009B; Fri, 5 Jul 2024 08:46:07 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 6CE826B0099 for ; Fri, 5 Jul 2024 08:46:07 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 0136D1602E7 for ; Fri, 5 Jul 2024 12:46:06 +0000 (UTC) X-FDA: 82305671574.28.5EE8BAF Received: from mout-p-103.mailbox.org (mout-p-103.mailbox.org [80.241.56.161]) by imf15.hostedemail.com (Postfix) with ESMTP id 10CF9A000B for ; Fri, 5 Jul 2024 12:46:04 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=pankajraghav.com header.s=MBO0001 header.b=HnrTJ3hX; spf=pass (imf15.hostedemail.com: domain of kernel@pankajraghav.com designates 80.241.56.161 as permitted sender) smtp.mailfrom=kernel@pankajraghav.com; dmarc=pass (policy=quarantine) header.from=pankajraghav.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1720183539; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=KiRhD8gjkNly0VzoFRI/T7DqOqqz5F9zI7sRKqsklio=; b=IwoA0X4EJw40g3N+RWgZEJYSu84ycD1Rf4scHfdy3IfJrhYf08/Npn9LZ/VEGbaacJ76nL CastxOwi25u4CQHsREwpikqGzbvgmM6SM9FzvO3bJjqEVvPjHpk7lRuDmvK0QUegO6LfsD 67gYqdQyGnSLfSRtx5bQXFV0XJWOOBI= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1720183539; a=rsa-sha256; cv=none; b=DPnst48DlATeANGvK3654Fj6hJj8ORSdQT0q+oTLGCqFi6fmlzl+eaWzRiPRQScxgBQVnR 1IpVMSTtMupAoDLolrlLvmQQPa+5fnh+1z4FPhboTCpV1nIn3lwGtIic6uxxTKKxLaLHRr 1TzmlyXAm6LT+Z0n6Yb4X/f0HZDBeZg= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=pankajraghav.com header.s=MBO0001 header.b=HnrTJ3hX; spf=pass (imf15.hostedemail.com: domain of kernel@pankajraghav.com designates 80.241.56.161 as permitted sender) smtp.mailfrom=kernel@pankajraghav.com; dmarc=pass (policy=quarantine) header.from=pankajraghav.com Received: from smtp2.mailbox.org (smtp2.mailbox.org [10.196.197.2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-103.mailbox.org (Postfix) with ESMTPS id 4WFtY35G6lz9snG; Fri, 5 Jul 2024 14:45:59 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pankajraghav.com; s=MBO0001; t=1720183559; 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=KiRhD8gjkNly0VzoFRI/T7DqOqqz5F9zI7sRKqsklio=; b=HnrTJ3hXg4TcedHC4quAPAipQIsjo92Sc1NxBYqY1oxDv/2/xTIRKMj9lN5xgioJHLBOvK L0kp+qNcxHWsthfLROMVJ1XNZ6mJIoYmiLlGV/Wz8huHAlDVytbSnMI45rxG4tnTi3NnV/ 30bBFuvbW5VdXc3jAGZ/U0e9HxpHarwN/JTL8FBAHg0hALF1EYoWhw0GfzrkpNwBoOT7iv 0cW2aGm+9D6CQVf8szISEWTgjnujRJCIITzrxPr2okAWHuL6Mk7H9wi0lS8qfKw5748cN7 jIhj5Epz1cL0V2xd0LyxZV7mP8sVPuaROr2P/HUAn+w98xwT9/a+PMbWhoM6uQ== Date: Fri, 5 Jul 2024 12:45:52 +0000 From: "Pankaj Raghav (Samsung)" To: Ryan Roberts Cc: Dave Chinner , Matthew Wilcox , chandan.babu@oracle.com, djwong@kernel.org, brauner@kernel.org, akpm@linux-foundation.org, linux-kernel@vger.kernel.org, yang@os.amperecomputing.com, linux-mm@kvack.org, john.g.garry@oracle.com, linux-fsdevel@vger.kernel.org, hare@suse.de, p.raghav@samsung.com, mcgrof@kernel.org, gost.dev@samsung.com, cl@os.amperecomputing.com, linux-xfs@vger.kernel.org, hch@lst.de, Zi Yan Subject: Re: [PATCH v8 01/10] fs: Allow fine-grained control of folio sizes Message-ID: <20240705124552.oastd7oyxs3u75yo@quentin> References: <20240625114420.719014-1-kernel@pankajraghav.com> <20240625114420.719014-2-kernel@pankajraghav.com> <03b9ea6c-a3c4-41e8-ad47-4e82344da419@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <03b9ea6c-a3c4-41e8-ad47-4e82344da419@arm.com> X-Stat-Signature: 14z5hbrfi4f9e51kkwufsya14e5p6689 X-Rspamd-Queue-Id: 10CF9A000B X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1720183564-103713 X-HE-Meta: U2FsdGVkX1+Ci8NSUYGGT+QJxe1gRuUwivWz7UuvxyCWzgy26fL9PQE9qwdoZgLSjmPbX5TWQvaQAG31w9ZKo3Lmnd8nqJe3+uBCAlkxPIct/byu2uTADdX3Gpv2DibvtY4p6DjIVI8pMBkhvDXA/M69qf6Os/n8/AytAzfHxM/D3t1yg594okwpTN5yQ0m6NPM4qNnTgvoJEb1CfQxQ27Oy6CYwQiizsL5IYgiv08w+whCm0JuPDu+6zX9KIt2nkT9OEaeq/SQ5YZetz1F3VRaCwJelww+9DWlWpPuughWHdrLamPuu6ZdZwFQt2lnU15htv5ZblYwwZx9+r81nZCg7trbO7vzlAcGqQe6fmnnM/uqSg+RSo/Z2FNPG6hDlMwgCHgmtwRHHBGTEaYOj42MqgdAGzuwsZRWFFfQXuJIL8oRbJJYAdFAKRjPDO6nBotMhZoPLkPVjtzVvwA2FMlpaPJlN6z9S3dL3iBc8aRd6J3pprSkoJ5lria8/eWiI98PdgY0vRLg2wXS0Ve2Sspc6K5Sl1VnKBXnW2XiKDxvgdw9wJpmQsm7Bc1iCyatKxfDHOkHLsBFrvJ3n5URE5dkmraoSVuifME+kk2zqZpPfAR5JSCEwrr7C9P43f7A16rqEe2TlQHlbKZYDJ7/THMAtdyZqLbBhAtAx97uNBJc46g4KVGmezW3TuyI4qUTZG2Pvo9U+ISgNRsBN5j/fjPN8cjO9fROGPPjRtUEaKhLFQeQPtHMwylLg1Jcg72phkeM7R9OmBD/GamcndlxeGJRIHh8x+vlfJFOZ3XpGHtHkxjcb1pVO+RDjtYU0+4wconCaVtn5g+SuUNGzyd+0/2SL9KxnbtgAKhWOmL2o4yAizu8hW4x7MGD1Xu4227o9ZhzNQldj9qPQ/nkD3nzLbKmhTWmb7LENpJHdJ1lZvThUCndG48OBpqZIsGX3yfiWIiYkgOQfYpcYWun5UPr Kt6V6lhm kGQo7ONR3L+D6Fn2Us9eeLbaiEOPM9MT5TgNkcvzI61qGzMdWImPaKWkOIGK1st5oYTKsko9jzCvD93trIlM2GPXEJD0po1zo/uoZV9EKoB7D2nE8+mF248bCMktDwqnyj0iDsyjPhHXMjUQLXUi5pIgcueebjYuMagHJvWkzTiOue0Rid5qvHIGDVLStiB11CiMF1HxpGKNKgD/imb0ajxBxYLsPfwE9NTuCO2NBFa0Zyss7QXliWUqohUnRXWjUzTP4+K4Duqo8F0FsY1xDTj4g1h4eO0nNTc1IQgAc+9FQeh9hKK6uC9nqswxDvCjvT1EenRm6vj8uRjvOkLcM2fIMUQ== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Fri, Jul 05, 2024 at 10:03:31AM +0100, Ryan Roberts wrote: > On 05/07/2024 05:32, Dave Chinner wrote: > > On Fri, Jul 05, 2024 at 12:56:28AM +0100, Matthew Wilcox wrote: > >> On Fri, Jul 05, 2024 at 08:06:51AM +1000, Dave Chinner wrote: > >>>>> It seems strange to silently clamp these? Presumably for the bs>ps usecase, > >>>>> whatever values are passed in are a hard requirement? So wouldn't want them to > >>>>> be silently reduced. (Especially given the recent change to reduce the size of > >>>>> MAX_PAGECACHE_ORDER to less then PMD size in some cases). > >>>> > >>>> Hm, yes. We should probably make this return an errno. Including > >>>> returning an errno for !IS_ENABLED() and min > 0. > >>> > >>> What are callers supposed to do with an error? In the case of > >>> setting up a newly allocated inode in XFS, the error would be > >>> returned in the middle of a transaction and so this failure would > >>> result in a filesystem shutdown. > >> > >> I suggest you handle it better than this. If the device is asking for a > >> blocksize > PMD_SIZE, you should fail to mount it. > > A detail, but MAX_PAGECACHE_ORDER may be smaller than PMD_SIZE even on systems > with CONFIG_TRANSPARENT_HUGEPAGE as of a fix that is currently in mm-unstable: > > #ifdef CONFIG_TRANSPARENT_HUGEPAGE > #define PREFERRED_MAX_PAGECACHE_ORDER HPAGE_PMD_ORDER > #else > #define PREFERRED_MAX_PAGECACHE_ORDER 8 > #endif > > /* > * xas_split_alloc() does not support arbitrary orders. This implies no > * 512MB THP on ARM64 with 64KB base page size. > */ > #define MAX_XAS_ORDER (XA_CHUNK_SHIFT * 2 - 1) > #define MAX_PAGECACHE_ORDER min(MAX_XAS_ORDER, > PREFERRED_MAX_PAGECACHE_ORDER) > > But that also implies that the page cache can handle up to order-8 without > CONFIG_TRANSPARENT_HUGEPAGE so sounds like there isn't a dependcy on > CONFIG_TRANSPARENT_HUGEPAGE in this respect? > I remember seeing willy's comment about dependency on CONFIG_TRANSPARENT_HUGEPAGE for large folios[0]: Some parts of the VM still depend on THP to handle large folios correctly. Until those are fixed, prevent creating large folios if THP are disabled. This was Jan of 2022. I don't know the status of it now but we enable large folios for filesystem only when THP is enabled(as you can see in the helpers mapping_set_folio_order_range()). [0] https://lore.kernel.org/lkml/20220116121822.1727633-8-willy@infradead.org/