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 827F5C2BD09 for ; Tue, 9 Jul 2024 21:08:43 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E83F86B00A3; Tue, 9 Jul 2024 17:08:42 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E344D6B00A6; Tue, 9 Jul 2024 17:08:42 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CFBD06B00A8; Tue, 9 Jul 2024 17:08:42 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id B37306B00A3 for ; Tue, 9 Jul 2024 17:08:42 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 608271C399D for ; Tue, 9 Jul 2024 21:08:42 +0000 (UTC) X-FDA: 82321453284.01.3E851AE Received: from mout-p-102.mailbox.org (mout-p-102.mailbox.org [80.241.56.152]) by imf07.hostedemail.com (Postfix) with ESMTP id 6924B40022 for ; Tue, 9 Jul 2024 21:08:39 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=pankajraghav.com header.s=MBO0001 header.b=fU0YrPQt; dmarc=pass (policy=quarantine) header.from=pankajraghav.com; spf=pass (imf07.hostedemail.com: domain of kernel@pankajraghav.com designates 80.241.56.152 as permitted sender) smtp.mailfrom=kernel@pankajraghav.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1720559294; a=rsa-sha256; cv=none; b=utBSceMVAOxOf2fIj2K2uuv3hPnRY+BtThSTyV5RqV4LwBmXxAkO9nQC3tjatRMC4dOuVZ HnoHDif5pLmJD4+C3ZOK1jReeXqrbUUI2YnmfylfmO+Y0FMk+uh2R77onYDt37K+Jka7lZ q/xVoY8IJOSdFejO3F9D5M6+5/uGSKE= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=pankajraghav.com header.s=MBO0001 header.b=fU0YrPQt; dmarc=pass (policy=quarantine) header.from=pankajraghav.com; spf=pass (imf07.hostedemail.com: domain of kernel@pankajraghav.com designates 80.241.56.152 as permitted sender) smtp.mailfrom=kernel@pankajraghav.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1720559294; 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=iVjuijbIr/b7fVxDSSOmDOpSaFlx4V8o7i65KF3sL+E=; b=hObbcm049c71cQpxLRwiHBnIzdYfe79r/89WFC3zAFF0HYZHKYFGzgWtKOQ00vtSF8D6Ez 1QZgUKLgWsjF5IxRh9fZ6A+Qpmg9KpTITImiGr/RA25ODK9U/vyQMm522d78Shy1JU7yyQ +VVjjw54QAvlr4r5PU3E8Jw4VMAEdgQ= Received: from smtp102.mailbox.org (smtp102.mailbox.org [IPv6:2001:67c:2050:b231:465::102]) (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-102.mailbox.org (Postfix) with ESMTPS id 4WJYW61S9Cz9scJ; Tue, 9 Jul 2024 23:08:34 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pankajraghav.com; s=MBO0001; t=1720559314; 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=iVjuijbIr/b7fVxDSSOmDOpSaFlx4V8o7i65KF3sL+E=; b=fU0YrPQtSaMiHdH59A/z/WbCWtgL0Gd/ubUJnDLi2lbwjYRFYc8YzmqEiJz27+ZLPOU0FF LqJodweJikQZgbdVSSdCBNMnMQTeP/nUQku5UEuzhJ+zVSnSmWUNA18D4O5VQdi9+EbJV4 /v5sGpyGDyS0JgB7wWmM7s3xx3CyuzS/7VyTsWQE3iX3GyMKduF8PLWILwyaWoiqmrM+NF uCm2KCrNmitAmVV6ZOPKNmlN8t50hMo+jsE0M05OrbaEgvjfc+OPqvPcVkkSSHaUG/BpVl f/VEqIz9YlUiOLjkxZ0J0OxqxVugHxAjssgPPP2ITzAVVnUO9QYLCjVv+vA6hQ== Date: Tue, 9 Jul 2024 21:08:29 +0000 From: "Pankaj Raghav (Samsung)" To: "Darrick J. Wong" 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: <20240709210829.dgm6dsirkry3fgu6@quentin> References: <20240625114420.719014-1-kernel@pankajraghav.com> <20240625114420.719014-2-kernel@pankajraghav.com> <20240709162907.gsd5nf33teoss5ir@quentin> <20240709165047.GS1998502@frogsfrogsfrogs> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240709165047.GS1998502@frogsfrogsfrogs> X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 6924B40022 X-Stat-Signature: hxmcd9cqjo831gzjp7xnm41jfjexcqp9 X-Rspam-User: X-HE-Tag: 1720559319-896097 X-HE-Meta: U2FsdGVkX18tN2fSav8VnGt+czOx7UxEPpo+fz8yOCV0M4BLJZwG7cGqTPspLjNsGPTpuUpOL791VHyhazTzqGlTYH51dSu1ibcKgdWRoC/VU3WzQzD/w3GwVhDdIh1xBf/DJYcKDH78VsTW2GzvqTclrrPdNUIg8uOPIWnVdZSVZJj1ZR90V70kd5LaN+PYUHqxclhhYGLsPJBrVEKnM+7mVvkIhINt82QLLaNQc4pInWJtkf0sc/sxDooCcbXJOqqlzN+4pQ1ZRYtZHkazyKCKW6DOR6cFVE76IWzvpBW3klVoUPagZAZ+mcyj17VVfSFisCvBRsyXflqL6rjhSnG3jKIfnKzalTzmTBS9dzbCketmQph5ibra0MbDqrZVaTFls9Qwx0fHOIqdQu+10sxXBi37qRexgu4aCbfdiA761dG9mrsHcpoUuEhqUcZCjMSV01gcErO/GPKtc0Oq0qoMltBWI8NrW8zFcI1U0sY2fFqknRu2tL6WEL0Hq7c/5iKogatGTZMq7SG6/LD+dWdSNzA7OdCIhoV+YewmbDY4yS1pLsZbTTSS3HHmljkt7sSZMHWp78hSzGuO9e431QBEGycQyAClVCLnppVpAr6LeQp/3RIYROz3vzb6oXOwCylubTp58+AlMFGtd6wIU0lE8/W/rhBlyrJIAst+iPKz+On+8bD8Z5tCCxTtduN4nOBSkGjjcOG6Hw0QEyzOxxUtY02HvUglcb1VeC7E6f7heeM9JDzldT7IOIbNljvgEVoif8TAPxz/kxPP8lYpAPTsJxNw40QOTYGB5/c/JLugNDY+TXoWn04MWx+vkaBOppT2u8nNckkrRz+ij/edaIrbnxMvqNhmlQBIZHTSk4JKPgEWnh0qVITs8yp3JRpveDE2q92/+oN7Y+QZDm0xnswwj4HRzqVkLwyB3AAibXqwHVWsy5hlCMZMeLzjIH+Tk3m4mZaYPW6ZHyInopY 5nAhvLoe 3HXO7NfQPFk56kgHgEw5iUATaCRX/McUAKNF52mXJaUtYtCcOrn9A0K9mKhNZMaTwexDd1MUPh++GnlhSZ0IETd1ZzkcnD9xQLM8JGD5GMSfuO74oSLTC3MFZv2949TTuiuJRGJaMw6P08E391iG8WxSIWW2m59RSSyDeqwwpjYxUEueR9U31BH7dZBcuYYQ/ijhLnS2Hyx/7j/IMoshfngmiRo+rYKexmVzhdaOzfB6KvZQzik4TuARFwg== 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: > > > > - 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! > > 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