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 0C623C3DA42 for ; Wed, 17 Jul 2024 15:25:29 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7E4926B0096; Wed, 17 Jul 2024 11:25:29 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 794026B0098; Wed, 17 Jul 2024 11:25:29 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 65C036B009A; Wed, 17 Jul 2024 11:25:29 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 42D976B0096 for ; Wed, 17 Jul 2024 11:25:29 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id E5E9E1A0B55 for ; Wed, 17 Jul 2024 15:25:28 +0000 (UTC) X-FDA: 82349618736.30.EB9F602 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf15.hostedemail.com (Postfix) with ESMTP id ACF42A0019 for ; Wed, 17 Jul 2024 15:25:25 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=CqePwazl; spf=pass (imf15.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=1721229906; 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=lC6K4u3jFgh5pRSKr+P2JHQxnMQHjSqoTPPKF+sfr5I=; b=Z+CASsNeBttPqMSkKkC7JVKcNraG6SFPwCqty2eiKmns6IFPo26+kS5nhrr0gbJOJEHFEL DCWwgY5MDPrRY85wBw6akPKGk47d0AzRRk2brzBbBGjj14xpZ9XCVegXS9/pA3dmwOF5TK lFgh1TPmlJxktJ1Ge8rjECs3nSi5T7I= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=CqePwazl; spf=pass (imf15.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=1721229906; a=rsa-sha256; cv=none; b=WljGoyHzKQVnB4e+2GgwDq4FDMS7d23uDfZevPqp0PfFzLWE5gM0EwppHZ75AOpTKzutCz m/WIgIt/ruqG+Dye3/PJ7nDA8XXuarxL6XwaSMfL4TJHrITCNzS7qAkCmpCVzg1dc794H8 iknycArIGMUtvKENu6zcMs3vfUM2HxA= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 94ECE6173D; Wed, 17 Jul 2024 15:25:24 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E7245C4AF50; Wed, 17 Jul 2024 15:25:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1721229923; bh=DaTpRgJzWuI3JbYf7wsfuKAVwq9nrnAcFhQzfaoZpbw=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=CqePwazlBQsMh8JyH+2onHzIgig7EbJ2ZLDuHB5MXQshcYWBmsWwwIU8mRyH8C/wM q5k4fAC7avhpe0bJM7syVZwT4UWy/YNOlI8tN4GB2nBA4xdrh5xfPipJktNz7ROVJx 1HlKpSIVCL3uJKqvworU//xiTjWGvRFPrNUoh8dKpmUz7M5GTFokT5bNqWF8wzuhO3 sV2RuUFy5sRxh7Ejq2rKnTYnNY+KwN2o9spTIHGyMvGJE/QIhaWHJ3trUlO6hbUgvS SbtlLcaU/32O5vXmHVTlj0WdzErE7Ojsp6zPZytOQDtTruHE16/TSQnk1mp6vI4SuL 0bOJP+t8GlG3g== Date: Wed, 17 Jul 2024 08:25:22 -0700 From: "Darrick J. Wong" To: "Pankaj Raghav (Samsung)" Cc: Ryan Roberts , Matthew Wilcox , david@fromorbit.com, chandan.babu@oracle.com, 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: <20240717152522.GF612460@frogsfrogsfrogs> References: <20240715094457.452836-1-kernel@pankajraghav.com> <20240715094457.452836-2-kernel@pankajraghav.com> <20240717094621.fdobfk7coyirg5e5@quentin> <61806152-3450-4a4f-b81f-acc6c6aeed29@arm.com> <20240717151251.x7vkwajb57pefs6m@quentin> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240717151251.x7vkwajb57pefs6m@quentin> X-Rspamd-Server: rspam03 X-Rspam-User: X-Rspamd-Queue-Id: ACF42A0019 X-Stat-Signature: bzbyupgaiyozg8ktncabiteq8fcbgkip X-HE-Tag: 1721229925-720182 X-HE-Meta: U2FsdGVkX18s7dRpIofPk2hD9gEJNw7yVmnbcCHOANY8DIp/uZmlnPnnXb02wCQKpyOYxz4dLIpA1rsb1u83Ma8CbeZ9ly14q+9PMR5ofks7RNGA2KKQXrysmFGWmxftfnns1B64NpXYWg/s302kQoyz5Rz/PjKIrno+g/0VW5zGIIceCME9hB6sMlyzFblN75CRLuSUZh5bSbP32iA44PwmG+gSjUnUenUB4mbgdBbKJgykhabOVTdE9KYQ1QT2JoWg3/eDIUFPomPRjuFCwGn1OqU/hzFj+AvA/jqR8LB9Wz/uJmQXrHhqpo1F0kCKgVSmkiZv/Ap34PkAlSjwP78nH9GtdPXKMvbKrEl8Doo+4UeZptzpz8CTWTHKoLWbkgVfSZ5yodUaw+wkHsPI4+yP2ftFjk46dsZ8sPjZKgBCTbWzoCyb/t/20P3uZhHS/JlqJICMtk9AJWWLqUBTkM/bMVDaB2rgZEeoJI9gkNcJpzOAHoqELjKGijmKDWhtVMVvIE5nAcKplCgNsmkM5Sj6Byqc7lrrRIiLRWwo9N4Waeg4thDwkxB3Aeyki64KqIRzE6VdGZP2dCZz7fDh9putzwqCF5h/kSPYNgBN42qE14D/0gE5zbsCgtfYQjo9XmJVCv5oCeOLHlEURFmzx5rsyge7Y/wIpkNoE6tX695gHhTmc1lg4LLz5P9iXBZ4nwaERSHxDqgUQyZBG8EHBEugS62YRr8O/JZWNrsU7o/DoGBX6mvOg08ZHpeV+H23a9oukZDMqeAvOR/7szkwfLpu9xYcLUtbukUX1iyr5Y06BelsqRkRXcp9sNdBYUTbZjnI1tArU+KJU5Nona/p7CRksJ5rhrojBAmDIUgIy367YbdX293VPVTM+wvImzccH/LC8Wsw+Fci5rNhmeQ5BtJnRmVXUgd97W+ZOGTmV8QKZghw3uhaC23YM9bR+g6pQ2cJWq751X1i1Me0XTn ZUC5iKnD /AuWW9a7cWcPfDpSMfMKN7jql7K8pycOMG0tcjASMW1sairv7VwHiLit0nMa+/Y3dXsjbOgEzjnxnSydiRL5e8Cw31l+IFH1w7OHYatx/k76v7GhiQ2Z9gyTXWZHauamxct6FKMCodv8qTuMnjYUsXkZ+/RuuQ0KHOezzcWSKnbpfUrseuFsNz1V7L/sEHqTPvLIdwGHtqQt5cOqRhKi1eS3SUqPzh9eN2uyI/IYRN+hTTw4UcCVlS2pupi9x/hVluHSdsxPOplxiO6llMjSg9JfGdl2K75Xk0MJcYH7ST40dKUN4AvdJZ0PD0DJ+uQibtNVYh6vNR6YLM7zx53NyUPtrdg== 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 Wed, Jul 17, 2024 at 03:12:51PM +0000, Pankaj Raghav (Samsung) wrote: > > >> > > >> 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? That's my read of the situation, but I'll ask about it at the next thp meeting if that helps. > > > > 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. I agree. Filesystem-wide properties (e.g. fs blocksize) should cause the mount to fail if the pagecache cannot possibly handle any file blocks. Inode-specific properties (e.g. the forcealign+notears write work John Garry is working on) could error out of open() with -EIO, but that's a specialty file property. --D > -- > Pankaj >