From patchwork Fri Sep 15 18:38:26 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Pankaj Raghav (Samsung)" X-Patchwork-Id: 13387462 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 A2C7BEED61F for ; Fri, 15 Sep 2023 18:39:01 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3CEDF6B03AF; Fri, 15 Sep 2023 14:39:01 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3814A6B03B0; Fri, 15 Sep 2023 14:39:01 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 26E7E6B03B1; Fri, 15 Sep 2023 14:39:01 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 1A3296B03AF for ; Fri, 15 Sep 2023 14:39:01 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id E684FC0776 for ; Fri, 15 Sep 2023 18:39:00 +0000 (UTC) X-FDA: 81239693640.17.EE62B30 Received: from mout-p-202.mailbox.org (mout-p-202.mailbox.org [80.241.56.172]) by imf19.hostedemail.com (Postfix) with ESMTP id 165331A0017 for ; Fri, 15 Sep 2023 18:38:58 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=pankajraghav.com header.s=MBO0001 header.b=hsUb3KY4; dmarc=none; spf=pass (imf19.hostedemail.com: domain of me@pankajraghav.com designates 80.241.56.172 as permitted sender) smtp.mailfrom=me@pankajraghav.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1694803139; 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-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=pCLutTTx1nXzynufX5Rc0GaxeJJRiIKE41sPKA97GlA=; b=lZJJtxCWoDtmbBrAtaoVlrUM+pKundQFCFbm9/N+EwAXxv7wmL20MVI9+efTzHIKv4iiH6 BOmOw5prh/VpddqOB1JrTtdXrB2ZgIS9572HYaR40xVXJXb6M0N3G6SP8gVAcQkwNlkITq +9+ke6nZkMX8TJHVc5WW+Ns30oX6HjE= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=pankajraghav.com header.s=MBO0001 header.b=hsUb3KY4; dmarc=none; spf=pass (imf19.hostedemail.com: domain of me@pankajraghav.com designates 80.241.56.172 as permitted sender) smtp.mailfrom=me@pankajraghav.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1694803139; a=rsa-sha256; cv=none; b=VPLExujOv6z10umLplTY3e965Hv6zuyVb1Gk9nLwZYsWnmshCZKIzZefsHF/++T2dkU1K1 v0XECAKlLLmbzyqbNlt9cT4fVnNIbsA2xOyPAXUH9zC2GUVbj9F/DqDed5dtM8y6w5CFe3 XcaTBteWDYthxqYB0zZfh+NH0hFx1u4= Received: from smtp2.mailbox.org (smtp2.mailbox.org [10.196.197.2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-202.mailbox.org (Postfix) with ESMTPS id 4RnNHz3428z9sSS; Fri, 15 Sep 2023 20:38:55 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pankajraghav.com; s=MBO0001; t=1694803135; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=pCLutTTx1nXzynufX5Rc0GaxeJJRiIKE41sPKA97GlA=; b=hsUb3KY4XvzrJ/umA8hy7LoJ99BD3KFTp3A7geTDr8UuQPQSYjMxDoznaGguaLUp7+zDIb SpPpJCMfaXeSHycMiA5SkGcdhUnKdR3h+9BxRRTe16EO607wdLjOeBmcoXsuLn52tuqvDv 6vmC+15VxzBBalR61EhCSDFSmIsNKNLAGWw8wrAVsAyDjZWOJY6PUd+mtQyjsROOAYhLGS NBJ3482DeuVAANzY1Xw0ipSZdmdT2UWd+jwufpsrPntaDwop5mTrOij6aXocMWbBhTaL3+ hzIlOi0fN7bzc6CO2LU+jTDYY2GYSV06QMUd7bZZKQ4eRqAmRVXDL0y/e0ivFQ== From: Pankaj Raghav To: linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org Cc: p.raghav@samsung.com, david@fromorbit.com, da.gomez@samsung.com, akpm@linux-foundation.org, linux-kernel@vger.kernel.org, willy@infradead.org, djwong@kernel.org, linux-mm@kvack.org, chandan.babu@oracle.com, mcgrof@kernel.org, gost.dev@samsung.com Subject: [RFC 01/23] fs: Allow fine-grained control of folio sizes Date: Fri, 15 Sep 2023 20:38:26 +0200 Message-Id: <20230915183848.1018717-2-kernel@pankajraghav.com> In-Reply-To: <20230915183848.1018717-1-kernel@pankajraghav.com> References: <20230915183848.1018717-1-kernel@pankajraghav.com> MIME-Version: 1.0 X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 165331A0017 X-Stat-Signature: fz1t7p7niaf8u1gs1tww8enmfrhjunrm X-Rspam-User: X-HE-Tag: 1694803138-338917 X-HE-Meta: U2FsdGVkX1+QOgtx6K2XS2IG+IYjWyk6Xj2F79B+mE+NWgjqvlv4T0dU+GcA7EATAPQbQ+WP6B7ZXIbfkXk/Zs42uBUtD3PKImLcXE8FKG9ofu1mDpcT7WplHLeaihvb9nxUyI68PsftSrZPyv21ZWxNWadzs+5Tr/qeDNRhPZBsbh95EyoyJQQzuF9G60Ydq5+tn3W/N63s8n/FSmQX1nN8TxZyrn78+iNdIfOyARm0i7z+3oG4oh1VZTDE3EXQqehJrs2ESfz8L2ETf6rLhxMdoQF8TAflmMUGDxl1KJM+yXJxD9Nh1e742HjVw4az7+QKCcAsIzXE97jrSWQdifIO+GhjcNIthYm5eZlcdmsjowZ1ZDg+tNgCez+JEjRXK6OBJ4RK+8bVhUi+18rF9zIqm9cU1cxtO4IS+a8QNZa80DDeIJDRyCn0BOjHXTSDU+ub0J8m+/Gp1ag696aI1Nctu16qCL2GtIWlaFxjNPuIBSnvYzqEkFKrQQ/M/7uIj3me4Ec5i46yooUC+/8teYBsStBBTXBz5wUDFL4z3h9RKJ3O8Die/A8ABTkZRcj8wJE3ztOpAVaEs9K0maVRlpczBZrBHzE78CesHbphvR4wrUq9M3sRzDRqfLZnlGIv1YPNsh6hExI6wpvUkDfJ0T4Y8U3zVqx9J7vaTXsv4w64FyQqer4SpJ/3V8J2ZWCybWfPrFmq3SwSRz3xF9cMPYCmKMgOwCoG9XF47jaygTQiqRk/ePeIAsDqQmUODfu2Yok1r0s8biNloIgZtR7g+3oUoXyC1xo448yFnMxgmavlODMFXKTvioFd6v2YsApmHKb0YWqn+5WihY/1UaeFE/9F76MORJAhwwvPxJwLjE0qa0U3HFRicM9lrWDDqtjVyTQ67vrw5RNbzRE/BiIem45ppZzBXQRmVsr3t0g5RLEPoe+34hob5P0+HW32F7R8elwCnf8zg/UR3RXO8hM S7acYmhH HVuEi0kJBUrg35ntwkNLctFCEby6DaV1q0KKiZmP37Ln+3fuE5iApOgt++P0Wi/V1GEYMSZCdb3aUiQbyLJgf6YCcLIA5FBUFOFi453/VV3/MYIIPBtf4/gjKLKj00CZW0b26hy+58/JfS54bnA+oki8nC1ieJKrgfLllNkrzsVyAEkGBWAzJ1+esDN6hYb6jxnJqI07aYaqF8mNIgv/XIjF8UAlkmK0Q0wrL9LfYGnUnm16OlDIVzexSgA/AIeWOMPwM8GCj1F+ftYmoiVm6L+5my2HaJH9fGdBHQuzWUaVUAyzlwLL+wevwc87X/aE8ATBqbrRANnZllpXRmSWXmtpcitk4XW+rzICm6ptcWPYbCL+nlJ92KXST+w== 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: From: "Matthew Wilcox (Oracle)" Some filesystems want to be able to limit the maximum size of folios, and some want to be able to ensure that folios are at least a certain size. Add mapping_set_folio_orders() to allow this level of control. The max folio order parameter is ignored and it is always set to MAX_PAGECACHE_ORDER. [Pankaj]: added mapping_min_folio_order(), changed MAX_MASK to 0x0003e000 Signed-off-by: Pankaj Raghav [mcgrof: rebase in light of "mm, netfs, fscache: stop read optimisation when folio removed from pagecache" which adds AS_RELEASE_ALWAYS] Signed-off-by: Matthew Wilcox (Oracle) --- include/linux/pagemap.h | 78 +++++++++++++++++++++++++++++++---------- 1 file changed, 60 insertions(+), 18 deletions(-) diff --git a/include/linux/pagemap.h b/include/linux/pagemap.h index 759b29d9a69a..d2b5308cc59e 100644 --- a/include/linux/pagemap.h +++ b/include/linux/pagemap.h @@ -202,10 +202,16 @@ enum mapping_flags { AS_EXITING = 4, /* final truncate in progress */ /* writeback related tags are not used */ AS_NO_WRITEBACK_TAGS = 5, - AS_LARGE_FOLIO_SUPPORT = 6, - AS_RELEASE_ALWAYS, /* Call ->release_folio(), even if no private data */ + AS_RELEASE_ALWAYS = 6, /* Call ->release_folio(), even if no private data */ + AS_FOLIO_ORDER_MIN = 8, + AS_FOLIO_ORDER_MAX = 13, + /* 8-17 are used for FOLIO_ORDER */ }; +#define AS_FOLIO_ORDER_MIN_MASK 0x00001f00 +#define AS_FOLIO_ORDER_MAX_MASK 0x0003e000 +#define AS_FOLIO_ORDER_MASK (AS_FOLIO_ORDER_MIN_MASK | AS_FOLIO_ORDER_MAX_MASK) + /** * mapping_set_error - record a writeback error in the address_space * @mapping: the mapping in which an error should be set @@ -310,6 +316,46 @@ static inline void mapping_set_gfp_mask(struct address_space *m, gfp_t mask) m->gfp_mask = mask; } +/* + * There are some parts of the kernel which assume that PMD entries + * are exactly HPAGE_PMD_ORDER. Those should be fixed, but until then, + * limit the maximum allocation order to PMD size. I'm not aware of any + * assumptions about maximum order if THP are disabled, but 8 seems like + * a good order (that's 1MB if you're using 4kB pages) + */ +#ifdef CONFIG_TRANSPARENT_HUGEPAGE +#define MAX_PAGECACHE_ORDER HPAGE_PMD_ORDER +#else +#define MAX_PAGECACHE_ORDER 8 +#endif + +/* + * mapping_set_folio_orders() - Set the range of folio sizes supported. + * @mapping: The file. + * @min: Minimum folio order (between 0-MAX_PAGECACHE_ORDER inclusive). + * @max: Maximum folio order (between 0-MAX_PAGECACHE_ORDER inclusive). + * + * The filesystem should call this function in its inode constructor to + * indicate which sizes 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_orders(struct address_space *mapping, + unsigned int min, unsigned int max) +{ + /* + * XXX: max is ignored as only minimum folio order is supported + * currently. + */ + mapping->flags = (mapping->flags & ~AS_FOLIO_ORDER_MASK) | + (min << AS_FOLIO_ORDER_MIN) | + (MAX_PAGECACHE_ORDER << AS_FOLIO_ORDER_MAX); +} + /** * mapping_set_large_folios() - Indicate the file supports large folios. * @mapping: The file. @@ -323,7 +369,17 @@ static inline void mapping_set_gfp_mask(struct address_space *m, gfp_t mask) */ static inline void mapping_set_large_folios(struct address_space *mapping) { - __set_bit(AS_LARGE_FOLIO_SUPPORT, &mapping->flags); + mapping_set_folio_orders(mapping, 0, MAX_PAGECACHE_ORDER); +} + +static inline unsigned int mapping_max_folio_order(struct address_space *mapping) +{ + return (mapping->flags & AS_FOLIO_ORDER_MAX_MASK) >> AS_FOLIO_ORDER_MAX; +} + +static inline unsigned int mapping_min_folio_order(struct address_space *mapping) +{ + return (mapping->flags & AS_FOLIO_ORDER_MIN_MASK) >> AS_FOLIO_ORDER_MIN; } /* @@ -332,8 +388,7 @@ static inline void mapping_set_large_folios(struct address_space *mapping) */ static inline bool mapping_large_folio_support(struct address_space *mapping) { - return IS_ENABLED(CONFIG_TRANSPARENT_HUGEPAGE) && - test_bit(AS_LARGE_FOLIO_SUPPORT, &mapping->flags); + return mapping_max_folio_order(mapping) > 0; } static inline int filemap_nr_thps(struct address_space *mapping) @@ -494,19 +549,6 @@ static inline void *detach_page_private(struct page *page) return folio_detach_private(page_folio(page)); } -/* - * There are some parts of the kernel which assume that PMD entries - * are exactly HPAGE_PMD_ORDER. Those should be fixed, but until then, - * limit the maximum allocation order to PMD size. I'm not aware of any - * assumptions about maximum order if THP are disabled, but 8 seems like - * a good order (that's 1MB if you're using 4kB pages) - */ -#ifdef CONFIG_TRANSPARENT_HUGEPAGE -#define MAX_PAGECACHE_ORDER HPAGE_PMD_ORDER -#else -#define MAX_PAGECACHE_ORDER 8 -#endif - #ifdef CONFIG_NUMA struct folio *filemap_alloc_folio(gfp_t gfp, unsigned int order); #else