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 A6A0EC54E64 for ; Mon, 25 Mar 2024 18:29:43 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2F0EB6B0089; Mon, 25 Mar 2024 14:29:43 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2A1A86B008A; Mon, 25 Mar 2024 14:29:43 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 190B06B0092; Mon, 25 Mar 2024 14:29:43 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 078A76B0089 for ; Mon, 25 Mar 2024 14:29:43 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id AAE10120813 for ; Mon, 25 Mar 2024 18:29:42 +0000 (UTC) X-FDA: 81936399804.24.40493E0 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf22.hostedemail.com (Postfix) with ESMTP id 98E3AC001C for ; Mon, 25 Mar 2024 18:29:39 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=L+oSZr1p; dmarc=none; spf=none (imf22.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1711391380; a=rsa-sha256; cv=none; b=t70GIEo6u0FIVonNOBS9V0RG6NLeOK7/HHoTaSXM05hjuKhyWGC12FZLNc4Xu3Y4pP/Aqx RxLpNJM9CA989SK1aZgCALow714L74o9y7dukr4Gq7tnafvE0c60aVV6WNGu8SstU4QYlE JMT1wp9+atp9E2rk2gGRmTd1tht0Uso= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=L+oSZr1p; dmarc=none; spf=none (imf22.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1711391380; 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=l7E+1tHSH1IK7nuvUWxZFmjLoD4xOjRNO5sUR9Pf950=; b=rxYtbkUAB3CjSEFaUA/oXsDgIyjT2Osb8C0vxn0wPoE1sxfYUTVqE7pW0hGPw638IbCpAJ 3TwQkq+bdM+ajD2pqbxgeuby9wf3egtvW7Cpi1FvTuvL2u7h2UlfVwfBJIPqDYaEiNC18v ApN5clTxzG0zflwO42qLgJ4AldRiPeU= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=l7E+1tHSH1IK7nuvUWxZFmjLoD4xOjRNO5sUR9Pf950=; b=L+oSZr1p6P6iD4v9M1lW/38dNk Ft19z4dLHo93OI83W6Hgo3RAW15U3QhbxG3VyadGiznwBIGAY4TjdOwq+aPoX+3Fecco2txGtp1Su qgnJh3kKWPEhtdPJh4//lCAMCjkyUSld5107p+z5YtIr2IKtoqFtuyvaZ5HD6rEX7DEVZLFRA9O6s Smu8CzAiKWQSPkPaTKPaqb91AYA//j7a0spNwTYaPbDmbjS+Af/Qmh6bWprRjTwyCm2IJrd58XZvD pkwXKpdDrrI32fsQT82yh9nrnkCtWeUtF8PVmvznqQsw4f7q5kezGw9rAkJcxyTcjLcuxbpOA9aoJ 4lrqKMSg==; Received: from willy by casper.infradead.org with local (Exim 4.97.1 #2 (Red Hat Linux)) id 1rop4c-0000000H3yU-33W8; Mon, 25 Mar 2024 18:29:30 +0000 Date: Mon, 25 Mar 2024 18:29:30 +0000 From: Matthew Wilcox To: "Pankaj Raghav (Samsung)" Cc: linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org, gost.dev@samsung.com, chandan.babu@oracle.com, hare@suse.de, mcgrof@kernel.org, djwong@kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, david@fromorbit.com, akpm@linux-foundation.org, Pankaj Raghav Subject: Re: [PATCH v3 02/11] fs: Allow fine-grained control of folio sizes Message-ID: References: <20240313170253.2324812-1-kernel@pankajraghav.com> <20240313170253.2324812-3-kernel@pankajraghav.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240313170253.2324812-3-kernel@pankajraghav.com> X-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 98E3AC001C X-Stat-Signature: jz8m1fthrgforsna96s78keoj98ajkfq X-HE-Tag: 1711391379-933751 X-HE-Meta: U2FsdGVkX19XKZnS5RiOSlUXM0VXbSHvNfytB48sZPZu5e7uZC4hPmnrMTFXq0eZlAiAB/Dcs22vEAriH0Uya21WJWHyMlJxbVApGgfHg1Bp8P1dseWi3sX4fdVBrXDv0pUO2G0El4Xt0uufwd2c7KtqTQbNhEQAtsVUhndV4a0gJNoquiM/dNHsLeBUcTQg9Vjq+KZNUU2mGfNLTMLpTGWBRonlVjyCqrghjuQUgnLOExD9uwkZEhNgT7DpkQw8wkItf1Jcyubt0xVPEo04UiKN+bwGixnJ+EUmcltGDkBmW3uvZX6Q8EJHyu8vGwgtsqMQL7g/8FAZWmZ9qPH0MQSPtugUsgJ+9lvIigFS8YWceRWpaNctVG/HTtNUSST/N4uyWe23besjj76cl8Stc6iXzdQE5jEnAk4Eb5zhiGkgtlSIFbDHwybr329h+Z8yLwyeH1Q38+ch6aVRo9j+Jp/3GAPtJKxubfTroN46/w41Dokp/xz/vcEGFigxn8I/XERYWeUMGup0M8t36N1/znvBfeoJ7SMD1+qTgjSh+Jcubo2048XlEWw/w9RrtXj9TH5afrNXgAy0RzmnbwVYCYgga88ZjjnxO0YKL2tDa8HGU4bh3qbFCdUvYnU9ZSQAHtAvGIiTziWriRSUEUEfI2rFLnL+BYDsV8QmUhSz+UCOO/nvxru/CpU26X36/QGlxy5P69484p1AfEnh1z/wM7JaNw0mMI/woCvGDucPdMwIFkneXPRAmW3Fvu0aZ2LhT+jIWIvOLRcwqK0vaR8HX7KzcThp8e/CTOZaPn6FinvbAfJriF+NE26WWBi5bXqD+zdkQNtGoFpjO/AE6W6VCg== 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, Mar 13, 2024 at 06:02:44PM +0100, Pankaj Raghav (Samsung) wrote: > +/* > + * mapping_set_folio_min_order() - Set the minimum folio order > + * @mapping: The address_space. > + * @min: Minimum folio order (between 0-MAX_PAGECACHE_ORDER inclusive). > + * > + * The filesystem should call this function in its inode constructor to > + * indicate which base size of folio the VFS can use to cache the contents > + * of the file. This should only be used if the filesystem needs special > + * handling of folio sizes (ie there is something the core cannot know). > + * Do not tune it based on, eg, i_size. > + * > + * Context: This should not be called while the inode is active as it > + * is non-atomic. > + */ > +static inline void mapping_set_folio_min_order(struct address_space *mapping, > + unsigned int min) > +{ > + if (min > MAX_PAGECACHE_ORDER) > + min = MAX_PAGECACHE_ORDER; > + > + mapping->flags = (mapping->flags & ~AS_FOLIO_ORDER_MASK) | > + (min << AS_FOLIO_ORDER_MIN) | > + (MAX_PAGECACHE_ORDER << AS_FOLIO_ORDER_MAX); > +} I was surprised when I read this, which indicates it might be surprising for others too. I think it at least needs a comment to say that the maximum will be set to the MAX_PAGECACHE_ORDER, because I was expecting it to set max == min. I guess that isn't what XFS wants, but someone doing this to, eg, ext4 is going to have an unpleasant surprise when they call into block_read_full_folio() and overrun 'arr'. I'm still not entirely convinced this wouldn't be better to do as mapping_set_folio_order_range() and have static inline void mapping_set_folio_min_order(struct address_space *mapping, unsigned int min) { mapping_set_folio_range(mapping, min, MAX_PAGECACHE_ORDER); }