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 7D93BC3DA42 for ; Wed, 17 Jul 2024 15:13:06 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A4BB96B009E; Wed, 17 Jul 2024 11:13:05 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9FB976B00A0; Wed, 17 Jul 2024 11:13:05 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8C20C6B00A1; Wed, 17 Jul 2024 11:13:05 -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 6E4CD6B009E for ; Wed, 17 Jul 2024 11:13:05 -0400 (EDT) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 3010D1A0A07 for ; Wed, 17 Jul 2024 15:13:05 +0000 (UTC) X-FDA: 82349587530.27.21018CE Received: from mout-p-103.mailbox.org (mout-p-103.mailbox.org [80.241.56.161]) by imf14.hostedemail.com (Postfix) with ESMTP id 49C1810001C for ; Wed, 17 Jul 2024 15:13:02 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=pankajraghav.com header.s=MBO0001 header.b=PIbi01yD; dmarc=pass (policy=quarantine) header.from=pankajraghav.com; spf=pass (imf14.hostedemail.com: domain of kernel@pankajraghav.com designates 80.241.56.161 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=1721229138; 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=wkGlIL/8yYyHEDYOvtGp85rUzFdd0lvsLxhOub/l8Dw=; b=uvKGKvKB6ilZYoA64mP0IrYwGzJvy/KxxeSpxeR6jlLGvBu8l1tbq/Max5Mlm6FL6RQVMu Ux9A5ZxYxLIwLxaq3UC4vTwXTTqONcWksRn48RdV/P1PjNk7ppM5OOlLAH1ogT5wHWRBis knZQX5iGG9U1OqoeAG2zuGjQwRYJetA= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1721229138; a=rsa-sha256; cv=none; b=m0NQ1h2Xjql2E9RMp1VXSWowvcQ7+npCG4XyZPTmMZBJVlUorp/01g0mHOeJCeWIDLWNmX M57ugBKjHuW30xcyj50otnuTJ4byCwUKeGQVLY/b1rO//t/6dxPwkc5v2shS6WkcPGQ4Xg 6YOQNu2UT5qrAm2FKkePNrgNCOXOkVw= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=pankajraghav.com header.s=MBO0001 header.b=PIbi01yD; dmarc=pass (policy=quarantine) header.from=pankajraghav.com; spf=pass (imf14.hostedemail.com: domain of kernel@pankajraghav.com designates 80.241.56.161 as permitted sender) smtp.mailfrom=kernel@pankajraghav.com Received: from smtp2.mailbox.org (smtp2.mailbox.org [IPv6:2001:67c:2050:b231:465::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 4WPKF46PK9z9scN; Wed, 17 Jul 2024 17:12:56 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pankajraghav.com; s=MBO0001; t=1721229176; 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=wkGlIL/8yYyHEDYOvtGp85rUzFdd0lvsLxhOub/l8Dw=; b=PIbi01yDD/lqKD8I/KAF7g90eBYXWrXENMgSb3CBHFRS0GSbqzabZPo2jnKsAclomkqi/E PnViURvG9P0HFHP3M85oB3QocxVJ5j+nSgdDhBPlaVgVrqtz5uwEZnfWd2D+0WBGmsGkYF L8mOjI28meM12Hq9K06VmfgpVohIKttL5euBe7gsK3UFejQWpvrqxkfxoR62kkmHdG2v11 UBf2LXozSlh9JKw2BlwsZah7XUXWRSpZYcRMC5n7RlBiMVE0D/WmuagEK9KEjbh3BEQc9W rfveAKVXMSNn/FpxJFUc+RUw8GSfwe3ltnqLmvrbfkFegAWYeB0ps9YIPD9UPA== Date: Wed, 17 Jul 2024 15:12:51 +0000 From: "Pankaj Raghav (Samsung)" To: Ryan Roberts Cc: Matthew Wilcox , david@fromorbit.com, 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 v10 01/10] fs: Allow fine-grained control of folio sizes Message-ID: <20240717151251.x7vkwajb57pefs6m@quentin> References: <20240715094457.452836-1-kernel@pankajraghav.com> <20240715094457.452836-2-kernel@pankajraghav.com> <20240717094621.fdobfk7coyirg5e5@quentin> <61806152-3450-4a4f-b81f-acc6c6aeed29@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <61806152-3450-4a4f-b81f-acc6c6aeed29@arm.com> X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 49C1810001C X-Stat-Signature: byqo71qg3wwdr7qbp9dbw6n6tuh5emux X-Rspam-User: X-HE-Tag: 1721229182-458002 X-HE-Meta: U2FsdGVkX1/9fW5auNtLcirLh5coltnZv82w93hN2QDogx6ZAb4WmNqv+R2SR3vCS9l5IDRmyBftXmiBY2bH3+oEUhNu9alm1gr1E+xkwwCDdE6P2Dl+1DVdUWnKE3BIGwILYD2kj067YlCndwQc7DmFcwUoScz7Tpo4cTSQo/jjFu5VFl7KHKcl+cd2ZernakDi4smUAvo9vnDHEpHIY590aEd5vEmMt1+xXLCCYtyHaodPI2wWUxx5IuBphuV8AkWObD6qoztOxhFWLbILx/tFWIwubAaFGh4j0uxkXmqg6VdgKtNEBtDqR6nFD20Bn3zN/IKQLXg3POTCcYmdWGo5ftwaKx677IYWxntvssfIGj+q3CgTibMM5VkpqSF28FXZ+XXQkRYixPdJ7eT1Jz43DL8oW1WU6C7r5gHu9B6RG2ZoVHYsrGicYQlsg8pL3aX6bKAhYseQeGa7xeTpXv+xrQiURVJnsIJ/Sub2ugm7EM4ZS9yBaoBb5IN2Sq788KjKG1KBRN52Mh/ct3xbRwrNKxqcuVaoZ7V5oDUlwOef0B0hUVlBNMKUoWPZePdz0hY0kmc9req2m7KQo5avaFcuVHRC4DqViJuid17boJjDjrQXddcODu2tazBgJwyaB15F908lZzK3e1LBFN/qs30IHVSAysXp5zWK5h2DgXI5S1h9b/Eb6Tc1JVe5recdTKPIEErqM5+FjnhC7GvmjYTq9kNezrJJDgayTvLcTrp1UOQR7aVmz5GOx6hh0VH8KxELaxapFcGMVm6QoCgEMD1JhkOw3uNsyBpXqqatIdExSieXvwZpV6RMeShI/oqP81d+d/+UN+/GWNz994qpFva4XLQW2WKW5vACuk/61Bvh/8pr8e/to3A+ujK4AVtgXM3dWrkEAlB7IWvGIT6exr/Ja+lufiBQgXOgRWN/HGY0bMWO5/yea8tCNnTVklIiEsl6OfhPMObSTn2RrvY xAj5Ac19 BikRdZEF28sAdDW//yZLqndU2uO0EfgvWQSW+b0I2QUvLPiWxpZLXdPD730AUsLbv9fq9MICZoib/sEN3LJQQwj6ePS6vWfaxoDqkzGEK05a7yDhL+LOqcghim5YkO/eSRrtHAokOK/3s7/qxlZ9feRzjp3hURU8tlv0nNpKpWzThr9+jrsoh+8IcSsiKb/oVCmou6ZrNEoD+wq9X6aKDkz9g6X73JAuSfHsKaIoMq2la7+S6PNxmCcC+7u7LYs+89fwVmF4bxSUj0abm0zaqHwtfzmYpxUMs0iUGcZp1qhCkMRCPB4Cj7rDX0Evscfta6gGH5Eq0drdhH/Jtb2KDIpvBcoRwfJMo5rLjU6QrZwkELME= 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: > >> > >> This is really too much. It's something that will never happen. Just > >> delete the message. > >> > >>> + if (max > MAX_PAGECACHE_ORDER) { > >>> + VM_WARN_ONCE(1, > >>> + "max order > MAX_PAGECACHE_ORDER. Setting max_order to MAX_PAGECACHE_ORDER"); > >>> + max = MAX_PAGECACHE_ORDER; > >> > >> Absolutely not. If the filesystem declares it can support a block size > >> of 4TB, then good for it. We just silently clamp it. > > > > Hmm, but you raised the point about clamping in the previous patches[1] > > after Ryan pointed out that we should not silently clamp the order. > > > > ``` > >> 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. > > ``` > > > > It was not clear from the conversation in the previous patches that we > > decided to just clamp the order (like it was done before). > > > > So let's just stick with how it was done before where we clamp the > > values if min and max > MAX_PAGECACHE_ORDER? > > > > [1] https://lore.kernel.org/linux-fsdevel/Zoa9rQbEUam467-q@casper.infradead.org/ > > The way I see it, there are 2 approaches we could take: > > 1. Implement mapping_max_folio_size_supported(), write a headerdoc for > mapping_set_folio_order_range() that says min must be lte max, max must be lte > mapping_max_folio_size_supported(). Then emit VM_WARN() in > mapping_set_folio_order_range() if the constraints are violated, and clamp to > make it safe (from page cache's perspective). The VM_WARN()s can just be inline Inlining with the `if` is not possible since: 91241681c62a ("include/linux/mmdebug.h: make VM_WARN* non-rvals") > in the if statements to keep them clean. The FS is responsible for checking > mapping_max_folio_size_supported() and ensuring min and max meet requirements. This is sort of what is done here but IIUC willy's reply to the patch, he prefers silent clamping over having WARNINGS. I think because we check the constraints during the mount time, so it should be safe to call this I guess? > > 2. Return an error from mapping_set_folio_order_range() (and the other functions > that set min/max). No need for warning. No state changed if error is returned. > FS can emit warning on error if it wants. I think Chinner was not happy with this approach because this is done per inode and basically we would just shutdown the filesystem in the first inode allocation instead of refusing the mount as we know about the MAX_PAGECACHE_ORDER even during the mount phase anyway. -- Pankaj