Re: [PATCH v5.1] fs: Allow fine-grained control of folio sizes
From: Hannes Reinecke <hare@suse.de>
Date: 2024-05-28 10:20:44
Also in:
linux-fsdevel, linux-mm, linux-xfs
On 5/27/24 23:01, Matthew Wilcox (Oracle) wrote:
quoted hunk ↗ jump to hunk
We need filesystems to be able to communicate acceptable folio sizes to the pagecache for a variety of uses (e.g. large block sizes). Support a range of folio sizes between order-0 and order-31. Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org> Co-developed-by: Pankaj Raghav <redacted> Signed-off-by: Pankaj Raghav <redacted> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Reviewed-by: Hannes Reinecke <hare@suse.de> --- For this version, I fixed the TODO that the maximum folio size was not being honoured. I made some other changes too like adding const, moving the location of the constants, checking CONFIG_TRANSPARENT_HUGEPAGE, and dropping some of the functions which aren't needed until later patches. (They can be added in the commits that need them). Also rebased against current Linus tree, so MAX_PAGECACHE_ORDER no longer needs to be moved). include/linux/pagemap.h | 81 +++++++++++++++++++++++++++++++++++------ mm/filemap.c | 6 +-- mm/readahead.c | 4 +- 3 files changed, 73 insertions(+), 18 deletions(-)diff --git a/include/linux/pagemap.h b/include/linux/pagemap.h index 1ed9274a0deb..c6aaceed0de6 100644 --- a/include/linux/pagemap.h +++ b/include/linux/pagemap.h@@ -204,13 +204,18 @@ 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_STABLE_WRITES, /* must wait for writeback before modifying + AS_RELEASE_ALWAYS = 6, /* Call ->release_folio(), even if no private data */ + AS_STABLE_WRITES = 7, /* must wait for writeback before modifying folio contents */ - AS_UNMOVABLE, /* The mapping cannot be moved, ever */ + AS_UNMOVABLE = 8, /* The mapping cannot be moved, ever */ + AS_FOLIO_ORDER_MIN = 16, + AS_FOLIO_ORDER_MAX = 21, /* Bits 16-25 are used for FOLIO_ORDER */ }; +#define AS_FOLIO_ORDER_MIN_MASK 0x001f0000 +#define AS_FOLIO_ORDER_MAX_MASK 0x03e00000 +#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@@ -359,9 +364,48 @@ static inline void mapping_set_gfp_mask(struct address_space *m, gfp_t mask) #define MAX_PAGECACHE_ORDER 8 #endif +/* + * mapping_set_folio_order_range() - Set the orders supported by a file. + * @mapping: The address space of the file. + * @min: Minimum folio order (between 0-MAX_PAGECACHE_ORDER inclusive). + * @max: Maximum folio order (between @min-MAX_PAGECACHE_ORDER inclusive). + * + * The filesystem should call this function in its inode constructor to + * indicate which base size (min) and maximum size (max) 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_order_range(struct address_space *mapping, + unsigned int min, unsigned int max) +{ + if (IS_ENABLED(CONFIG_TRANSPARENT_HUGEPAGE)) + return; +
Errm. Sure? When transparent hugepages are _enabled_ we don't support this feature? Confused. Cheers, Hannes -- Dr. Hannes Reinecke Kernel Storage Architect hare@suse.de +49 911 74053 688 SUSE Software Solutions GmbH, Frankenstr. 146, 90461 Nürnberg HRB 36809 (AG Nürnberg), GF: I. Totev, A. McDonald, W. Knoblich