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 E7355C3DA42 for ; Tue, 9 Jul 2024 21:59:22 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7A6346B0095; Tue, 9 Jul 2024 17:59:22 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 756636B0096; Tue, 9 Jul 2024 17:59:22 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 61DFD6B0098; Tue, 9 Jul 2024 17:59:22 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 440196B0095 for ; Tue, 9 Jul 2024 17:59:22 -0400 (EDT) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id E1A4B1A1AA3 for ; Tue, 9 Jul 2024 21:59:21 +0000 (UTC) X-FDA: 82321580922.14.BB1A64F Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf11.hostedemail.com (Postfix) with ESMTP id 3BA0340028 for ; Tue, 9 Jul 2024 21:59:20 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=qrFdG7XC; spf=pass (imf11.hostedemail.com: domain of djwong@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=djwong@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1720562344; 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=T1ZJaDdGRcON2PbKxhtt6fJP974v448p53V/BHFeyE8=; b=iV0qncZLFhti36pSE4Q6uCyka+LhLSUcSwayB6annCDSiv41BafKYBQ+qmaudhesCkIm+q j6X4ZzHtsyDs2fdWm7VGGwfW7fjlxacijchOZDgBfcQTc8RBLI5I35SGOVnI3dZOmxjUwT ACSC4ambQbmihveJguj2xZOVnSS2bPQ= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=qrFdG7XC; spf=pass (imf11.hostedemail.com: domain of djwong@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=djwong@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1720562344; a=rsa-sha256; cv=none; b=ViehuzrGyRdD4mpN8cqoyVmERW7cnpXYx5EsIMNztTILlH+gngJ1Lur+lt83GmnCCiTW44 Fvn6HbI2m/G9jAOYhg3JBxGnhD/ilYmhSRL8VaaK13shFVTSU9c1CMiMoeKThm1N/bA1wj HOetaTqBwHdVfF8slBR/9eGCEA4p9tk= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 5D5E161475; Tue, 9 Jul 2024 21:59:19 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 020D9C3277B; Tue, 9 Jul 2024 21:59:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1720562359; bh=gJR9+R3Sp+X9MDHtGXK+187J/tLYoRv4pK+2NdBCMnw=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=qrFdG7XCGLOOpEaTEEkx5EgR5W6BwnZ8GIaRyOty4hmQqtqicvqzY1kwqdLslE02s i22EOi3o5yGSTgnk6uawtJt4T+ZOnafHgmEvL42BvBb9vZEJn5n2LKOZuhP6kkpAzJ Z9r0t9LGKtG+ywgdW41+VNfHrS+IUsaNbVX0enlYVQY8iu0PRrvqLACUecEx1di9GP R0wX5t5kLiBU5eTS7PDmWusszfqt0PQgnktJ41ka/Kel6cdMHYGwbFEiGUplvAuYLR ttQHNcUnRbBlXGdHjgjyXDP5xBakY3Dg2usV3i2YXcMPMcCU4Xpy4l1Ujs255Ft5BT UgmI0KHTxvhVA== Date: Tue, 9 Jul 2024 14:59:18 -0700 From: "Darrick J. Wong" To: "Pankaj Raghav (Samsung)" Cc: david@fromorbit.com, willy@infradead.org, ryan.roberts@arm.com, 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 , akpm@linux-foundation.org, chandan.babu@oracle.com Subject: Re: [PATCH v8 01/10] fs: Allow fine-grained control of folio sizes Message-ID: <20240709215918.GD612460@frogsfrogsfrogs> References: <20240625114420.719014-1-kernel@pankajraghav.com> <20240625114420.719014-2-kernel@pankajraghav.com> <20240709162907.gsd5nf33teoss5ir@quentin> <20240709165047.GS1998502@frogsfrogsfrogs> <20240709210829.dgm6dsirkry3fgu6@quentin> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240709210829.dgm6dsirkry3fgu6@quentin> X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: 3BA0340028 X-Stat-Signature: 9e5tkzimgagqibaqos3o4i56sqoiinbf X-Rspam-User: X-HE-Tag: 1720562360-958031 X-HE-Meta: U2FsdGVkX1/Pd/z3xFD/oE01T1Yc8Qb2f5ST4vPhWSzyhGU+0hz94rErEcjeqnOgRADOvY32A+DHrAusnB1wxwKxAmnJJxQ8yxSPA+wrj8kehw0MSJ1zivvjsb2zCHTq/gQ3bjpcsdpVpgtj4/K2LfFuKYon4HdOWRjYI24WBTy+amzzfbb3nzTWWqqCczfc5O/g3rmvozFTS77SYrJ8w5fWjyi7F/saVeNtCOCcpoAMCOF0ptYFLG4d0xbwKSvXUMpeb4y5150e58wc8c4aO/PXF08vUWt6zNwptG3eeYFMQ7mH/XVFidyKuJWO+fHme/w4AbU0ZIRQ+QJeG9quSUp/1sGj0ntW2YEwZOzFGFYqDRJziUrJVDfQ6MtYUOBfAsdhpERZFs5FY58ll24dM53ZKyKFLR+/ELbY++i+DDHYJJBbmT2QMb+U+Yw5cTck92S7dpA6N4pef0zZQzKO7IFQL7/HGyE6taGqKs80E01KgKwCp1HpKa/FvnWzYJbAidbigNrAxLqbILhQvUyQumxvxa5o28Vb/IAcl4Va360imougGFLEMy9T9xU4GS+T6Hbw0wj4u7uOj/XUgX8FrLQKmhTDbrTzjG9y4vPdrPDFy1U1YDoR1gJNfot906bZz23/A/4TwmnE9ErzGnwqPgkyssTwc4QfIkbjDmVMM5+cj6LypkW3xaN8U8Z02NFseTnttjDD1SVSQZGc/4h5r2OcoD9PdEzJxiVAekRX6s2Tt8Rfdlmgg7JkDjiReSUEelEfT1oYm69H9Jj/VybsKwv2W/bDJNinV9Pnf4ZGIzkxkPBGZbYffTryrfEoG702pzBWwIA7mXuzxy3KhzuEdxUWPOu6V+45kjpX8wcvVmGKqDV/F/rRQsZO44h4aIUo1h2ud8i9SR9VNxquHIcjfvAiIhSdFFTOSDvOsrw6NiIdeiEHV4+mt/JdLx7D1KM3+e+I2sbDRjbd8a6S/M8 o0fpPpcn v3rMi6O4ia5PDoK/dmlV2GSxOihSgE5zdIxFRH6r1FqyB3ek0k/jJjcL/QZz+wV42Nm/aAGsDL56zSfOZckor7wxNXliPJa/5tTOoUaEnbC5WKZwodr6wmnRV99guHn8FbY6wzAdAWE7AigqLPyEojsOb8jmc3B8/R/rm/ztBPaeQnBSkoh6YKBuxJWoZKKpJHwzzTeLmwP25wL4KLVsZt3E+WLzI1KhRt+01 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 Tue, Jul 09, 2024 at 09:08:29PM +0000, Pankaj Raghav (Samsung) wrote: > > > > > > - We make THP an explicit dependency for XFS: > > > > > > diff --git a/fs/xfs/Kconfig b/fs/xfs/Kconfig > > > index d41edd30388b7..be2c1c0e9fe8b 100644 > > > --- a/fs/xfs/Kconfig > > > +++ b/fs/xfs/Kconfig > > > @@ -5,6 +5,7 @@ config XFS_FS > > > select EXPORTFS > > > select LIBCRC32C > > > select FS_IOMAP > > > + select TRANSPARENT_HUGEPAGE > > > help > > > XFS is a high performance journaling filesystem which originated > > > on the SGI IRIX platform. It is completely multi-threaded, can > > > > > > OR > > > > > > We create a helper in page cache that FSs can use to check if a specific > > > order can be supported at mount time: > > > > I like this solution better; if XFS is going to drop support for o[ld]d > > architectures I think we need /some/ sort of notice period. Or at least > > a better story than "we want to support 64k fsblocks on x64 so we're > > withdrawing support even for 4k fsblocks and smallish filesystems on > > m68k". > > > > You probably don't want bs>ps support to block on some arcane discussion > > about 32-bit, right? ;) > > > > :) > > > > diff --git a/include/linux/pagemap.h b/include/linux/pagemap.h > > > index 14e1415f7dcf..9be775ef11a5 100644 > > > --- a/include/linux/pagemap.h > > > +++ b/include/linux/pagemap.h > > > @@ -374,6 +374,14 @@ static inline void mapping_set_gfp_mask(struct address_space *m, gfp_t mask) > > > #define MAX_XAS_ORDER (XA_CHUNK_SHIFT * 2 - 1) > > > #define MAX_PAGECACHE_ORDER min(MAX_XAS_ORDER, PREFERRED_MAX_PAGECACHE_ORDER) > > > > > > + > > > +static inline unsigned int mapping_max_folio_order_supported() > > > +{ > > > + if (!IS_ENABLED(CONFIG_TRANSPARENT_HUGEPAGE)) > > > + return 0; > > > > Shouldn't this line be indented by two tabs, not six spaces? > > > > > + return MAX_PAGECACHE_ORDER; > > > +} > > > > Alternately, should this return the max folio size in bytes? > > > > static inline size_t mapping_max_folio_size(void) > > { > > if (IS_ENABLED(CONFIG_TRANSPARENT_HUGEPAGE)) > > return 1U << (PAGE_SHIFT + MAX_PAGECACHE_ORDER); > > return PAGE_SIZE; > > } > > We already have mapping_max_folio_size(mapping) which returns the > maximum folio order set for that mapping. So this could be called as > mapping_max_folio_size_supported(). > > So we could just have mapping_max_folio_size_supported() instead of > having mapping_max_folio_order_supported as you suggest. > > > > Then the validation looks like: > > > > const size_t max_folio_size = mapping_max_folio_size(); > > > > if (mp->m_sb.sb_blocksize > max_folio_size) { > > xfs_warn(mp, > > "block size (%u bytes) not supported; maximum folio size is %u.", > > mp->m_sb.sb_blocksize, max_folio_size); > > error = -ENOSYS; > > goto out_free_sb; > > } > > > > (Don't mind me bikeshedding here.) > > > > > + > > > > > > > > > diff --git a/fs/xfs/xfs_super.c b/fs/xfs/xfs_super.c > > > index b8a93a8f35cac..e2be8743c2c20 100644 > > > --- a/fs/xfs/xfs_super.c > > > +++ b/fs/xfs/xfs_super.c > > > @@ -1647,6 +1647,15 @@ xfs_fs_fill_super( > > > goto out_free_sb; > > > } > > > > > > + if (mp->m_sb.sb_blocklog - PAGE_SHIFT > > > > + mapping_max_folio_order_supported()) { > > > + xfs_warn(mp, > > > +"Block Size (%d bytes) is not supported. Check MAX_PAGECACHE_ORDER", > > > + mp->m_sb.sb_blocksize); > > > > You might as well print MAX_PAGECACHE_ORDER here to make analysis > > easier on less-familiar architectures: > > Yes! Thanks. --D > > > > xfs_warn(mp, > > "block size (%d bytes) is not supported; max folio size is %u.", > > mp->m_sb.sb_blocksize, > > 1U << mapping_max_folio_order_supported()); > > > > (I wrote this comment first.) > > > > > --D > > > > > + error = -ENOSYS; > > > + goto out_free_sb; > > > + } > > > + > > > xfs_warn(mp, > > > "EXPERIMENTAL: V5 Filesystem with Large Block Size (%d bytes) enabled.", > > > mp->m_sb.sb_blocksize); > > > > > > > > > -- > > > Pankaj >