From nobody Tue Jul 14 13:54:41 2026 Received: from mout-p-202.mailbox.org (mout-p-202.mailbox.org [80.241.56.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8E2211948E8; Wed, 13 Mar 2024 17:03:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=80.241.56.172 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1710349394; cv=none; b=JhWsHHMYAexyubg7GxEVOHzufseHo5fxlllAWta3VgFUOfCO35J8f43dHHemXWV49NsSlrV6lSxR7wXsaJrnBcPBhvdgl7GRKrRF+rLZozZ0rJRfYm8zTivZK+fdqlI23HlyKRsjKSWkvE1oQlqQzZrcOS5EXV2y73/x0QtT3qA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1710349394; c=relaxed/simple; bh=ZMppSe3CLJUbYtty6hKMUnmRewuVLsS/1omALJEd3z8=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Q48zLmQOqJniXjAIMsuUzgeNdqnRVB7TBFbZr4b8EK42Pnhe9iu4i4jAcln32IwMo1+L65TFpseHFYj90wCcWCpUlb7mli0A4p6Y45SJdye0+h8RLIUDl9oZIlpJhbxKhY+D4EKfumHIqhIquXeMVUasgq33n8trrsg2TVEtcUM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=pankajraghav.com; spf=pass smtp.mailfrom=pankajraghav.com; dkim=pass (2048-bit key) header.d=pankajraghav.com header.i=@pankajraghav.com header.b=ePofVGEs; arc=none smtp.client-ip=80.241.56.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=pankajraghav.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=pankajraghav.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=pankajraghav.com header.i=@pankajraghav.com header.b="ePofVGEs" Received: from smtp102.mailbox.org (smtp102.mailbox.org [10.196.197.102]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-202.mailbox.org (Postfix) with ESMTPS id 4TvxfF6kKKz9scJ; Wed, 13 Mar 2024 18:03:01 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pankajraghav.com; s=MBO0001; t=1710349381; 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=0O7jkYtxzM0DX7ZIGW+ZLQ370PUm3ZF/59ff/K84oK4=; b=ePofVGEsoAuYyqzVJOkLIjTDjgCqkUNNOdF5wzwok0juW1t96f6PLR+0tjm1jOKGs4hvX2 3677Dz+o7Boi66JMyxVV3+rcqBM/OQu7ZXWHFTDqbmsoC/7VAPHy8TXOPLcs2xNnWRdkls 5zLtrlq5B3Db6hJMkwoK7tF/b70+gbA+5G2XTJN6N/txcjTwGP+K/vtKUQExim+4ia4n7n ufxGGEgxOz5AjhMheKmu+XTB6CPt+uDyD+W2r3Efm4IK01gSenpsNoFRF73WLWeosdEIZA +kfkH2IJb5NGiYEd/YRBYCG5IsKjX7RavQEu4I7XeTAXcIo7nWlaRlfBUhvZ4A== From: "Pankaj Raghav (Samsung)" To: willy@infradead.org, linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org Cc: 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 Subject: [PATCH v3 01/11] mm: Support order-1 folios in the page cache Date: Wed, 13 Mar 2024 18:02:43 +0100 Message-ID: <20240313170253.2324812-2-kernel@pankajraghav.com> In-Reply-To: <20240313170253.2324812-1-kernel@pankajraghav.com> References: <20240313170253.2324812-1-kernel@pankajraghav.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: "Matthew Wilcox (Oracle)" Folios of order 1 have no space to store the deferred list. This is not a problem for the page cache as file-backed folios are never placed on the deferred list. All we need to do is prevent the core MM from touching the deferred list for order 1 folios and remove the code which prevented us from allocating order 1 folios. Link: https://lore.kernel.org/linux-mm/90344ea7-4eec-47ee-5996-0c22f42d6a6a= @google.com/ Signed-off-by: Matthew Wilcox (Oracle) --- include/linux/huge_mm.h | 7 +++++-- mm/filemap.c | 2 -- mm/huge_memory.c | 23 ++++++++++++++++++----- mm/internal.h | 4 +--- mm/readahead.c | 3 --- 5 files changed, 24 insertions(+), 15 deletions(-) diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h index 5adb86af35fc..916a2a539517 100644 --- a/include/linux/huge_mm.h +++ b/include/linux/huge_mm.h @@ -263,7 +263,7 @@ unsigned long thp_vma_allowable_orders(struct vm_area_s= truct *vma, unsigned long thp_get_unmapped_area(struct file *filp, unsigned long addr, unsigned long len, unsigned long pgoff, unsigned long flags); =20 -void folio_prep_large_rmappable(struct folio *folio); +struct folio *folio_prep_large_rmappable(struct folio *folio); bool can_split_folio(struct folio *folio, int *pextra_pins); int split_huge_page_to_list(struct page *page, struct list_head *list); static inline int split_huge_page(struct page *page) @@ -410,7 +410,10 @@ static inline unsigned long thp_vma_allowable_orders(s= truct vm_area_struct *vma, return 0; } =20 -static inline void folio_prep_large_rmappable(struct folio *folio) {} +static inline struct folio *folio_prep_large_rmappable(struct folio *folio) +{ + return folio; +} =20 #define transparent_hugepage_flags 0UL =20 diff --git a/mm/filemap.c b/mm/filemap.c index 4a30de98a8c7..a1cb3ea55fb6 100644 --- a/mm/filemap.c +++ b/mm/filemap.c @@ -1912,8 +1912,6 @@ struct folio *__filemap_get_folio(struct address_spac= e *mapping, pgoff_t index, gfp_t alloc_gfp =3D gfp; =20 err =3D -ENOMEM; - if (order =3D=3D 1) - order =3D 0; if (order > 0) alloc_gfp |=3D __GFP_NORETRY | __GFP_NOWARN; folio =3D filemap_alloc_folio(alloc_gfp, order); diff --git a/mm/huge_memory.c b/mm/huge_memory.c index 94c958f7ebb5..81fd1ba57088 100644 --- a/mm/huge_memory.c +++ b/mm/huge_memory.c @@ -788,11 +788,15 @@ struct deferred_split *get_deferred_split_queue(struc= t folio *folio) } #endif =20 -void folio_prep_large_rmappable(struct folio *folio) +struct folio *folio_prep_large_rmappable(struct folio *folio) { - VM_BUG_ON_FOLIO(folio_order(folio) < 2, folio); - INIT_LIST_HEAD(&folio->_deferred_list); + if (!folio || !folio_test_large(folio)) + return folio; + if (folio_order(folio) > 1) + INIT_LIST_HEAD(&folio->_deferred_list); folio_set_large_rmappable(folio); + + return folio; } =20 static inline bool is_transparent_hugepage(struct folio *folio) @@ -3082,7 +3086,8 @@ int split_huge_page_to_list(struct page *page, struct= list_head *list) /* Prevent deferred_split_scan() touching ->_refcount */ spin_lock(&ds_queue->split_queue_lock); if (folio_ref_freeze(folio, 1 + extra_pins)) { - if (!list_empty(&folio->_deferred_list)) { + if (folio_order(folio) > 1 && + !list_empty(&folio->_deferred_list)) { ds_queue->split_queue_len--; list_del(&folio->_deferred_list); } @@ -3133,6 +3138,9 @@ void folio_undo_large_rmappable(struct folio *folio) struct deferred_split *ds_queue; unsigned long flags; =20 + if (folio_order(folio) <=3D 1) + return; + /* * At this point, there is no one trying to add the folio to * deferred_list. If folio is not in deferred_list, it's safe @@ -3158,7 +3166,12 @@ void deferred_split_folio(struct folio *folio) #endif unsigned long flags; =20 - VM_BUG_ON_FOLIO(folio_order(folio) < 2, folio); + /* + * Order 1 folios have no space for a deferred list, but we also + * won't waste much memory by not adding them to the deferred list. + */ + if (folio_order(folio) <=3D 1) + return; =20 /* * The try_to_unmap() in page reclaim path might reach here too, diff --git a/mm/internal.h b/mm/internal.h index f309a010d50f..5174b5b0c344 100644 --- a/mm/internal.h +++ b/mm/internal.h @@ -419,9 +419,7 @@ static inline struct folio *page_rmappable_folio(struct= page *page) { struct folio *folio =3D (struct folio *)page; =20 - if (folio && folio_order(folio) > 1) - folio_prep_large_rmappable(folio); - return folio; + return folio_prep_large_rmappable(folio); } =20 static inline void prep_compound_head(struct page *page, unsigned int orde= r) diff --git a/mm/readahead.c b/mm/readahead.c index 2648ec4f0494..369c70e2be42 100644 --- a/mm/readahead.c +++ b/mm/readahead.c @@ -516,9 +516,6 @@ void page_cache_ra_order(struct readahead_control *ract= l, /* Don't allocate pages past EOF */ while (index + (1UL << order) - 1 > limit) order--; - /* THP machinery does not support order-1 */ - if (order =3D=3D 1) - order =3D 0; err =3D ra_alloc_folio(ractl, index, mark, order, gfp); if (err) break; --=20 2.43.0 From nobody Tue Jul 14 13:54:41 2026 Received: from mout-p-103.mailbox.org (mout-p-103.mailbox.org [80.241.56.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C5E5278272; Wed, 13 Mar 2024 17:10:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=80.241.56.161 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1710349832; cv=none; b=Ev4EwX4IvdNW8gy4CO2P6J4wVbZcO9mWB9u5R1uMInf+1DElyJZYBAvl/2DfpHD62ffEQtllcViDmK+g4T1reDM6F8eiA4b+ttyIjQ+k3SK8ufq6nqEM+r04AWlOLwihxWSseGZk3uJPkWYX3xllLrB9ClvDLfsV/olJg2VmoQs= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1710349832; c=relaxed/simple; bh=uEN3+Pd+RH/FPBp58dP39IOAx4Z8ypnrnt80ldJB+Go=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=iI+Pj7VxPqxaXIOeOaqbGK7tvmHeYONUgKm2CNigFniFqQz6etVU2namqMTNdO7TUmentODvW+gVQsZgbzy2ZPpb/g/DmfQ2rK/dZpRbOe8j56VJSyK5rFySfiiH35xv+ysQXm07HSX2wqCWyM8BK+I9HxxMrSvipU/Bjj6MJVw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=pankajraghav.com; spf=pass smtp.mailfrom=pankajraghav.com; dkim=pass (2048-bit key) header.d=pankajraghav.com header.i=@pankajraghav.com header.b=FKXPUs2f; arc=none smtp.client-ip=80.241.56.161 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=pankajraghav.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=pankajraghav.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=pankajraghav.com header.i=@pankajraghav.com header.b="FKXPUs2f" Received: from smtp202.mailbox.org (smtp202.mailbox.org [IPv6:2001:67c:2050:b231:465::202]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-103.mailbox.org (Postfix) with ESMTPS id 4TvxfK4Tbyz9t6h; Wed, 13 Mar 2024 18:03:05 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pankajraghav.com; s=MBO0001; t=1710349385; 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=wozYDNbmy2bEoKve6FiU3MASCD8dtvfm2o2W8jk+gfE=; b=FKXPUs2fuDsWqd/RzRu5+rfCFIpIrPx1U/+fFFTvFbtEhJZ8SHhGthBo8ybr9J0e992Svz pL6C17UJGmdo7r76XOQiQIkixF8r94mI5JB/lkuBCCigSVIkSmN7jHfl3raHipIQ5KAZWb c5Y2eUfhVSB3Z4l6Hj9Vk+Xpk0nZNezMEiaGU+agMZsFVIThR/QPChspgVvoelbmtIKFoo N+9tXSlYmyp77ZLvY7jjB5YwrSO64t+YMYuCAqqIr9//yrcOHRBt1b+m0sOkNlhKL0iDNJ pMAvyd+M8Lb7xTSjI+NfUl+xzmnpF751DjHQbTqryYQnvF9J4GcPLuwO63LOnw== From: "Pankaj Raghav (Samsung)" To: willy@infradead.org, linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org Cc: 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: [PATCH v3 02/11] fs: Allow fine-grained control of folio sizes Date: Wed, 13 Mar 2024 18:02:44 +0100 Message-ID: <20240313170253.2324812-3-kernel@pankajraghav.com> In-Reply-To: <20240313170253.2324812-1-kernel@pankajraghav.com> References: <20240313170253.2324812-1-kernel@pankajraghav.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4TvxfK4Tbyz9t6h Content-Type: text/plain; charset="utf-8" From: "Matthew Wilcox (Oracle)" Some filesystems want to be able to ensure that folios that are added to the page cache are at least a certain size. Add mapping_set_folio_min_order() to allow this level of control. Signed-off-by: Matthew Wilcox (Oracle) Co-developed-by: Pankaj Raghav Signed-off-by: Pankaj Raghav Signed-off-by: Luis Chamberlain Reviewed-by: Hannes Reinecke --- include/linux/pagemap.h | 100 ++++++++++++++++++++++++++++++++-------- 1 file changed, 80 insertions(+), 20 deletions(-) diff --git a/include/linux/pagemap.h b/include/linux/pagemap.h index 2df35e65557d..fc8eb9c94e9c 100644 --- a/include/linux/pagemap.h +++ b/include/linux/pagemap.h @@ -202,13 +202,18 @@ enum mapping_flags { AS_EXITING =3D 4, /* final truncate in progress */ /* writeback related tags are not used */ AS_NO_WRITEBACK_TAGS =3D 5, - AS_LARGE_FOLIO_SUPPORT =3D 6, - AS_RELEASE_ALWAYS, /* Call ->release_folio(), even if no private data */ - AS_STABLE_WRITES, /* must wait for writeback before modifying + AS_RELEASE_ALWAYS =3D 6, /* Call ->release_folio(), even if no private da= ta */ + AS_STABLE_WRITES =3D 7, /* must wait for writeback before modifying folio contents */ - AS_UNMOVABLE, /* The mapping cannot be moved, ever */ + AS_FOLIO_ORDER_MIN =3D 8, + AS_FOLIO_ORDER_MAX =3D 13, /* Bit 8-17 are used for FOLIO_ORDER */ + AS_UNMOVABLE =3D 18, /* The mapping cannot be moved, ever */ }; =20 +#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 @@ -344,9 +349,47 @@ static inline void mapping_set_gfp_mask(struct address= _space *m, gfp_t mask) m->gfp_mask =3D mask; } =20 +/* + * 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_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 *mappi= ng, + unsigned int min) +{ + if (min > MAX_PAGECACHE_ORDER) + min =3D MAX_PAGECACHE_ORDER; + + mapping->flags =3D (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. + * @mapping: The address_space. * * The filesystem should call this function in its inode constructor to * indicate that the VFS can use large folios to cache the contents of @@ -357,7 +400,37 @@ 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_min_order(mapping, 0); +} + +static inline unsigned int mapping_max_folio_order(struct address_space *m= apping) +{ + return (mapping->flags & AS_FOLIO_ORDER_MAX_MASK) >> AS_FOLIO_ORDER_MAX; +} + +static inline unsigned int mapping_min_folio_order(struct address_space *m= apping) +{ + return (mapping->flags & AS_FOLIO_ORDER_MIN_MASK) >> AS_FOLIO_ORDER_MIN; +} + +static inline unsigned long mapping_min_folio_nrpages(struct address_space= *mapping) +{ + return 1UL << mapping_min_folio_order(mapping); +} + +/** + * mapping_align_start_index() - Align starting index based on the min + * folio order of the page cache. + * @mapping: The address_space. + * + * Ensure the index used is aligned to the minimum folio order when adding + * new folios to the page cache by rounding down to the nearest minimum + * folio number of pages. + */ +static inline pgoff_t mapping_align_start_index(struct address_space *mapp= ing, + pgoff_t index) +{ + return round_down(index, mapping_min_folio_nrpages(mapping)); } =20 /* @@ -367,7 +440,7 @@ static inline void mapping_set_large_folios(struct addr= ess_space *mapping) static inline bool mapping_large_folio_support(struct address_space *mappi= ng) { return IS_ENABLED(CONFIG_TRANSPARENT_HUGEPAGE) && - test_bit(AS_LARGE_FOLIO_SUPPORT, &mapping->flags); + (mapping_max_folio_order(mapping) > 0); } =20 static inline int filemap_nr_thps(struct address_space *mapping) @@ -528,19 +601,6 @@ static inline void *detach_page_private(struct page *p= age) return folio_detach_private(page_folio(page)); } =20 -/* - * 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 --=20 2.43.0 From nobody Tue Jul 14 13:54:41 2026 Received: from mout-p-201.mailbox.org (mout-p-201.mailbox.org [80.241.56.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7914B197F07; Wed, 13 Mar 2024 17:03:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=80.241.56.171 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1710349400; cv=none; b=XHC2Cuv7yvlx9FHAv2K1KPr1hr6dIweatXAxdfO4l2s0SLg5ntoyXAl14jHbKRBUROjVJLUHangxNrkBVE4BAsft82u6p7W/xO4tFZg6Sk7vTuFtd7JFTOarLzzvTUqaiFDYd3gJm/g8jCyZyWyzZsVuTtIkksoppMXkDQOJfDk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1710349400; c=relaxed/simple; bh=YxB/X/48cfwolL9OjGvtP+CkDHnRLIxkhXlYkn7ryjk=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=td4dkZjb75rFHEGJHDN27WngYuLQm25KnlxbFHwMm0xLISZOKexpyeH+ykgJQz61lFFF2o8X9aogphvAD3gwb+Y8RifqhV1+zBJCIDfoC5IPvnr0F8FgkcP3hktK8r2VHG89xxzi5KBAIvhoWacWcI5WFvXLwQOhcwEh8U8jhLA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=pankajraghav.com; spf=pass smtp.mailfrom=pankajraghav.com; dkim=pass (2048-bit key) header.d=pankajraghav.com header.i=@pankajraghav.com header.b=CmOymcqE; arc=none smtp.client-ip=80.241.56.171 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=pankajraghav.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=pankajraghav.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=pankajraghav.com header.i=@pankajraghav.com header.b="CmOymcqE" Received: from smtp202.mailbox.org (smtp202.mailbox.org [IPv6:2001:67c:2050:b231:465::202]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-201.mailbox.org (Postfix) with ESMTPS id 4TvxfN6wJZz9sZ1; Wed, 13 Mar 2024 18:03:08 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pankajraghav.com; s=MBO0001; t=1710349389; 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=Wszp5hbUcP6JMNVNZOwpP5JGK1SwphDd9Wp1MxuYftg=; b=CmOymcqEA2k7F3fSEc2F0iZrVfdQjpS+vB/8mbuQc6OVEXK4IZaNdr26Mdt8g6AgFWGu+S /CcsBxKTvJT1TRyRh9A+aRMVGD1fy09gUUkNaLWdRLnQagNJEzLSuytM6bk+uf2+2uPZHR NozFQhS3e1i2r52JNALlZ8dxSL3OCSeTI8onadSfCy/V9uFlGUDynvxiSZ2ppEkNFvpUPE Re+YMOHOHJ8UaC/qsTcVZpYi69oAnc3A2wY4giR8dC7ieBM6FCviYzdlNCnz61gnqUlo01 v7XayFjgxuRzrlBX26Qau+MsdV8EI6YqAd1ZHFsgL4mfHVSEACXlboqLcp4Y9A== From: "Pankaj Raghav (Samsung)" To: willy@infradead.org, linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org Cc: 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: [PATCH v3 03/11] filemap: allocate mapping_min_order folios in the page cache Date: Wed, 13 Mar 2024 18:02:45 +0100 Message-ID: <20240313170253.2324812-4-kernel@pankajraghav.com> In-Reply-To: <20240313170253.2324812-1-kernel@pankajraghav.com> References: <20240313170253.2324812-1-kernel@pankajraghav.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4TvxfN6wJZz9sZ1 Content-Type: text/plain; charset="utf-8" From: Luis Chamberlain filemap_create_folio() and do_read_cache_folio() were always allocating folio of order 0. __filemap_get_folio was trying to allocate higher order folios when fgp_flags had higher order hint set but it will default to order 0 folio if higher order memory allocation fails. Supporting mapping_min_order implies that we guarantee each folio in the page cache has at least an order of mapping_min_order. When adding new folios to the page cache we must also ensure the index used is aligned to the mapping_min_order as the page cache requires the index to be aligned to the order of the folio. Signed-off-by: Luis Chamberlain Co-developed-by: Pankaj Raghav Signed-off-by: Pankaj Raghav --- mm/filemap.c | 24 +++++++++++++++++------- 1 file changed, 17 insertions(+), 7 deletions(-) diff --git a/mm/filemap.c b/mm/filemap.c index a1cb3ea55fb6..57889f206829 100644 --- a/mm/filemap.c +++ b/mm/filemap.c @@ -849,6 +849,8 @@ noinline int __filemap_add_folio(struct address_space *= mapping, =20 VM_BUG_ON_FOLIO(!folio_test_locked(folio), folio); VM_BUG_ON_FOLIO(folio_test_swapbacked(folio), folio); + VM_BUG_ON_FOLIO(folio_order(folio) < mapping_min_folio_order(mapping), + folio); mapping_set_update(&xas, mapping); =20 if (!huge) { @@ -1886,8 +1888,10 @@ struct folio *__filemap_get_folio(struct address_spa= ce *mapping, pgoff_t index, folio_wait_stable(folio); no_page: if (!folio && (fgp_flags & FGP_CREAT)) { - unsigned order =3D FGF_GET_ORDER(fgp_flags); + unsigned int min_order =3D mapping_min_folio_order(mapping); + unsigned int order =3D max(min_order, FGF_GET_ORDER(fgp_flags)); int err; + index =3D mapping_align_start_index(mapping, index); =20 if ((fgp_flags & FGP_WRITE) && mapping_can_writeback(mapping)) gfp |=3D __GFP_WRITE; @@ -1927,7 +1931,7 @@ struct folio *__filemap_get_folio(struct address_spac= e *mapping, pgoff_t index, break; folio_put(folio); folio =3D NULL; - } while (order-- > 0); + } while (order-- > min_order); =20 if (err =3D=3D -EEXIST) goto repeat; @@ -2416,13 +2420,16 @@ static int filemap_update_page(struct kiocb *iocb, } =20 static int filemap_create_folio(struct file *file, - struct address_space *mapping, pgoff_t index, + struct address_space *mapping, loff_t pos, struct folio_batch *fbatch) { struct folio *folio; int error; + unsigned int min_order =3D mapping_min_folio_order(mapping); + pgoff_t index; =20 - folio =3D filemap_alloc_folio(mapping_gfp_mask(mapping), 0); + folio =3D filemap_alloc_folio(mapping_gfp_mask(mapping), + min_order); if (!folio) return -ENOMEM; =20 @@ -2440,6 +2447,8 @@ static int filemap_create_folio(struct file *file, * well to keep locking rules simple. */ filemap_invalidate_lock_shared(mapping); + /* index in PAGE units but aligned to min_order number of pages. */ + index =3D (pos >> (PAGE_SHIFT + min_order)) << min_order; error =3D filemap_add_folio(mapping, folio, index, mapping_gfp_constraint(mapping, GFP_KERNEL)); if (error =3D=3D -EEXIST) @@ -2500,8 +2509,7 @@ static int filemap_get_pages(struct kiocb *iocb, size= _t count, if (!folio_batch_count(fbatch)) { if (iocb->ki_flags & (IOCB_NOWAIT | IOCB_WAITQ)) return -EAGAIN; - err =3D filemap_create_folio(filp, mapping, - iocb->ki_pos >> PAGE_SHIFT, fbatch); + err =3D filemap_create_folio(filp, mapping, iocb->ki_pos, fbatch); if (err =3D=3D AOP_TRUNCATED_PAGE) goto retry; return err; @@ -3662,9 +3670,11 @@ static struct folio *do_read_cache_folio(struct addr= ess_space *mapping, repeat: folio =3D filemap_get_folio(mapping, index); if (IS_ERR(folio)) { - folio =3D filemap_alloc_folio(gfp, 0); + folio =3D filemap_alloc_folio(gfp, + mapping_min_folio_order(mapping)); if (!folio) return ERR_PTR(-ENOMEM); + index =3D mapping_align_start_index(mapping, index); err =3D filemap_add_folio(mapping, folio, index, gfp); if (unlikely(err)) { folio_put(folio); --=20 2.43.0 From nobody Tue Jul 14 13:54:41 2026 Received: from mout-p-201.mailbox.org (mout-p-201.mailbox.org [80.241.56.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 020C2197F12; Wed, 13 Mar 2024 17:03:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=80.241.56.171 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1710349401; cv=none; b=OnBkhMRzSYFUw+q0JUdOM/L2F1mjChOnLxCP3nLdueSur2uYVAZ8YrxsNh4QwQqTYxhS96rtb6GrmtpcrFVshm7By1/x4SblZMpBL/GXOfeVUnsCjT5sz/K0yoTukuW66IrWx4xD2Ub0/A8Scw7QzntSRNs9UBlv8ZPYxoCLipM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1710349401; c=relaxed/simple; bh=SVxRi94L1loycCE1JyBsDivfSbS/LPTvG3kVbz3Q9S8=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=TA/KEVSaKjNzD05FzcyXrEIoxse+ZRnudEgq8Jqbm6B771YFvBTU3Tc7FPC7oirQ5GjRMgReTclFKfdWlFpKTu36B6Fh2x9g/RGdJ3Wb1skpqglo4zbF0h0k6/VNDKpaC4x4g55RZPjMqXI05xF7YLjoJ9xMbTzkmro1qcdfZTw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=pankajraghav.com; spf=pass smtp.mailfrom=pankajraghav.com; dkim=pass (2048-bit key) header.d=pankajraghav.com header.i=@pankajraghav.com header.b=iLuEZtwu; arc=none smtp.client-ip=80.241.56.171 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=pankajraghav.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=pankajraghav.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=pankajraghav.com header.i=@pankajraghav.com header.b="iLuEZtwu" Received: from smtp1.mailbox.org (smtp1.mailbox.org [IPv6:2001:67c:2050:b231:465::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-201.mailbox.org (Postfix) with ESMTPS id 4TvxfX4xPNz9sv2; Wed, 13 Mar 2024 18:03:16 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pankajraghav.com; s=MBO0001; t=1710349396; 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=LlktHRrCotj7h+dmYranbD+6rKP22De/aSKpvLU15xI=; b=iLuEZtwukGR8j/wP2yTR5lqu8w1dn1Om8H+h1Jrn/yb2Op1vTScowf81qXdWfFwhx03M/k lQ/ljugRNgFKv69Zpc6GDcMiFT9VCHupZ6ValiBdiFfuWsmov6aNUmcQiDMialZfyaybui 8T59W5m15KIJ0u/Ty4jAsUYT9GrTgDUpkTktfRWjiysbyXYSygMpuhFGLRtvAF3XUnEXNb PjoKw2atBz6K73ROKH0xNo9tEt25+B4heTtlXX02+5MGRYL4KHK5fIQB8ASFf3iPeRzqLB qWHeD/50YVeH/RmWQXjuSiVGmXs3wQCjp0KP/PxP8pUf+qiTnxODf+IHoVquZQ== From: "Pankaj Raghav (Samsung)" To: willy@infradead.org, linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org Cc: 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: [PATCH v3 04/11] readahead: rework loop in page_cache_ra_unbounded() Date: Wed, 13 Mar 2024 18:02:46 +0100 Message-ID: <20240313170253.2324812-5-kernel@pankajraghav.com> In-Reply-To: <20240313170253.2324812-1-kernel@pankajraghav.com> References: <20240313170253.2324812-1-kernel@pankajraghav.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4TvxfX4xPNz9sv2 Content-Type: text/plain; charset="utf-8" From: Hannes Reinecke Rework the loop in page_cache_ra_unbounded() to advance with the number of pages in a folio instead of just one page at a time. Signed-off-by: Hannes Reinecke Co-developed-by: Pankaj Raghav Signed-off-by: Pankaj Raghav Acked-by: Darrick J. Wong --- mm/readahead.c | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/mm/readahead.c b/mm/readahead.c index 369c70e2be42..37b938f4b54f 100644 --- a/mm/readahead.c +++ b/mm/readahead.c @@ -208,7 +208,7 @@ void page_cache_ra_unbounded(struct readahead_control *= ractl, struct address_space *mapping =3D ractl->mapping; unsigned long index =3D readahead_index(ractl); gfp_t gfp_mask =3D readahead_gfp_mask(mapping); - unsigned long i; + unsigned long i =3D 0; =20 /* * Partway through the readahead operation, we will have added @@ -226,7 +226,7 @@ void page_cache_ra_unbounded(struct readahead_control *= ractl, /* * Preallocate as many pages as we will need. */ - for (i =3D 0; i < nr_to_read; i++) { + while (i < nr_to_read) { struct folio *folio =3D xa_load(&mapping->i_pages, index + i); =20 if (folio && !xa_is_value(folio)) { @@ -239,8 +239,8 @@ void page_cache_ra_unbounded(struct readahead_control *= ractl, * not worth getting one just for that. */ read_pages(ractl); - ractl->_index++; - i =3D ractl->_index + ractl->_nr_pages - index - 1; + ractl->_index +=3D folio_nr_pages(folio); + i =3D ractl->_index + ractl->_nr_pages - index; continue; } =20 @@ -252,13 +252,14 @@ void page_cache_ra_unbounded(struct readahead_control= *ractl, folio_put(folio); read_pages(ractl); ractl->_index++; - i =3D ractl->_index + ractl->_nr_pages - index - 1; + i =3D ractl->_index + ractl->_nr_pages - index; continue; } if (i =3D=3D nr_to_read - lookahead_size) folio_set_readahead(folio); ractl->_workingset |=3D folio_test_workingset(folio); - ractl->_nr_pages++; + ractl->_nr_pages +=3D folio_nr_pages(folio); + i +=3D folio_nr_pages(folio); } =20 /* --=20 2.43.0 From nobody Tue Jul 14 13:54:41 2026 Received: from mout-p-101.mailbox.org (mout-p-101.mailbox.org [80.241.56.151]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 52F11198721; Wed, 13 Mar 2024 17:03:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=80.241.56.151 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1710349406; cv=none; b=WTV5h02vhWJCd5V/dS9Ooiisu3eSsEzV/kkrZZSnOkTkJTko0LOCyMFnlhjadxVYd+54UxQGSWYOQ3in5LiYrjYhzp1Y+oIUfaS3wXNM7qjWfugdT2D1hJ1Yju4/qUpkBhaCOyhoQUZ4PmS9WxqvawGaZ5CAEOdW1r+EcKs7zns= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1710349406; c=relaxed/simple; bh=oDNHNt2aySA06Gwd4USIX2lFcP+MCPQWTnRxxPtPQ9Q=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=NCtFkRln1zrrEvxQEfd5iRFlofG6VAk01FrxB8DaE2ukMrOT+4fZNSu2U8TCL/pv91N/FJbtO5Rhq7b7Y4P62ShHCLbeWgDvr2zoxPrgxgI22vwS42HQup3rc2K5A6dSp8gvzlZvSyEbCZAVovQrg4zhAU/Ox/J/YaTOGXTJMXg= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=pankajraghav.com; spf=pass smtp.mailfrom=pankajraghav.com; dkim=pass (2048-bit key) header.d=pankajraghav.com header.i=@pankajraghav.com header.b=TTj6XlQF; arc=none smtp.client-ip=80.241.56.151 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=pankajraghav.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=pankajraghav.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=pankajraghav.com header.i=@pankajraghav.com header.b="TTj6XlQF" Received: from smtp202.mailbox.org (smtp202.mailbox.org [IPv6:2001:67c:2050:b231:465::202]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-101.mailbox.org (Postfix) with ESMTPS id 4Tvxfc5Ylyz9svD; Wed, 13 Mar 2024 18:03:20 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pankajraghav.com; s=MBO0001; t=1710349400; 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=RU7wAkeEZDBqdQxVOpHCiR4r3AW1LNpG/Tc03yCcuTY=; b=TTj6XlQFpuWaG2HRYwVUmyL+mGDOj1YyE4BzeSzFG1uBTNOYHvqLSLJTAqTzOXnojbUFav VaI6Qsori+supnIjfxd7QOIIRBt1r3AjdYofmkNSsGr1IzJ+kCMctOkAAwm7VlS4HYxEwd xhBIKghw4OfU+qFZghRdae1Y3kRqk8ielVKILzxzoDayVYCCt3MRCU1hTX/PN4sZvgQ33s ldT65trmEXqfRbC8rb0GhMPrB26/1wbc37xM1ESEazL9aNIsjbMNJiTV0XGU5MF3Oqr4YQ tKChz4zQjWYPgbXBOzZwEHxjNui6cK8PvepNc7H9MPPB3lVOeKaxX9IUrPkHog== From: "Pankaj Raghav (Samsung)" To: willy@infradead.org, linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org Cc: 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: [PATCH v3 05/11] readahead: allocate folios with mapping_min_order in readahead Date: Wed, 13 Mar 2024 18:02:47 +0100 Message-ID: <20240313170253.2324812-6-kernel@pankajraghav.com> In-Reply-To: <20240313170253.2324812-1-kernel@pankajraghav.com> References: <20240313170253.2324812-1-kernel@pankajraghav.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4Tvxfc5Ylyz9svD Content-Type: text/plain; charset="utf-8" From: Pankaj Raghav page_cache_ra_unbounded() was allocating single pages (0 order folios) if there was no folio found in an index. Allocate mapping_min_order folios as we need to guarantee the minimum order if it is set. When read_pages() is triggered and if a page is already present, check for truncation and move the ractl->_index by mapping_min_nrpages if that folio was truncated. This is done to ensure we keep the alignment requirement while adding a folio to the page cache. page_cache_ra_order() tries to allocate folio to the page cache with a higher order if the index aligns with that order. Modify it so that the order does not go below the min_order requirement of the page cache. When adding new folios to the page cache we must also ensure the index used is aligned to the mapping_min_order as the page cache requires the index to be aligned to the order of the folio. readahead_expand() is called from readahead aops to extend the range of the readahead so this function can assume ractl->_index to be aligned with min_order. Signed-off-by: Pankaj Raghav --- mm/readahead.c | 86 ++++++++++++++++++++++++++++++++++++++++++-------- 1 file changed, 72 insertions(+), 14 deletions(-) diff --git a/mm/readahead.c b/mm/readahead.c index 37b938f4b54f..650834c033f0 100644 --- a/mm/readahead.c +++ b/mm/readahead.c @@ -206,9 +206,10 @@ void page_cache_ra_unbounded(struct readahead_control = *ractl, unsigned long nr_to_read, unsigned long lookahead_size) { struct address_space *mapping =3D ractl->mapping; - unsigned long index =3D readahead_index(ractl); + unsigned long index =3D readahead_index(ractl), ra_folio_index; gfp_t gfp_mask =3D readahead_gfp_mask(mapping); - unsigned long i =3D 0; + unsigned long i =3D 0, mark; + unsigned int min_nrpages =3D mapping_min_folio_nrpages(mapping); =20 /* * Partway through the readahead operation, we will have added @@ -223,6 +224,22 @@ void page_cache_ra_unbounded(struct readahead_control = *ractl, unsigned int nofs =3D memalloc_nofs_save(); =20 filemap_invalidate_lock_shared(mapping); + index =3D mapping_align_start_index(mapping, index); + + /* + * As iterator `i` is aligned to min_nrpages, round_up the + * difference between nr_to_read and lookahead_size to mark the + * index that only has lookahead or "async_region" to set the + * readahead flag. + */ + ra_folio_index =3D round_up(readahead_index(ractl) + nr_to_read - lookahe= ad_size, + min_nrpages); + mark =3D ra_folio_index - index; + if (index !=3D readahead_index(ractl)) { + nr_to_read +=3D readahead_index(ractl) - index; + ractl->_index =3D index; + } + /* * Preallocate as many pages as we will need. */ @@ -230,6 +247,8 @@ void page_cache_ra_unbounded(struct readahead_control *= ractl, struct folio *folio =3D xa_load(&mapping->i_pages, index + i); =20 if (folio && !xa_is_value(folio)) { + long nr_pages =3D folio_nr_pages(folio); + /* * Page already present? Kick off the current batch * of contiguous pages before continuing with the @@ -239,23 +258,35 @@ void page_cache_ra_unbounded(struct readahead_control= *ractl, * not worth getting one just for that. */ read_pages(ractl); - ractl->_index +=3D folio_nr_pages(folio); + + /* + * Move the ractl->_index by at least min_pages + * if the folio got truncated to respect the + * alignment constraint in the page cache. + * + */ + if (mapping !=3D folio->mapping) + nr_pages =3D min_nrpages; + + VM_BUG_ON_FOLIO(nr_pages < min_nrpages, folio); + ractl->_index +=3D nr_pages; i =3D ractl->_index + ractl->_nr_pages - index; continue; } =20 - folio =3D filemap_alloc_folio(gfp_mask, 0); + folio =3D filemap_alloc_folio(gfp_mask, + mapping_min_folio_order(mapping)); if (!folio) break; if (filemap_add_folio(mapping, folio, index + i, gfp_mask) < 0) { folio_put(folio); read_pages(ractl); - ractl->_index++; + ractl->_index +=3D min_nrpages; i =3D ractl->_index + ractl->_nr_pages - index; continue; } - if (i =3D=3D nr_to_read - lookahead_size) + if (i =3D=3D mark) folio_set_readahead(folio); ractl->_workingset |=3D folio_test_workingset(folio); ractl->_nr_pages +=3D folio_nr_pages(folio); @@ -489,12 +520,18 @@ void page_cache_ra_order(struct readahead_control *ra= ctl, { struct address_space *mapping =3D ractl->mapping; pgoff_t index =3D readahead_index(ractl); + unsigned int min_order =3D mapping_min_folio_order(mapping); pgoff_t limit =3D (i_size_read(mapping->host) - 1) >> PAGE_SHIFT; pgoff_t mark =3D index + ra->size - ra->async_size; int err =3D 0; gfp_t gfp =3D readahead_gfp_mask(mapping); + unsigned int min_ra_size =3D max(4, mapping_min_folio_nrpages(mapping)); =20 - if (!mapping_large_folio_support(mapping) || ra->size < 4) + /* + * Fallback when size < min_nrpages as each folio should be + * at least min_nrpages anyway. + */ + if (!mapping_large_folio_support(mapping) || ra->size < min_ra_size) goto fallback; =20 limit =3D min(limit, index + ra->size - 1); @@ -505,9 +542,19 @@ void page_cache_ra_order(struct readahead_control *rac= tl, new_order =3D MAX_PAGECACHE_ORDER; while ((1 << new_order) > ra->size) new_order--; + if (new_order < min_order) + new_order =3D min_order; } =20 filemap_invalidate_lock_shared(mapping); + /* + * If the new_order is greater than min_order and index is + * already aligned to new_order, then this will be noop as index + * aligned to new_order should also be aligned to min_order. + */ + ractl->_index =3D mapping_align_start_index(mapping, index); + index =3D readahead_index(ractl); + while (index <=3D limit) { unsigned int order =3D new_order; =20 @@ -515,7 +562,7 @@ void page_cache_ra_order(struct readahead_control *ract= l, if (index & ((1UL << order) - 1)) order =3D __ffs(index); /* Don't allocate pages past EOF */ - while (index + (1UL << order) - 1 > limit) + while (order > min_order && index + (1UL << order) - 1 > limit) order--; err =3D ra_alloc_folio(ractl, index, mark, order, gfp); if (err) @@ -778,8 +825,15 @@ void readahead_expand(struct readahead_control *ractl, struct file_ra_state *ra =3D ractl->ra; pgoff_t new_index, new_nr_pages; gfp_t gfp_mask =3D readahead_gfp_mask(mapping); + unsigned long min_nrpages =3D mapping_min_folio_nrpages(mapping); + unsigned int min_order =3D mapping_min_folio_order(mapping); =20 new_index =3D new_start / PAGE_SIZE; + /* + * Readahead code should have aligned the ractl->_index to + * min_nrpages before calling readahead aops. + */ + VM_BUG_ON(!IS_ALIGNED(ractl->_index, min_nrpages)); =20 /* Expand the leading edge downwards */ while (ractl->_index > new_index) { @@ -789,9 +843,11 @@ void readahead_expand(struct readahead_control *ractl, if (folio && !xa_is_value(folio)) return; /* Folio apparently present */ =20 - folio =3D filemap_alloc_folio(gfp_mask, 0); + folio =3D filemap_alloc_folio(gfp_mask, min_order); if (!folio) return; + + index =3D mapping_align_start_index(mapping, index); if (filemap_add_folio(mapping, folio, index, gfp_mask) < 0) { folio_put(folio); return; @@ -801,7 +857,7 @@ void readahead_expand(struct readahead_control *ractl, ractl->_workingset =3D true; psi_memstall_enter(&ractl->_pflags); } - ractl->_nr_pages++; + ractl->_nr_pages +=3D min_nrpages; ractl->_index =3D folio->index; } =20 @@ -816,9 +872,11 @@ void readahead_expand(struct readahead_control *ractl, if (folio && !xa_is_value(folio)) return; /* Folio apparently present */ =20 - folio =3D filemap_alloc_folio(gfp_mask, 0); + folio =3D filemap_alloc_folio(gfp_mask, min_order); if (!folio) return; + + index =3D mapping_align_start_index(mapping, index); if (filemap_add_folio(mapping, folio, index, gfp_mask) < 0) { folio_put(folio); return; @@ -828,10 +886,10 @@ void readahead_expand(struct readahead_control *ractl, ractl->_workingset =3D true; psi_memstall_enter(&ractl->_pflags); } - ractl->_nr_pages++; + ractl->_nr_pages +=3D min_nrpages; if (ra) { - ra->size++; - ra->async_size++; + ra->size +=3D min_nrpages; + ra->async_size +=3D min_nrpages; } } } --=20 2.43.0 From nobody Tue Jul 14 13:54:41 2026 Received: from mout-p-201.mailbox.org (mout-p-201.mailbox.org [80.241.56.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6C1CF60898; Wed, 13 Mar 2024 17:03:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=80.241.56.171 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1710349409; cv=none; b=OkZ5t/FYPs2MQVKmaWdfHYLmcLGbTU7BODGYkBRuwXpIIFKHrvmrAL9HeR4ZHpybp7Z00TysvXvpsvI30ub34AkqJEsa/HkWrHkeXNdlC9xh9dQ1mqtwOFJJYJkO6xfbPA0y4eMO4R3djybPO57pdxTNbULN5ryVe5YiDI85WAA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1710349409; c=relaxed/simple; bh=N90HyHZVwwldCpPQycLW/AGlmNXwgHSjmbrwJecuTXA=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=eZagKc4MvAh1DEFFOpCil3XzJq3d16ipzaGYbMbU4fRr8L7bgPf38+R+jlTLmf1Daoq8OvwvrEl3CDlPxXuHt4pkY4yk/QWwpdDEdQ6W3czXODbqdn+Mwc2hQDJjSHqpILAFRkrccs7YRS5gLg3UAshdZQIzzXj3AzaIcvRvbVU= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=pankajraghav.com; spf=pass smtp.mailfrom=pankajraghav.com; dkim=pass (2048-bit key) header.d=pankajraghav.com header.i=@pankajraghav.com header.b=xM9JIwoX; arc=none smtp.client-ip=80.241.56.171 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=pankajraghav.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=pankajraghav.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=pankajraghav.com header.i=@pankajraghav.com header.b="xM9JIwoX" Received: from smtp202.mailbox.org (smtp202.mailbox.org [10.196.197.202]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-201.mailbox.org (Postfix) with ESMTPS id 4Tvxfh15bQz9sZ1; Wed, 13 Mar 2024 18:03:24 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pankajraghav.com; s=MBO0001; t=1710349404; 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=vHEsUd+FYkmqqyGjADf/C4ejcwO7DnLkDR82am0hB3M=; b=xM9JIwoX5gfosfCIgrMHHI0lYvtdu6ZSdRS8udaibXJzPgqBiMrW7zluqYyjXMsntx79E6 2K2JqTPoFCW5ixCWR9tlqqjH1qKCyzUev3xHpZruPqOQHYPcZEKOxg8/ybdc4NAgczGzS4 7V9rgm9sX0lxn+RJdKbJpX7veZNi8RIO2ca6Eup7OaWjYAIdQZxeGzR8cRr5aDLlx9W379 0xvXMgN4k4w5usidPHXUIxwyv3at5dfBb6gkrUazd+wm7mrVE5lIkK4MCEp+J3yx8VzTUS r/b+/UPiq17+WJUtpABU496d59OseFcfLk7VMFEAyx72tw59+MsrrQajyD6jHQ== From: "Pankaj Raghav (Samsung)" To: willy@infradead.org, linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org Cc: 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: [PATCH v3 06/11] readahead: round up file_ra_state->ra_pages to mapping_min_nrpages Date: Wed, 13 Mar 2024 18:02:48 +0100 Message-ID: <20240313170253.2324812-7-kernel@pankajraghav.com> In-Reply-To: <20240313170253.2324812-1-kernel@pankajraghav.com> References: <20240313170253.2324812-1-kernel@pankajraghav.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Luis Chamberlain As we will be adding multiples of mapping_min_nrpages to the page cache, initialize file_ra_state->ra_pages with bdi->ra_pages rounded up to the nearest mapping_min_nrpages. Signed-off-by: Luis Chamberlain Signed-off-by: Pankaj Raghav --- mm/readahead.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/mm/readahead.c b/mm/readahead.c index 650834c033f0..50194fddecf1 100644 --- a/mm/readahead.c +++ b/mm/readahead.c @@ -138,7 +138,8 @@ void file_ra_state_init(struct file_ra_state *ra, struct address_space *mapping) { - ra->ra_pages =3D inode_to_bdi(mapping->host)->ra_pages; + ra->ra_pages =3D round_up(inode_to_bdi(mapping->host)->ra_pages, + mapping_min_folio_nrpages(mapping)); ra->prev_pos =3D -1; } EXPORT_SYMBOL_GPL(file_ra_state_init); --=20 2.43.0 From nobody Tue Jul 14 13:54:41 2026 Received: from mout-p-201.mailbox.org (mout-p-201.mailbox.org [80.241.56.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 861941991AA; Wed, 13 Mar 2024 17:03:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=80.241.56.171 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1710349412; cv=none; b=jZNQbjyKO6pRF57moZfmtko1tfFf/oETjMlksY5irOEsLu+bxr5fNtkTpfEC/are046OKlC7ABBdore2PQ1gNXjJjtC//ZJK9dKl6K6Y5fMnKC7HALkOOw46aVcUOO6THYT8k0Y0P9EfMYEUW6rp+WJaNyXHQQm3zJTs4sc3UAY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1710349412; c=relaxed/simple; bh=RpGDv7xjt1Tn0NAFmnUJ4dRChi0PW0zUu2AGhx/ey2I=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=CzhHdJsNnl8c/nZ/MsTh7N7lX/K6Ndgf37fELRahci5woO2FL0VrRgRaKpCDAWaUFuo3V6G5UKaQHU8NCi7EwuiNDh3ECyfCsmrA54rQrNAFavMDuzhgCa7/CQxPHrl9bk0W4r4qA3sTCEaBXEZuelQX7JG3UHRcWPqSWCgt0fM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=pankajraghav.com; spf=pass smtp.mailfrom=pankajraghav.com; dkim=pass (2048-bit key) header.d=pankajraghav.com header.i=@pankajraghav.com header.b=L+OtKexa; arc=none smtp.client-ip=80.241.56.171 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=pankajraghav.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=pankajraghav.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=pankajraghav.com header.i=@pankajraghav.com header.b="L+OtKexa" Received: from smtp202.mailbox.org (smtp202.mailbox.org [IPv6:2001:67c:2050:b231:465::202]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-201.mailbox.org (Postfix) with ESMTPS id 4Tvxfl1Ftrz9sqV; Wed, 13 Mar 2024 18:03:27 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pankajraghav.com; s=MBO0001; t=1710349407; 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=F3Xg5bE7lOUEiWrLgvJkawBGempm7FqinU/8gfujPB8=; b=L+OtKexa8lscvnV+tP6Qwfgscep0OokKJI+6VWJsVSvNCdYGHpjfa+oUx+M4CnU+flHItA Z7biTY7xoXAJWfjX8BUdzqizkXIbR083jNK0fC/LUb0rJ1ZBAH9+6gYFAQuNpHE9vI7/wL zbWzflaswuuxg1W3On8MRJaz9vHDwPBmneBEUngNZBU/bneNO4W9RdsLF/SuGWBcq4rFBL EDyHiJ9W22Go64+oMoK0yj/4z70enqNwtiC/3W/sgqAhc0pY2QxwX3uOcaTcmNTYsts4WV zcm5NCF1rZ91I8S3vS/p0psodGFJnSjvTeYE+LRQIBxvVmMN5SOOT2jfF38FPw== From: "Pankaj Raghav (Samsung)" To: willy@infradead.org, linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org Cc: 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: [PATCH v3 07/11] mm: do not split a folio if it has minimum folio order requirement Date: Wed, 13 Mar 2024 18:02:49 +0100 Message-ID: <20240313170253.2324812-8-kernel@pankajraghav.com> In-Reply-To: <20240313170253.2324812-1-kernel@pankajraghav.com> References: <20240313170253.2324812-1-kernel@pankajraghav.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4Tvxfl1Ftrz9sqV Content-Type: text/plain; charset="utf-8" From: Pankaj Raghav As we don't have a way to split a folio to a any given lower folio order yet, avoid splitting the folio in split_huge_page_to_list() if it has a minimum folio order requirement. Signed-off-by: Pankaj Raghav Signed-off-by: Luis Chamberlain Reviewed-by: Hannes Reinecke --- mm/huge_memory.c | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/mm/huge_memory.c b/mm/huge_memory.c index 81fd1ba57088..6ec3417638a1 100644 --- a/mm/huge_memory.c +++ b/mm/huge_memory.c @@ -3030,6 +3030,19 @@ int split_huge_page_to_list(struct page *page, struc= t list_head *list) goto out; } =20 + /* + * Do not split if mapping has minimum folio order + * requirement. + * + * XXX: Once we have support for splitting to any lower + * folio order, then it could be split based on the + * min_folio_order. + */ + if (mapping_min_folio_order(mapping)) { + ret =3D -EAGAIN; + goto out; + } + gfp =3D current_gfp_context(mapping_gfp_mask(mapping) & GFP_RECLAIM_MASK); =20 --=20 2.43.0 From nobody Tue Jul 14 13:54:41 2026 Received: from mout-p-103.mailbox.org (mout-p-103.mailbox.org [80.241.56.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8BE6B199896; Wed, 13 Mar 2024 17:03:33 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=80.241.56.161 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1710349415; cv=none; b=mJgbBAtf/e33SBzU6Fjr9WdRgMFj7JI8hiGOuOJHMrpor/DIwK1i5cNLKbw/uZA3Lo42dNORH05q0DeMUkWvK6SuqJiMbWGWAjIx4H3oFpXPsbmCGW6xKSVaRnEy/s4qEQvaiftuGD/Ijt2qt0b/FC6W5qSuuC6/IPVdxz2OI6E= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1710349415; c=relaxed/simple; bh=OPjPelr7jC5j/AA2ZEydqVDJmFXOxA3MXRxWvzjeqDU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=G1efBD2hwGcC7x4yH4uum4uxdvFpyA5GH2SwTI7LCy4r3O8PU14HG5loau9w3oT5Y+/kPYGcG2SlEQTytwE3IAhAGkRBxyqXrV7cIaVUBRb64Ydd1HztIz7ik2iAdjLRHH/1n+6tPcI+KsvS3KhnR6UCvaFSc3BGfQ0UEP++x4A= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=pankajraghav.com; spf=pass smtp.mailfrom=pankajraghav.com; dkim=pass (2048-bit key) header.d=pankajraghav.com header.i=@pankajraghav.com header.b=mvvw8Uxd; arc=none smtp.client-ip=80.241.56.161 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=pankajraghav.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=pankajraghav.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=pankajraghav.com header.i=@pankajraghav.com header.b="mvvw8Uxd" Received: from smtp202.mailbox.org (smtp202.mailbox.org [IPv6:2001:67c:2050:b231:465::202]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-103.mailbox.org (Postfix) with ESMTPS id 4Tvxfp0XHQz9sjG; Wed, 13 Mar 2024 18:03:30 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pankajraghav.com; s=MBO0001; t=1710349410; 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=CoSlfuEyGkiaGErrLwm5tBbxdIgWjqVT8F2G+alxKAU=; b=mvvw8Uxd8FI+cZwtRvS7Jb6PzVhcuKI2aUQbkfgZAXBDtjhGQc6l/aHdA/AuoMYeLf+Pha JCQRnn+aIlO10MBf3ldx/ILo5zGxFbvlXtliBuGk8I6tmj9crdNElXPe7JhhVnVL0YLvPx LcYQMAhx+gx+SIMNo/J1uYdpG21GWg6Pb7M8jLF7uAaV+FC9tnL6YC2H9w32hGf2WG4AI6 fQ1dBQ7uxhT+3f/VbS3J8HxQWXhZ1lxrpQZeNv4/66sHoQuND7xbilehbB17lzfXSqHkiD OamFwpDDrG1taP1i/YuGszkIkYVB9r3HPNQFh+JapI6Y5/q/DwMfYzwX3Z1bdQ== From: "Pankaj Raghav (Samsung)" To: willy@infradead.org, linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org Cc: 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: [PATCH v3 08/11] iomap: fix iomap_dio_zero() for fs bs > system page size Date: Wed, 13 Mar 2024 18:02:50 +0100 Message-ID: <20240313170253.2324812-9-kernel@pankajraghav.com> In-Reply-To: <20240313170253.2324812-1-kernel@pankajraghav.com> References: <20240313170253.2324812-1-kernel@pankajraghav.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4Tvxfp0XHQz9sjG Content-Type: text/plain; charset="utf-8" From: Pankaj Raghav iomap_dio_zero() will pad a fs block with zeroes if the direct IO size < fs block size. iomap_dio_zero() has an implicit assumption that fs block size < page_size. This is true for most filesystems at the moment. If the block size > page size, this will send the contents of the page next to zero page(as len > PAGE_SIZE) to the underlying block device, causing FS corruption. iomap is a generic infrastructure and it should not make any assumptions about the fs block size and the page size of the system. Signed-off-by: Pankaj Raghav Reviewed-by: Darrick J. Wong --- fs/iomap/direct-io.c | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/fs/iomap/direct-io.c b/fs/iomap/direct-io.c index bcd3f8cf5ea4..04f6c5548136 100644 --- a/fs/iomap/direct-io.c +++ b/fs/iomap/direct-io.c @@ -239,14 +239,23 @@ static void iomap_dio_zero(const struct iomap_iter *i= ter, struct iomap_dio *dio, struct page *page =3D ZERO_PAGE(0); struct bio *bio; =20 - bio =3D iomap_dio_alloc_bio(iter, dio, 1, REQ_OP_WRITE | REQ_SYNC | REQ_I= DLE); + WARN_ON_ONCE(len > (BIO_MAX_VECS * PAGE_SIZE)); + + bio =3D iomap_dio_alloc_bio(iter, dio, BIO_MAX_VECS, + REQ_OP_WRITE | REQ_SYNC | REQ_IDLE); fscrypt_set_bio_crypt_ctx(bio, inode, pos >> inode->i_blkbits, GFP_KERNEL); + bio->bi_iter.bi_sector =3D iomap_sector(&iter->iomap, pos); bio->bi_private =3D dio; bio->bi_end_io =3D iomap_dio_bio_end_io; =20 - __bio_add_page(bio, page, len, 0); + while (len) { + unsigned int io_len =3D min_t(unsigned int, len, PAGE_SIZE); + + __bio_add_page(bio, page, io_len, 0); + len -=3D io_len; + } iomap_dio_submit_bio(iter, dio, bio, pos); } =20 --=20 2.43.0 From nobody Tue Jul 14 13:54:41 2026 Received: from mout-p-103.mailbox.org (mout-p-103.mailbox.org [80.241.56.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9F7FA60B9B; Wed, 13 Mar 2024 17:03:36 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=80.241.56.161 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1710349421; cv=none; b=moW+8TI1pbEdZooqRvqiRmPBUStxzus6Osiqf6SuVcI7GYi3CK93u6dFNPldrWZsqi5iL4FeZ0u3f9M0J5VJO6nrLSe9ixG3va86nXFOGsZtDLX5o82FLByiJJGudq/wXvy7jsjUyh5hFod/sZlrTmhFN5uD2v2RvHjw+QWu63s= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1710349421; c=relaxed/simple; bh=8h2k716LEkRXj/j4QF0KIKvbMa13OHXZcCU5xl00czw=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=GOKwJD44+CS9fjuiYZkThOKMpeua7tSx6+XxfBCuufi6qGG9nrF7Lz5P8ZreU5p8c9oyJeaLgLuTyCLKTY+Z8CLqYfVXlv2y0dKMMkiqLJ/UUvr+/RB6D8x/kvLIJbVvbnWCKdvttkuSKnxD5IsWc1GA+fj/KmFNqBm42Gi+ROI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=pankajraghav.com; spf=pass smtp.mailfrom=pankajraghav.com; dkim=pass (2048-bit key) header.d=pankajraghav.com header.i=@pankajraghav.com header.b=mZa/2rNz; arc=none smtp.client-ip=80.241.56.161 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=pankajraghav.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=pankajraghav.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=pankajraghav.com header.i=@pankajraghav.com header.b="mZa/2rNz" Received: from smtp202.mailbox.org (smtp202.mailbox.org [IPv6:2001:67c:2050:b231:465::202]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-103.mailbox.org (Postfix) with ESMTPS id 4Tvxfr5XYdz9svD; Wed, 13 Mar 2024 18:03:32 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pankajraghav.com; s=MBO0001; t=1710349412; 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=hTTuIiANd5kCHMpVIcnhOGjU1SgMYOpCUNpWo+aN5OQ=; b=mZa/2rNzUk5ItRGjmpFKbIx/e9/B2IW9ObJbSGaxYPcM6/REiNCqEk1WTvXyVIEg1IRLvo diMbHNgV0MF5F7anhDmyOFyn+elkV53QF7ODdqxDx3aNbteQwUgYMBNmP0FX6xERwETv8v J09mtYXdl9rfRkqC58xp6gSWM+i40fSvzFOJP+TdAu3FZq0m5EC1qZoNbnrd7jm1YKBAHd +vribik6eOON1VvDG9qzhVhSqph3+50/mkKuElzubYMNsOZc9lddHkPGrZzxIO+BWa9plt dDJmdXsM+i/9cSpi6ibNvk1ucveXD2OXrIf9fZ21iljyuGKrUV+HA1m+kDNgfQ== From: "Pankaj Raghav (Samsung)" To: willy@infradead.org, linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org Cc: 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: [PATCH v3 09/11] xfs: expose block size in stat Date: Wed, 13 Mar 2024 18:02:51 +0100 Message-ID: <20240313170253.2324812-10-kernel@pankajraghav.com> In-Reply-To: <20240313170253.2324812-1-kernel@pankajraghav.com> References: <20240313170253.2324812-1-kernel@pankajraghav.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4Tvxfr5XYdz9svD Content-Type: text/plain; charset="utf-8" From: Pankaj Raghav For block size larger than page size, the unit of efficient IO is the block size, not the page size. Leaving stat() to report PAGE_SIZE as the block size causes test programs like fsx to issue illegal ranges for operations that require block size alignment (e.g. fallocate() insert range). Hence update the preferred IO size to reflect the block size in this case. This change is based on a patch originally from Dave Chinner.[1] [1] https://lwn.net/ml/linux-fsdevel/20181107063127.3902-16-david@fromorbit= .com/ Signed-off-by: Pankaj Raghav Signed-off-by: Luis Chamberlain --- fs/xfs/xfs_iops.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/xfs/xfs_iops.c b/fs/xfs/xfs_iops.c index a0d77f5f512e..7ee829f7d708 100644 --- a/fs/xfs/xfs_iops.c +++ b/fs/xfs/xfs_iops.c @@ -543,7 +543,7 @@ xfs_stat_blksize( return 1U << mp->m_allocsize_log; } =20 - return PAGE_SIZE; + return max_t(uint32_t, PAGE_SIZE, mp->m_sb.sb_blocksize); } =20 STATIC int --=20 2.43.0 From nobody Tue Jul 14 13:54:41 2026 Received: from mout-p-101.mailbox.org (mout-p-101.mailbox.org [80.241.56.151]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 75852199EE0; Wed, 13 Mar 2024 17:03:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=80.241.56.151 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1710349421; cv=none; b=knU55o38ajZYS5fRaxmjiX7cvLtBqjqqbovMrqS6UXnjrvIHjMbOdamkCII8nzJq9wZzVaUXDO5ULMcVbPXBKEsIPE8A4ZcjIaYmPWMPpv1xJMzWOnD4b+HfLX8kw8hnXZoOlfl4OZKivWz6RSSVOsiRtXL7VRyu4xjKK45dd3c= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1710349421; c=relaxed/simple; bh=TxlF0K0AnCi7IfUOf9fZ9W/wQu6fwrGsP17GgzEpFC4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=mWC1rdfrPmfReqh5YJNYh1VWN7eAWNmZpnz11YLiTi2LejLq355xxlTQ1ZU030hez4YxcqvAJSj82774S7K4Y3lR2c4gOT0Y0SsnfwQaXjQcctswKBK8kLbAylN5u3EEAXEln7OhbBPZsbtK/bUlvd5g0zu1mmkdKO17Xox3HlY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=pankajraghav.com; spf=pass smtp.mailfrom=pankajraghav.com; dkim=pass (2048-bit key) header.d=pankajraghav.com header.i=@pankajraghav.com header.b=1zEwGmy7; arc=none smtp.client-ip=80.241.56.151 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=pankajraghav.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=pankajraghav.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=pankajraghav.com header.i=@pankajraghav.com header.b="1zEwGmy7" Received: from smtp202.mailbox.org (smtp202.mailbox.org [10.196.197.202]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-101.mailbox.org (Postfix) with ESMTPS id 4Tvxfv74R3z9sv7; Wed, 13 Mar 2024 18:03:35 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pankajraghav.com; s=MBO0001; t=1710349416; 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=jHOAd9x0YRVSd/dvnN0auN+I3KtosAxaAU4ZYQzup9I=; b=1zEwGmy7yxhQYT3bkSq+Y8tjRwEtpGIPiHQ8HX5SqWTyU5bCefTd7tYonFqfWq0MxoazNT i1/Ype9sIPvQXhYTGeDAgZoWccjAL5Hbcf1jIb7liUIkQV/KMPw7lD+vBdoencCUyBPe1+ VV0IO2fa1GoA3/Do51YEVKmtxtA6DXma9yKGF2hRt0kYlOrbAveBmUDcOmOxein9DrCrDP qPSRtgjqeFNZcuS9xLxEs0rJ4sFa7UUBFedirfY334tlBRmQDPCL/9qk0OeJGPCtw+OoaP RxOray1t/hXKdF8nnZEEVcAHMRsZgZocGVm8E0eSVcjKNjMZVsTJ0K9WwqtvNQ== From: "Pankaj Raghav (Samsung)" To: willy@infradead.org, linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org Cc: 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: [PATCH v3 10/11] xfs: make the calculation generic in xfs_sb_validate_fsb_count() Date: Wed, 13 Mar 2024 18:02:52 +0100 Message-ID: <20240313170253.2324812-11-kernel@pankajraghav.com> In-Reply-To: <20240313170253.2324812-1-kernel@pankajraghav.com> References: <20240313170253.2324812-1-kernel@pankajraghav.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Pankaj Raghav Instead of assuming that PAGE_SHIFT is always higher than the blocklog, make the calculation generic so that page cache count can be calculated correctly for LBS. Signed-off-by: Pankaj Raghav --- fs/xfs/xfs_mount.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/fs/xfs/xfs_mount.c b/fs/xfs/xfs_mount.c index aabb25dc3efa..9cf800586da7 100644 --- a/fs/xfs/xfs_mount.c +++ b/fs/xfs/xfs_mount.c @@ -133,9 +133,16 @@ xfs_sb_validate_fsb_count( { ASSERT(PAGE_SHIFT >=3D sbp->sb_blocklog); ASSERT(sbp->sb_blocklog >=3D BBSHIFT); + uint64_t max_index; + uint64_t max_bytes; + + if (check_shl_overflow(nblocks, sbp->sb_blocklog, &max_bytes)) + return -EFBIG; =20 /* Limited by ULONG_MAX of page cache index */ - if (nblocks >> (PAGE_SHIFT - sbp->sb_blocklog) > ULONG_MAX) + max_index =3D max_bytes >> PAGE_SHIFT; + + if (max_index > ULONG_MAX) return -EFBIG; return 0; } --=20 2.43.0 From nobody Tue Jul 14 13:54:41 2026 Received: from mout-p-202.mailbox.org (mout-p-202.mailbox.org [80.241.56.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1780019A56A; Wed, 13 Mar 2024 17:03:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=80.241.56.172 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1710349424; cv=none; b=qEOGB3w0Rb6DOrK0TxK6LjA5jOywhgViD8w517wOK7yTxx21mqi8lCt41+LaJoHIaqVe00TGpXvbTks+Fgish6Syfb3VMTMuPcy07MqnFAlkuTg43+tOAIwMNFxfxUeYInL5kNMlFUaCK6nk07h9Z8WOIF6MYaKY2nEIQ3wL/P0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1710349424; c=relaxed/simple; bh=3L4GbT2GGY6ZkVB0Gbmb4Xhq7Pezq97Uzm/KdVsUIvg=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=aIYuPuy2L5vPXnb0ZY8sPafwDYe3mETGWRhNeRff+hHfSuxbCwnRe1KgRbIhwyjeiFW+o0JWbAjgYh7U/fDnf1TZ6n4iXOoKSyfuyaht+8ksbmv3jPQNUMTeR01RezyUFvyI68QlmkKBGeJvPTEZFu58SFRVKFMT3AP6I0FCmLM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=pankajraghav.com; spf=pass smtp.mailfrom=pankajraghav.com; dkim=pass (2048-bit key) header.d=pankajraghav.com header.i=@pankajraghav.com header.b=Qsht05+U; arc=none smtp.client-ip=80.241.56.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=pankajraghav.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=pankajraghav.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=pankajraghav.com header.i=@pankajraghav.com header.b="Qsht05+U" Received: from smtp102.mailbox.org (smtp102.mailbox.org [10.196.197.102]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-202.mailbox.org (Postfix) with ESMTPS id 4Tvxfz2mzqz9srv; Wed, 13 Mar 2024 18:03:39 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pankajraghav.com; s=MBO0001; t=1710349419; 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=K/DUVmmSdMYXfogG3VkAiYhU6qYgNVi5gtPJ5i04LEI=; b=Qsht05+Uu/iP54oqngBXP2qLeNxikfv1Eh/QI13SRmymWufjW1qsMdPY+89rtgm6i4g39y SWW8c6kh0MkZTAY9/vDjZV0NUuGdfEDYIvP8SiXji0DUHluzyiOXftszOjn9q5H1LKy/1C Wmuim/RYXM+z/vXQclsx99izmsENZc4h3Rx1QHNx1sH/37t7Egj0nIEXHyTQVY2eGhYv6O juM46526/LJPKkmSZaGglSY7Z+d/pVduLN+qUMl02bRL2+VEd2C2B1ztr6Pz8AjlF74Dwr r544zElg3fjru2Ijy1ZG+m2sSurj0ux4aO+w3OnINoA1SJvA+sNnSqIZUgG9Vg== From: "Pankaj Raghav (Samsung)" To: willy@infradead.org, linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org Cc: 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: [PATCH v3 11/11] xfs: enable block size larger than page size support Date: Wed, 13 Mar 2024 18:02:53 +0100 Message-ID: <20240313170253.2324812-12-kernel@pankajraghav.com> In-Reply-To: <20240313170253.2324812-1-kernel@pankajraghav.com> References: <20240313170253.2324812-1-kernel@pankajraghav.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Pankaj Raghav Page cache now has the ability to have a minimum order when allocating a folio which is a prerequisite to add support for block size > page size. Signed-off-by: Pankaj Raghav Signed-off-by: Luis Chamberlain --- fs/xfs/libxfs/xfs_ialloc.c | 5 +++++ fs/xfs/libxfs/xfs_shared.h | 3 +++ fs/xfs/xfs_icache.c | 6 ++++-- fs/xfs/xfs_mount.c | 1 - fs/xfs/xfs_super.c | 10 ++-------- 5 files changed, 14 insertions(+), 11 deletions(-) diff --git a/fs/xfs/libxfs/xfs_ialloc.c b/fs/xfs/libxfs/xfs_ialloc.c index 2361a22035b0..c040bd6271fd 100644 --- a/fs/xfs/libxfs/xfs_ialloc.c +++ b/fs/xfs/libxfs/xfs_ialloc.c @@ -2892,6 +2892,11 @@ xfs_ialloc_setup_geometry( igeo->ialloc_align =3D mp->m_dalign; else igeo->ialloc_align =3D 0; + + if (mp->m_sb.sb_blocksize > PAGE_SIZE) + igeo->min_folio_order =3D mp->m_sb.sb_blocklog - PAGE_SHIFT; + else + igeo->min_folio_order =3D 0; } =20 /* Compute the location of the root directory inode that is laid out by mk= fs. */ diff --git a/fs/xfs/libxfs/xfs_shared.h b/fs/xfs/libxfs/xfs_shared.h index 4220d3584c1b..67ed406e7a81 100644 --- a/fs/xfs/libxfs/xfs_shared.h +++ b/fs/xfs/libxfs/xfs_shared.h @@ -188,6 +188,9 @@ struct xfs_ino_geometry { /* precomputed value for di_flags2 */ uint64_t new_diflags2; =20 + /* minimum folio order of a page cache allocation */ + unsigned int min_folio_order; + }; =20 #endif /* __XFS_SHARED_H__ */ diff --git a/fs/xfs/xfs_icache.c b/fs/xfs/xfs_icache.c index dba514a2c84d..a1857000e2cd 100644 --- a/fs/xfs/xfs_icache.c +++ b/fs/xfs/xfs_icache.c @@ -88,7 +88,8 @@ xfs_inode_alloc( /* VFS doesn't initialise i_mode or i_state! */ VFS_I(ip)->i_mode =3D 0; VFS_I(ip)->i_state =3D 0; - mapping_set_large_folios(VFS_I(ip)->i_mapping); + mapping_set_folio_min_order(VFS_I(ip)->i_mapping, + M_IGEO(mp)->min_folio_order); =20 XFS_STATS_INC(mp, vn_active); ASSERT(atomic_read(&ip->i_pincount) =3D=3D 0); @@ -323,7 +324,8 @@ xfs_reinit_inode( inode->i_rdev =3D dev; inode->i_uid =3D uid; inode->i_gid =3D gid; - mapping_set_large_folios(inode->i_mapping); + mapping_set_folio_min_order(inode->i_mapping, + M_IGEO(mp)->min_folio_order); return error; } =20 diff --git a/fs/xfs/xfs_mount.c b/fs/xfs/xfs_mount.c index 9cf800586da7..a77e927807e5 100644 --- a/fs/xfs/xfs_mount.c +++ b/fs/xfs/xfs_mount.c @@ -131,7 +131,6 @@ xfs_sb_validate_fsb_count( xfs_sb_t *sbp, uint64_t nblocks) { - ASSERT(PAGE_SHIFT >=3D sbp->sb_blocklog); ASSERT(sbp->sb_blocklog >=3D BBSHIFT); uint64_t max_index; uint64_t max_bytes; diff --git a/fs/xfs/xfs_super.c b/fs/xfs/xfs_super.c index 98401de832ee..4f5f4cb772d4 100644 --- a/fs/xfs/xfs_super.c +++ b/fs/xfs/xfs_super.c @@ -1624,16 +1624,10 @@ xfs_fs_fill_super( goto out_free_sb; } =20 - /* - * Until this is fixed only page-sized or smaller data blocks work. - */ if (mp->m_sb.sb_blocksize > PAGE_SIZE) { xfs_warn(mp, - "File system with blocksize %d bytes. " - "Only pagesize (%ld) or less will currently work.", - mp->m_sb.sb_blocksize, PAGE_SIZE); - error =3D -ENOSYS; - goto out_free_sb; +"EXPERIMENTAL: Filesystem with Large Block Size (%d bytes) enabled.", + mp->m_sb.sb_blocksize); } =20 /* Ensure this filesystem fits in the page cache limits */ --=20 2.43.0