Received: by 2002:a05:7412:31a9:b0:e2:908c:2ebd with SMTP id et41csp4968459rdb; Fri, 15 Sep 2023 19:45:43 -0700 (PDT) X-Google-Smtp-Source: AGHT+IHGoGtn30VENRke15VA6Jxr1JRiK6I5tRUXoRUlbI2wq7JdkfF5i9SspU/+s3+1KLq7nuAa X-Received: by 2002:a05:6a00:b91:b0:68c:d6f:212b with SMTP id g17-20020a056a000b9100b0068c0d6f212bmr3799285pfj.19.1694832343241; Fri, 15 Sep 2023 19:45:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1694832343; cv=none; d=google.com; s=arc-20160816; b=YXsbokhLOJWQe5OHUuf4tc89AfuuVuzT/ulTu/2XvrINKxi+9U4BkrmEAQP5iRr3yz vsg5PcSYVfCM13hXfvY2pjySDzv8LXYX71k2jBtj+X7G4vYd2C8ki/UPWN4Bggvm12HM gybPzYkk7KurLsLsVzMLfAeXeWf8aKMuCHRLlT8++Cl2aT1vzpyVzifjXUhHYulAdZft OVRDC+LJV5TPX+Fb0ts+XRC9HqDBB/u4khmjCk/hnXw+HYHFRZIJCP8Iw+XNAMMIV+Au GwGpTKYyhFTrQZnNY59bx43KK1AGhiBcYISRzYSAxA8+68lBE/WHm9M131owT47SpIf3 kzXg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=pCLutTTx1nXzynufX5Rc0GaxeJJRiIKE41sPKA97GlA=; fh=kl+S4GAUWD1kOeoqBopscteh2mu3DZslcHc01dOJ6TI=; b=xAKK9QbsmoX754SGeWPJP6Fja4lBNwAmw3cj1qd1KD/1CGnr3dpWAUUXLcXsaABsJl Fv4cUfa3kkv4/eMENC/kV8vTh2ElpHvJan6uXKHM2oWXNM7SnF4r2OecMspTdyjW0Wzp B8BI8yLlTZzcpBBOfgHGLygx8HUNVIYsJjkvv4+tfbosslqgomq5pyckrex6pphbRxqR ulLdKSZHF6qezt15Yn6gVZERAnuYu7YTc4HC2qaRti5uhbfEjf/jx4j9llXcZItHAth9 jKgqFUqEuFmXRluCyUQeA7sx5RosE0hPD0EM8xAIqJszUw1k0WWiuzU/8+VBETnL1XnB xV1A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@pankajraghav.com header.s=MBO0001 header.b=hsUb3KY4; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.33 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from lipwig.vger.email (lipwig.vger.email. [23.128.96.33]) by mx.google.com with ESMTPS id m5-20020a056a00080500b0068a3a2984ccsi4250846pfk.236.2023.09.15.19.45.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 15 Sep 2023 19:45:43 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.33 as permitted sender) client-ip=23.128.96.33; Authentication-Results: mx.google.com; dkim=pass header.i=@pankajraghav.com header.s=MBO0001 header.b=hsUb3KY4; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.33 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by lipwig.vger.email (Postfix) with ESMTP id 01FE3807C6FA; Fri, 15 Sep 2023 11:41:30 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at lipwig.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236787AbjIOSlB (ORCPT + 99 others); Fri, 15 Sep 2023 14:41:01 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38346 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236882AbjIOSkz (ORCPT ); Fri, 15 Sep 2023 14:40:55 -0400 Received: from mout-p-202.mailbox.org (mout-p-202.mailbox.org [80.241.56.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8B906422A; Fri, 15 Sep 2023 11:39:00 -0700 (PDT) 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 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lipwig.vger.email Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (lipwig.vger.email [0.0.0.0]); Fri, 15 Sep 2023 11:41:30 -0700 (PDT) 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 -- 2.40.1