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 9BA05C41513 for ; Tue, 9 Jul 2024 13:08:45 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1836C6B00A1; Tue, 9 Jul 2024 09:08:45 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 10C1F6B00A2; Tue, 9 Jul 2024 09:08:45 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EC8096B00A3; Tue, 9 Jul 2024 09:08:44 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id CE6036B00A1 for ; Tue, 9 Jul 2024 09:08:44 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 81A0481909 for ; Tue, 9 Jul 2024 13:08:44 +0000 (UTC) X-FDA: 82320243768.15.91BC912 Received: from mout-p-202.mailbox.org (mout-p-202.mailbox.org [80.241.56.172]) by imf02.hostedemail.com (Postfix) with ESMTP id 201588001E for ; Tue, 9 Jul 2024 13:08:41 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=pankajraghav.com header.s=MBO0001 header.b="rnbT/omf"; spf=pass (imf02.hostedemail.com: domain of kernel@pankajraghav.com designates 80.241.56.172 as permitted sender) smtp.mailfrom=kernel@pankajraghav.com; dmarc=pass (policy=quarantine) header.from=pankajraghav.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1720530507; a=rsa-sha256; cv=none; b=UrEX7FYl0d2lH7m/LPKnQoS2/AXMHMXNaFHXaq2gEc4cmH9YBwh8/Rq6uGKF5p/I/7GcNv UrDfN96ZjOMDKtQfNXIIdbH2ZPqP1ePobJDeA8bvfB66h0G6a9xjjiweNOFHBQ1wEF1L3C 5GeVLkNkY/XrkL9MOyDsc0FmT4bcmTo= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=pankajraghav.com header.s=MBO0001 header.b="rnbT/omf"; spf=pass (imf02.hostedemail.com: domain of kernel@pankajraghav.com designates 80.241.56.172 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=1720530507; 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=67waOcRdhuokGC1VsAI1CleG4DFk7wy8/plFNIGbEQs=; b=F+WeXNP6GDQmUVShSUKWNuTx80WM0GkCc6r0CpmtuUE5szBW3rQxb1Ff309m+6HGksVmEI TlTElxro5fu4QKVhoz0vJsn+mLEPreTyW9PIGCANga8C6dYMnser1R5KrheDo4lFREBQGE KLXQwUiOi+c6pV9cbVonUDr27K8mwd4= Received: from smtp1.mailbox.org (smtp1.mailbox.org [10.196.197.1]) (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-202.mailbox.org (Postfix) with ESMTPS id 4WJLsJ3lh3z9svX; Tue, 9 Jul 2024 15:08:36 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pankajraghav.com; s=MBO0001; t=1720530516; 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=67waOcRdhuokGC1VsAI1CleG4DFk7wy8/plFNIGbEQs=; b=rnbT/omfpIWc1cek0uLglNB0CURzcvikih+bJ3m6P/4wM6UjSyplrz4+ochoizAsH5se0w wMEdrtgnPu7x3OvUpcLKPl0CY6ALJyWxR2ED/M2Md6tiZhzgBMQ3JSB16Sf1xTmr86OdLh JPVtQTjmadQc3jkabF4vTfdwjznCGQVRc+F2rrzM48h4WP29rwBVOw7+mEs0/lbnO9wa/T LDaGSNh5Y525D/WXzWpp0vkUdXjt7/4TVXuVnRvwGR2aTfuL5r4jaOAmvMBzxJTAOM5cfI cyx08zOgyd1HczCYcjOUSFxHFGMzHlIDkXrrX7kYOH0+EYNno+VgEx8mp7PYVg== Date: Tue, 9 Jul 2024 13:08:31 +0000 From: "Pankaj Raghav (Samsung)" To: Dave Chinner Cc: Ryan Roberts , 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: <20240709130831.5qdozpts44igmsn6@quentin> References: <20240625114420.719014-1-kernel@pankajraghav.com> <20240625114420.719014-2-kernel@pankajraghav.com> <20240705132418.gk7oeucdisat3sq5@quentin> <1e0e89ea-3130-42b0-810d-f52da2affe51@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Stat-Signature: jdz3s73kuu4rdpit8tk576y6r1y5obgp X-Rspamd-Queue-Id: 201588001E X-Rspam-User: X-Rspamd-Server: rspam10 X-HE-Tag: 1720530521-874427 X-HE-Meta: U2FsdGVkX189AnLwD1Lp3rQ2sBiafR+aJoFoJ8bBnvPDOdJBP8RSALHVcK473AE9H0CkVSBVqbr+vW/0MqmYIe4CeUzfxrryn8UxCgnyZv9g5/vuxNGufGj2Ao6u2Dali7jiw6+VtHfEppCHwyPd4SA8504h6ujjJ82vxnIe9ePqgpBAvH93ygXvWwVAYiDqD72ol0tdeG+bF4ygoXve7lJ2piD7r9MZjeb5eOHV4oDOgAxqm0MnVVZMaM+ZFmYswcLJikLZH0O8FejlbZfWTvgTUipgqiDwGVLx4BXVgqDs95mWOHidMZCvD4QBwq7TVOZ/lQQ3CIwBLG+vu4JJD7nWOXGjwaYoob3ZMwDghSFOJ+eGbrVc6RKphzRRGyc3xqZvWPP9dJBbGzYSUYf+B19Co9kNs8/hmxdAG8aAxLzdphUEnPZwTMYPo4KNstxwKtIVOZe3+5a9ersX6ZGQko0rnKwe5BSEYd+iGrtSn8Civ1vjAmQhmSy+IK2Psg2QmVY0cWhby8G82FkQowiUFP/3NUtGPe6LIVj8hLFzn+uohs7UJ4rzn/60IITOqqs7KwMU6BHeyfKTzgfDr1ErwzYCJD1+dpHXa0qe3qIQy9e0vgDSHJH2qS1jje3356ZKu2Z4oILBd20MH5j7nGngJ5egv/pfIG7SXJnHGEg2ID4P9DSSKizCVaaDNgITYmtZCkd7PsJ1JhJ/4y4QjpDSnC0CYayd72WrRBzbrbLpG2vYFeMT0GBmXKj2AHjUwKVQMnWx5Qdab8HhzSbDVxAKoQtkaFHpclUFBeg19eqncmpiThsTPDSfKQVuoUyN0FuraSaPHhG72n0JViB3DFq8UoQvUK5EQSGvquYBjUZ1kH1tfrcxdfb5uG+XQzhwNuVDCpdrLe5DC5tfM2Gctqbjwhxdia4EcpzbOmXQi1FYCdW1Qa32K7ho3qjUUvawNj0u5FBUF72PtKkzDC6O1mj wZ6ZkLf0 TOmnC5KoGcb0//OFTAgD9OSDv/K2Qsd0OgVPe1TCv+QM4JIdj4c8G3JVERzzcN77ZPgNBbiR1wU0tGXymkaPHatCFcbxXy0DLEYA2T8BuL/XcNVt6gSYxZa0sV0nbTj8iVLnHWTuOu/R8pnXCx/VraPWa4rYfMIShugJnAKdeu/tr9YjatudVgQjoEzfR+YTcbNbb63PWLxl5p+PkjnY4bs4OFAlTAsPDt9Ou 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: > > > > > > Why CONFIG_BLOCK? I think it is enough if it comes from the FS side > > > right? And for now, the only FS that needs that sort of bs > ps > > > guarantee is XFS with this series. Other filesystems such as bcachefs > > > that call mapping_set_large_folios() only enable it as an optimization > > > and it is not needed for the filesystem to function. > > > > > > So this is my conclusion from the conversation: > > > - Add a dependency in Kconfig on THP for XFS until we fix the dependency > > > of large folios on THP > > > > THP isn't supported on some arches, so isn't this effectively saying XFS can no > > longer be used with those arches, even if the bs <= ps? > > I'm good with that - we're already long past the point where we try >From my cursory review, I can see that the following arch supports THP (* indicates it has some dependency on other Kconfig parameter): arc*, arm*, arm64, loongarch, mips*, powerpc*, riscv*, s390, sparc, x86. and the following do not have THP support: alpha, csky, hexagon, m68k, microblaze, nios2, openrisc, parisc, sh, um, xtensa. Looks like the arch that do not THP support are either old or embedded processor that target mainly 32-bit architecture. So are we OK with? 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 > to support XFS on every linux platform. Indeed, we've recent been > musing about making XFS depend on 64 bit only - 32 bit systems don't > have the memory capacity to run the full xfs tool chain (e.g. > xfs_repair) on filesystems over about a TB in size, and they are > greatly limited in kernel memory and vmap areas, both of which XFS > makes heavy use of. Basically, friends don't let friends use XFS on > 32 bit systems, and that's been true for about 20 years now. > > Our problem is the test matrix - if we now have to explicitly test > XFS both with and without large folios enabled to support these > platforms, we've just doubled our test matrix. The test matrix is > already far too large to robustly cover, so anything that requires > doubling the number of kernel configs we have to test is, IMO, a > non-starter. > > That's why we really don't support XFS on 32 bit systems anymore and > why we're talking about making that official with a config option. > If we're at the point where XFS will now depend on large folios (i.e > THP), then we need to seriously consider reducing the supported > arches to just those that support both 64 bit and THP. If niche > arches want to support THP, or enable large folios without the need > for THP, then they can do that work and then they get XFS for > free. > > Just because an arch might run a Linux kernel, it doesn't mean we > have to support XFS on it.... The other option is we can expose a simple helper from page cache as follows: static inline unsigned int mapping_max_folio_order_supported() { if (!IS_ENABLED(CONFIG_TRANSPARENT_HUGEPAGE)) return 0; return MAX_PAGECACHE_ORDER; } This could be used to know the maximum order supported at mount time and deny mounting for LBS configs if max folio supported is less than the block size being requested.