| Message ID | 20240213215520.1048625-1-zi.yan@sent.com |
|---|---|
| Headers | show |
| Series | Split a folio to any lower order folios | expand |
On 13.02.24 23:05, Luis Chamberlain wrote: > On Tue, Feb 13, 2024 at 04:55:18PM -0500, Zi Yan wrote: >> From: Zi Yan <ziy@nvidia.com> >> Order-1 folio is not supported because _deferred_list, which is used by >> partially mapped folios, is stored in subpage 2 and an order-1 folio only >> has subpage 0 and 1. > > The LBS patches has the patch from Matthew which enables and allowed us > to successfully test order 1. So this restriction could be dropped if > that gets merged. For anon folios it will still be in place, so the restriction will only be dropped for !anon.
On 13 Feb 2024, at 17:15, Zi Yan wrote: > On 13 Feb 2024, at 17:05, Luis Chamberlain wrote: > >> On Tue, Feb 13, 2024 at 04:55:18PM -0500, Zi Yan wrote: >>> From: Zi Yan <ziy@nvidia.com> >>> Order-1 folio is not supported because _deferred_list, which is used by >>> partially mapped folios, is stored in subpage 2 and an order-1 folio only >>> has subpage 0 and 1. >> >> The LBS patches has the patch from Matthew which enables and allowed us >> to successfully test order 1. So this restriction could be dropped if >> that gets merged. > > OK. But it only applies to file-backed folios IIUC. Anonymous folios still > cannot be split to order-1. Something like this would lift the restriction: diff --git a/mm/huge_memory.c b/mm/huge_memory.c index 0564b007cbd1..7ee7f1906617 100644 --- a/mm/huge_memory.c +++ b/mm/huge_memory.c @@ -3045,9 +3045,9 @@ int split_huge_page_to_list_to_order(struct page *page, struct list_head *list, VM_BUG_ON_FOLIO(!folio_test_locked(folio), folio); VM_BUG_ON_FOLIO(!folio_test_large(folio), folio); - /* Cannot split THP to order-1 (no order-1 THPs) */ - if (new_order == 1) { - VM_WARN_ONCE(1, "Cannot split to order-1 folio"); + /* Cannot split anonymous folios to order-1 (no order-1 anon folios) */ + if (new_order == 1 && folio_test_anon(folio)) { + VM_WARN_ONCE(1, "Cannot split to order-1 anonymous folio"); return -EINVAL; } -- Best Regards, Yan, Zi
On 13 Feb 2024, at 17:21, David Hildenbrand wrote: > On 13.02.24 22:55, Zi Yan wrote: >> From: Zi Yan <ziy@nvidia.com> >> >> Hi all, >> >> File folio supports any order and multi-size THP is upstreamed[1], so both >> file and anonymous folios can be >0 order. Currently, split_huge_page() >> only splits a huge page to order-0 pages, but splitting to orders higher than >> 0 is going to better utilize large folios. In addition, Large Block >> Sizes in XFS support would benefit from it[2]. This patchset adds support for >> splitting a large folio to any lower order folios and uses it during file >> folio truncate operations. >> >> For Patch 6, Hugh did not like my approach to minimize the number of >> folios for truncate[3]. I would like to get more feedback, especially >> from FS people, on it to decide whether to keep it or not. > > I'm curious, would it make sense to exclude the "more" controversial parts (i.e., patch #6) for now, and focus on the XFS use case only? Sure. Patch 6 was there to make use of split_huge_page_to_list_to_order(). Now we have multi-size THP and XFS use cases, it can be dropped. -- Best Regards, Yan, Zi
On 13 Feb 2024, at 17:19, Zi Yan wrote: > On 13 Feb 2024, at 17:15, Zi Yan wrote: > >> On 13 Feb 2024, at 17:05, Luis Chamberlain wrote: >> >>> On Tue, Feb 13, 2024 at 04:55:18PM -0500, Zi Yan wrote: >>>> From: Zi Yan <ziy@nvidia.com> >>>> Order-1 folio is not supported because _deferred_list, which is used by >>>> partially mapped folios, is stored in subpage 2 and an order-1 folio only >>>> has subpage 0 and 1. >>> >>> The LBS patches has the patch from Matthew which enables and allowed us >>> to successfully test order 1. So this restriction could be dropped if >>> that gets merged. >> >> OK. But it only applies to file-backed folios IIUC. Anonymous folios still >> cannot be split to order-1. > > Something like this would lift the restriction: Actually this, since folio_prep_large_rmappable() is changed by that patch: diff --git a/mm/huge_memory.c b/mm/huge_memory.c index 0564b007cbd1..05eeeafaa9dc 100644 --- a/mm/huge_memory.c +++ b/mm/huge_memory.c @@ -2852,7 +2852,7 @@ static void __split_huge_page_tail(struct folio *folio, int tail, clear_compound_head(page_tail); if (new_order) { prep_compound_page(page_tail, new_order); - folio_prep_large_rmappable(page_folio(page_tail)); + new_folio = folio_prep_large_rmappable(new_folio); } /* Finally unfreeze refcount. Additional reference from page cache. */ @@ -3045,9 +3045,9 @@ int split_huge_page_to_list_to_order(struct page *page, struct list_head *list, VM_BUG_ON_FOLIO(!folio_test_locked(folio), folio); VM_BUG_ON_FOLIO(!folio_test_large(folio), folio); - /* Cannot split THP to order-1 (no order-1 THPs) */ - if (new_order == 1) { - VM_WARN_ONCE(1, "Cannot split to order-1 folio"); + /* Cannot split anonymous folios to order-1 (no order-1 anon folios) */ + if (new_order == 1 && folio_test_anon(folio)) { + VM_WARN_ONCE(1, "Cannot split to order-1 anonymous folio"); return -EINVAL; } -- Best Regards, Yan, Zi
On 13.02.24 22:55, Zi Yan wrote: > From: Zi Yan <ziy@nvidia.com> > > We do not have non power of two pages, using nr is error prone if nr > is not power-of-two. Use page order instead. > > Signed-off-by: Zi Yan <ziy@nvidia.com> > --- > include/linux/memcontrol.h | 4 ++-- > mm/huge_memory.c | 3 ++- > mm/memcontrol.c | 3 ++- > mm/page_alloc.c | 4 ++-- > 4 files changed, 8 insertions(+), 6 deletions(-) > > diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h > index 4e4caeaea404..173bbb53c1ec 100644 > --- a/include/linux/memcontrol.h > +++ b/include/linux/memcontrol.h > @@ -1163,7 +1163,7 @@ static inline void memcg_memory_event_mm(struct mm_struct *mm, > rcu_read_unlock(); > } > > -void split_page_memcg(struct page *head, unsigned int nr); > +void split_page_memcg(struct page *head, int order); > > unsigned long mem_cgroup_soft_limit_reclaim(pg_data_t *pgdat, int order, > gfp_t gfp_mask, > @@ -1621,7 +1621,7 @@ void count_memcg_event_mm(struct mm_struct *mm, enum vm_event_item idx) > { > } > > -static inline void split_page_memcg(struct page *head, unsigned int nr) > +static inline void split_page_memcg(struct page *head, int order) > { > } > > diff --git a/mm/huge_memory.c b/mm/huge_memory.c > index 016e20bd813e..0cd5fba0923c 100644 > --- a/mm/huge_memory.c > +++ b/mm/huge_memory.c > @@ -2877,9 +2877,10 @@ static void __split_huge_page(struct page *page, struct list_head *list, > unsigned long offset = 0; > unsigned int nr = thp_nr_pages(head); > int i, nr_dropped = 0; > + int order = folio_order(folio); You could calculate "nr" from "order" here, removing the usage of thp_nr_pages(). > > /* complete memcg works before add pages to LRU */ > - split_page_memcg(head, nr); > + split_page_memcg(head, order); > > if (folio_test_anon(folio) && folio_test_swapcache(folio)) { Acked-by: David Hildenbrand <david@redhat.com>
On 13.02.24 22:55, Zi Yan wrote: > From: Zi Yan <ziy@nvidia.com> > > It sets memcg information for the pages after the split. A new parameter > new_order is added to tell the order of subpages in the new page, always 0 > for now. It prepares for upcoming changes to support split huge page to > any lower order. > > Signed-off-by: Zi Yan <ziy@nvidia.com> > --- Nothing jumped at me. Acked-by: David Hildenbrand <david@redhat.com>
On 13/02/2024 21:55, Zi Yan wrote: > From: Zi Yan <ziy@nvidia.com> > > To split a THP to any lower order (except order-1) pages, we need to > reform THPs on subpages at given order and add page refcount based on the > new page order. Also we need to reinitialize page_deferred_list after > removing the page from the split_queue, otherwise a subsequent split will > see list corruption when checking the page_deferred_list again. > > It has many uses, like minimizing the number of pages after > truncating a huge pagecache page. For anonymous THPs, we can only split > them to order-0 like before until we add support for any size anonymous > THPs. multi-size THP is now upstream. Not sure if this comment still makes sense. Still its not completely clear to me how you would integrate this new machinery and decide what non-zero order to split anon THP to? > > Order-1 folio is not supported because _deferred_list, which is used by > partially mapped folios, is stored in subpage 2 and an order-1 folio only > has subpage 0 and 1. > > Signed-off-by: Zi Yan <ziy@nvidia.com> > --- > include/linux/huge_mm.h | 21 +++++--- > mm/huge_memory.c | 114 +++++++++++++++++++++++++++++++--------- > 2 files changed, 101 insertions(+), 34 deletions(-) > > diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h > index 5adb86af35fc..de0c89105076 100644 > --- a/include/linux/huge_mm.h > +++ b/include/linux/huge_mm.h > @@ -265,10 +265,11 @@ unsigned long thp_get_unmapped_area(struct file *filp, unsigned long addr, > > void 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); > +int split_huge_page_to_list_to_order(struct page *page, struct list_head *list, > + unsigned int new_order); > static inline int split_huge_page(struct page *page) > { > - return split_huge_page_to_list(page, NULL); > + return split_huge_page_to_list_to_order(page, NULL, 0); > } > void deferred_split_folio(struct folio *folio); > > @@ -422,7 +423,8 @@ can_split_folio(struct folio *folio, int *pextra_pins) > return false; > } > static inline int > -split_huge_page_to_list(struct page *page, struct list_head *list) > +split_huge_page_to_list_to_order(struct page *page, struct list_head *list, > + unsigned int new_order) > { > return 0; > } > @@ -519,17 +521,20 @@ static inline bool thp_migration_supported(void) > } > #endif /* CONFIG_TRANSPARENT_HUGEPAGE */ > > -static inline int split_folio_to_list(struct folio *folio, > - struct list_head *list) > +static inline int split_folio_to_list_to_order(struct folio *folio, > + struct list_head *list, int new_order) > { > - return split_huge_page_to_list(&folio->page, list); > + return split_huge_page_to_list_to_order(&folio->page, list, new_order); > } > > -static inline int split_folio(struct folio *folio) > +static inline int split_folio_to_order(struct folio *folio, int new_order) > { > - return split_folio_to_list(folio, NULL); > + return split_folio_to_list_to_order(folio, NULL, new_order); > } > > +#define split_folio_to_list(f, l) split_folio_to_list_to_order(f, l, 0) > +#define split_folio(f) split_folio_to_order(f, 0) > + > /* > * archs that select ARCH_WANTS_THP_SWAP but don't support THP_SWP due to > * limitations in the implementation like arm64 MTE can override this to > diff --git a/mm/huge_memory.c b/mm/huge_memory.c > index ad7133c97428..d0e555a8ea98 100644 > --- a/mm/huge_memory.c > +++ b/mm/huge_memory.c > @@ -2718,11 +2718,14 @@ void vma_adjust_trans_huge(struct vm_area_struct *vma, > > static void unmap_folio(struct folio *folio) > { > - enum ttu_flags ttu_flags = TTU_RMAP_LOCKED | TTU_SPLIT_HUGE_PMD | > - TTU_SYNC | TTU_BATCH_FLUSH; > + enum ttu_flags ttu_flags = TTU_RMAP_LOCKED | TTU_SYNC | > + TTU_BATCH_FLUSH; > > VM_BUG_ON_FOLIO(!folio_test_large(folio), folio); > > + if (folio_test_pmd_mappable(folio)) > + ttu_flags |= TTU_SPLIT_HUGE_PMD; Should we split this change out? I think it makes sense independent of this series? > + > /* > * Anon pages need migration entries to preserve them, but file > * pages can simply be left unmapped, then faulted back on demand. > @@ -2756,7 +2759,6 @@ static void lru_add_page_tail(struct page *head, struct page *tail, > struct lruvec *lruvec, struct list_head *list) > { > VM_BUG_ON_PAGE(!PageHead(head), head); > - VM_BUG_ON_PAGE(PageCompound(tail), head); > VM_BUG_ON_PAGE(PageLRU(tail), head); > lockdep_assert_held(&lruvec->lru_lock); > > @@ -2777,7 +2779,8 @@ static void lru_add_page_tail(struct page *head, struct page *tail, > } > > static void __split_huge_page_tail(struct folio *folio, int tail, > - struct lruvec *lruvec, struct list_head *list) > + struct lruvec *lruvec, struct list_head *list, > + unsigned int new_order) > { > struct page *head = &folio->page; > struct page *page_tail = head + tail; > @@ -2847,10 +2850,15 @@ static void __split_huge_page_tail(struct folio *folio, int tail, > * which needs correct compound_head(). > */ > clear_compound_head(page_tail); > + if (new_order) { > + prep_compound_page(page_tail, new_order); > + folio_prep_large_rmappable(page_folio(page_tail)); > + } > > /* Finally unfreeze refcount. Additional reference from page cache. */ > - page_ref_unfreeze(page_tail, 1 + (!folio_test_anon(folio) || > - folio_test_swapcache(folio))); > + page_ref_unfreeze(page_tail, > + 1 + ((!folio_test_anon(folio) || folio_test_swapcache(folio)) ? > + folio_nr_pages(page_folio(page_tail)) : 0)); > > if (folio_test_young(folio)) > folio_set_young(new_folio); > @@ -2868,7 +2876,7 @@ static void __split_huge_page_tail(struct folio *folio, int tail, > } > > static void __split_huge_page(struct page *page, struct list_head *list, > - pgoff_t end) > + pgoff_t end, unsigned int new_order) > { > struct folio *folio = page_folio(page); > struct page *head = &folio->page; > @@ -2877,10 +2885,11 @@ static void __split_huge_page(struct page *page, struct list_head *list, > unsigned long offset = 0; > unsigned int nr = thp_nr_pages(head); > int i, nr_dropped = 0; > + unsigned int new_nr = 1 << new_order; > int order = folio_order(folio); > > /* complete memcg works before add pages to LRU */ > - split_page_memcg(head, order, 0); > + split_page_memcg(head, order, new_order); > > if (folio_test_anon(folio) && folio_test_swapcache(folio)) { > offset = swp_offset(folio->swap); > @@ -2893,8 +2902,8 @@ static void __split_huge_page(struct page *page, struct list_head *list, > > ClearPageHasHWPoisoned(head); > > - for (i = nr - 1; i >= 1; i--) { > - __split_huge_page_tail(folio, i, lruvec, list); > + for (i = nr - new_nr; i >= new_nr; i -= new_nr) { > + __split_huge_page_tail(folio, i, lruvec, list, new_order); > /* Some pages can be beyond EOF: drop them from page cache */ > if (head[i].index >= end) { > struct folio *tail = page_folio(head + i); > @@ -2910,29 +2919,41 @@ static void __split_huge_page(struct page *page, struct list_head *list, > __xa_store(&head->mapping->i_pages, head[i].index, > head + i, 0); > } else if (swap_cache) { > + /* > + * split anonymous THPs (including swapped out ones) to > + * non-zero order not supported > + */ > + VM_WARN_ONCE(new_order, > + "Split swap-cached anon folio to non-0 order not supported"); Why isn't it supported? Even if it's not supported, is this level the right place to enforce these kinds of policy decisions? I wonder if we should be leaving that to the higher level to decide? Thanks, Ryan > __xa_store(&swap_cache->i_pages, offset + i, > head + i, 0); > } > } > > - ClearPageCompound(head); > + if (!new_order) > + ClearPageCompound(head); > + else { > + struct folio *new_folio = (struct folio *)head; > + > + folio_set_order(new_folio, new_order); > + } > unlock_page_lruvec(lruvec); > /* Caller disabled irqs, so they are still disabled here */ > > - split_page_owner(head, order, 0); > + split_page_owner(head, order, new_order); > > /* See comment in __split_huge_page_tail() */ > if (PageAnon(head)) { > /* Additional pin to swap cache */ > if (PageSwapCache(head)) { > - page_ref_add(head, 2); > + page_ref_add(head, 1 + new_nr); > xa_unlock(&swap_cache->i_pages); > } else { > page_ref_inc(head); > } > } else { > /* Additional pin to page cache */ > - page_ref_add(head, 2); > + page_ref_add(head, 1 + new_nr); > xa_unlock(&head->mapping->i_pages); > } > local_irq_enable(); > @@ -2944,7 +2965,15 @@ static void __split_huge_page(struct page *page, struct list_head *list, > if (folio_test_swapcache(folio)) > split_swap_cluster(folio->swap); > > - for (i = 0; i < nr; i++) { > + /* > + * set page to its compound_head when split to non order-0 pages, so > + * we can skip unlocking it below, since PG_locked is transferred to > + * the compound_head of the page and the caller will unlock it. > + */ > + if (new_order) > + page = compound_head(page); > + > + for (i = 0; i < nr; i += new_nr) { > struct page *subpage = head + i; > if (subpage == page) > continue; > @@ -2978,29 +3007,35 @@ bool can_split_folio(struct folio *folio, int *pextra_pins) > } > > /* > - * This function splits huge page into normal pages. @page can point to any > - * subpage of huge page to split. Split doesn't change the position of @page. > + * This function splits huge page into pages in @new_order. @page can point to > + * any subpage of huge page to split. Split doesn't change the position of > + * @page. > + * > + * NOTE: order-1 folio is not supported because _deferred_list, which is used > + * by partially mapped folios, is stored in subpage 2 and an order-1 folio > + * only has subpage 0 and 1. > * > * Only caller must hold pin on the @page, otherwise split fails with -EBUSY. > * The huge page must be locked. > * > * If @list is null, tail pages will be added to LRU list, otherwise, to @list. > * > - * Both head page and tail pages will inherit mapping, flags, and so on from > - * the hugepage. > + * Pages in new_order will inherit mapping, flags, and so on from the hugepage. > * > - * GUP pin and PG_locked transferred to @page. Rest subpages can be freed if > - * they are not mapped. > + * GUP pin and PG_locked transferred to @page or the compound page @page belongs > + * to. Rest subpages can be freed if they are not mapped. > * > * Returns 0 if the hugepage is split successfully. > * Returns -EBUSY if the page is pinned or if anon_vma disappeared from under > * us. > */ > -int split_huge_page_to_list(struct page *page, struct list_head *list) > +int split_huge_page_to_list_to_order(struct page *page, struct list_head *list, > + unsigned int new_order) > { > struct folio *folio = page_folio(page); > struct deferred_split *ds_queue = get_deferred_split_queue(folio); > - XA_STATE(xas, &folio->mapping->i_pages, folio->index); > + /* reset xarray order to new order after split */ > + XA_STATE_ORDER(xas, &folio->mapping->i_pages, folio->index, new_order); > struct anon_vma *anon_vma = NULL; > struct address_space *mapping = NULL; > int extra_pins, ret; > @@ -3010,6 +3045,26 @@ int split_huge_page_to_list(struct page *page, struct list_head *list) > VM_BUG_ON_FOLIO(!folio_test_locked(folio), folio); > VM_BUG_ON_FOLIO(!folio_test_large(folio), folio); > > + /* Cannot split THP to order-1 (no order-1 THPs) */ > + if (new_order == 1) { > + VM_WARN_ONCE(1, "Cannot split to order-1 folio"); > + return -EINVAL; > + } > + > + if (new_order) { > + /* Split shmem folio to non-zero order not supported */ > + if (shmem_mapping(folio->mapping)) { > + VM_WARN_ONCE(1, "Split shmem folio to non-0 order not support"); > + return -EINVAL; > + } > + /* No split if the file system does not support large folio */ > + if (!mapping_large_folio_support(folio->mapping)) { > + VM_WARN_ONCE(1, "Split file folio to non-0 order not support"); > + return -EINVAL; > + } > + } > + > + > is_hzp = is_huge_zero_page(&folio->page); > if (is_hzp) { > pr_warn_ratelimited("Called split_huge_page for huge zero page\n"); > @@ -3105,14 +3160,21 @@ int split_huge_page_to_list(struct page *page, struct list_head *list) > if (folio_ref_freeze(folio, 1 + extra_pins)) { > if (!list_empty(&folio->_deferred_list)) { > ds_queue->split_queue_len--; > - list_del(&folio->_deferred_list); > + /* > + * Reinitialize page_deferred_list after removing the > + * page from the split_queue, otherwise a subsequent > + * split will see list corruption when checking the > + * page_deferred_list. > + */ > + list_del_init(&folio->_deferred_list); > } > spin_unlock(&ds_queue->split_queue_lock); > if (mapping) { > int nr = folio_nr_pages(folio); > > xas_split(&xas, folio, folio_order(folio)); > - if (folio_test_pmd_mappable(folio)) { > + if (folio_test_pmd_mappable(folio) && > + new_order < HPAGE_PMD_ORDER) { > if (folio_test_swapbacked(folio)) { > __lruvec_stat_mod_folio(folio, > NR_SHMEM_THPS, -nr); > @@ -3124,7 +3186,7 @@ int split_huge_page_to_list(struct page *page, struct list_head *list) > } > } > > - __split_huge_page(page, list, end); > + __split_huge_page(page, list, end, new_order); > ret = 0; > } else { > spin_unlock(&ds_queue->split_queue_lock);
On 13/02/2024 22:31, Zi Yan wrote: > On 13 Feb 2024, at 17:21, David Hildenbrand wrote: > >> On 13.02.24 22:55, Zi Yan wrote: >>> From: Zi Yan <ziy@nvidia.com> >>> >>> Hi all, >>> >>> File folio supports any order and multi-size THP is upstreamed[1], so both >>> file and anonymous folios can be >0 order. Currently, split_huge_page() >>> only splits a huge page to order-0 pages, but splitting to orders higher than >>> 0 is going to better utilize large folios. In addition, Large Block >>> Sizes in XFS support would benefit from it[2]. This patchset adds support for >>> splitting a large folio to any lower order folios and uses it during file >>> folio truncate operations. >>> >>> For Patch 6, Hugh did not like my approach to minimize the number of >>> folios for truncate[3]. I would like to get more feedback, especially >>> from FS people, on it to decide whether to keep it or not. >> >> I'm curious, would it make sense to exclude the "more" controversial parts (i.e., patch #6) for now, and focus on the XFS use case only? > > Sure. Patch 6 was there to make use of split_huge_page_to_list_to_order(). > Now we have multi-size THP and XFS use cases, it can be dropped. What are your plans for how to determine when to split THP and to what order? I don't see anything in this series that would split anon THP to non-zero order? We have talked about using hints from user space in the past (e.g. mremap, munmap, madvise, etc). But chrome has a use case where it temporarily mprotects a single (4K) page as part of garbage collection (IIRC). If you eagerly split on that hint, you will have lost the benefits of the large folio when it later mprotects back to the original setting. I guess David will suggest this would be a good use case for the khugepaged-lite machanism we have been talking about. I dunno - it seems wasteful to split then collapse again. Or perhaps you're considering doing something clever in deferred split? > > -- > Best Regards, > Yan, Zi
On 14.02.24 11:50, Ryan Roberts wrote: > On 13/02/2024 22:31, Zi Yan wrote: >> On 13 Feb 2024, at 17:21, David Hildenbrand wrote: >> >>> On 13.02.24 22:55, Zi Yan wrote: >>>> From: Zi Yan <ziy@nvidia.com> >>>> >>>> Hi all, >>>> >>>> File folio supports any order and multi-size THP is upstreamed[1], so both >>>> file and anonymous folios can be >0 order. Currently, split_huge_page() >>>> only splits a huge page to order-0 pages, but splitting to orders higher than >>>> 0 is going to better utilize large folios. In addition, Large Block >>>> Sizes in XFS support would benefit from it[2]. This patchset adds support for >>>> splitting a large folio to any lower order folios and uses it during file >>>> folio truncate operations. >>>> >>>> For Patch 6, Hugh did not like my approach to minimize the number of >>>> folios for truncate[3]. I would like to get more feedback, especially >>>> from FS people, on it to decide whether to keep it or not. >>> >>> I'm curious, would it make sense to exclude the "more" controversial parts (i.e., patch #6) for now, and focus on the XFS use case only? >> >> Sure. Patch 6 was there to make use of split_huge_page_to_list_to_order(). >> Now we have multi-size THP and XFS use cases, it can be dropped. > > What are your plans for how to determine when to split THP and to what order? I > don't see anything in this series that would split anon THP to non-zero order? > > We have talked about using hints from user space in the past (e.g. mremap, > munmap, madvise, etc). But chrome has a use case where it temporarily mprotects > a single (4K) page as part of garbage collection (IIRC). If you eagerly split on > that hint, you will have lost the benefits of the large folio when it later > mprotects back to the original setting. Not only that, splitting will make some of these operations more expensive, possibly with no actual benefit. > > I guess David will suggest this would be a good use case for the khugepaged-lite > machanism we have been talking about. I dunno - it seems wasteful to split then > collapse again. I agree. mprotect() and even madvise(), ... might not be good candidates for splitting. mremap() likely is, if the folio is mapped exclusively. MADV_DONTNEED/munmap()/mlock() might be good candidates (again, if mapped exclusively). This will need a lot of thought I'm afraid (as you say, deferred splitting is another example).
On 14 Feb 2024, at 4:12, David Hildenbrand wrote: > On 13.02.24 22:55, Zi Yan wrote: >> From: Zi Yan <ziy@nvidia.com> >> >> We do not have non power of two pages, using nr is error prone if nr >> is not power-of-two. Use page order instead. >> >> Signed-off-by: Zi Yan <ziy@nvidia.com> >> --- >> include/linux/memcontrol.h | 4 ++-- >> mm/huge_memory.c | 3 ++- >> mm/memcontrol.c | 3 ++- >> mm/page_alloc.c | 4 ++-- >> 4 files changed, 8 insertions(+), 6 deletions(-) >> >> diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h >> index 4e4caeaea404..173bbb53c1ec 100644 >> --- a/include/linux/memcontrol.h >> +++ b/include/linux/memcontrol.h >> @@ -1163,7 +1163,7 @@ static inline void memcg_memory_event_mm(struct mm_struct *mm, >> rcu_read_unlock(); >> } >> -void split_page_memcg(struct page *head, unsigned int nr); >> +void split_page_memcg(struct page *head, int order); >> unsigned long mem_cgroup_soft_limit_reclaim(pg_data_t *pgdat, int order, >> gfp_t gfp_mask, >> @@ -1621,7 +1621,7 @@ void count_memcg_event_mm(struct mm_struct *mm, enum vm_event_item idx) >> { >> } >> -static inline void split_page_memcg(struct page *head, unsigned int nr) >> +static inline void split_page_memcg(struct page *head, int order) >> { >> } >> diff --git a/mm/huge_memory.c b/mm/huge_memory.c >> index 016e20bd813e..0cd5fba0923c 100644 >> --- a/mm/huge_memory.c >> +++ b/mm/huge_memory.c >> @@ -2877,9 +2877,10 @@ static void __split_huge_page(struct page *page, struct list_head *list, >> unsigned long offset = 0; >> unsigned int nr = thp_nr_pages(head); >> int i, nr_dropped = 0; >> + int order = folio_order(folio); > > You could calculate "nr" from "order" here, removing the usage of thp_nr_pages(). Sure. > >> /* complete memcg works before add pages to LRU */ >> - split_page_memcg(head, nr); >> + split_page_memcg(head, order); >> if (folio_test_anon(folio) && folio_test_swapcache(folio)) { > > Acked-by: David Hildenbrand <david@redhat.com> Thanks. -- Best Regards, Yan, Zi
On 14 Feb 2024, at 5:38, Ryan Roberts wrote: > On 13/02/2024 21:55, Zi Yan wrote: >> From: Zi Yan <ziy@nvidia.com> >> >> To split a THP to any lower order (except order-1) pages, we need to >> reform THPs on subpages at given order and add page refcount based on the >> new page order. Also we need to reinitialize page_deferred_list after >> removing the page from the split_queue, otherwise a subsequent split will >> see list corruption when checking the page_deferred_list again. >> >> It has many uses, like minimizing the number of pages after >> truncating a huge pagecache page. For anonymous THPs, we can only split >> them to order-0 like before until we add support for any size anonymous >> THPs. > > multi-size THP is now upstream. Not sure if this comment still makes sense. Will change it to reflect the fact that multi-size THP is already upstream. > Still its not completely clear to me how you would integrate this new machinery > and decide what non-zero order to split anon THP to? Originally, it was developed along with my 1GB THP support. So it was intended to split order-18 to order-9. But for now, like you and David said in the cover letter email thread, we might not want to use it for anonymous large folios until we find a necessary use case. >> >> Order-1 folio is not supported because _deferred_list, which is used by >> partially mapped folios, is stored in subpage 2 and an order-1 folio only >> has subpage 0 and 1. >> >> Signed-off-by: Zi Yan <ziy@nvidia.com> >> --- >> include/linux/huge_mm.h | 21 +++++--- >> mm/huge_memory.c | 114 +++++++++++++++++++++++++++++++--------- >> 2 files changed, 101 insertions(+), 34 deletions(-) >> >> diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h >> index 5adb86af35fc..de0c89105076 100644 >> --- a/include/linux/huge_mm.h >> +++ b/include/linux/huge_mm.h >> @@ -265,10 +265,11 @@ unsigned long thp_get_unmapped_area(struct file *filp, unsigned long addr, >> >> void 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); >> +int split_huge_page_to_list_to_order(struct page *page, struct list_head *list, >> + unsigned int new_order); >> static inline int split_huge_page(struct page *page) >> { >> - return split_huge_page_to_list(page, NULL); >> + return split_huge_page_to_list_to_order(page, NULL, 0); >> } >> void deferred_split_folio(struct folio *folio); >> >> @@ -422,7 +423,8 @@ can_split_folio(struct folio *folio, int *pextra_pins) >> return false; >> } >> static inline int >> -split_huge_page_to_list(struct page *page, struct list_head *list) >> +split_huge_page_to_list_to_order(struct page *page, struct list_head *list, >> + unsigned int new_order) >> { >> return 0; >> } >> @@ -519,17 +521,20 @@ static inline bool thp_migration_supported(void) >> } >> #endif /* CONFIG_TRANSPARENT_HUGEPAGE */ >> >> -static inline int split_folio_to_list(struct folio *folio, >> - struct list_head *list) >> +static inline int split_folio_to_list_to_order(struct folio *folio, >> + struct list_head *list, int new_order) >> { >> - return split_huge_page_to_list(&folio->page, list); >> + return split_huge_page_to_list_to_order(&folio->page, list, new_order); >> } >> >> -static inline int split_folio(struct folio *folio) >> +static inline int split_folio_to_order(struct folio *folio, int new_order) >> { >> - return split_folio_to_list(folio, NULL); >> + return split_folio_to_list_to_order(folio, NULL, new_order); >> } >> >> +#define split_folio_to_list(f, l) split_folio_to_list_to_order(f, l, 0) >> +#define split_folio(f) split_folio_to_order(f, 0) >> + >> /* >> * archs that select ARCH_WANTS_THP_SWAP but don't support THP_SWP due to >> * limitations in the implementation like arm64 MTE can override this to >> diff --git a/mm/huge_memory.c b/mm/huge_memory.c >> index ad7133c97428..d0e555a8ea98 100644 >> --- a/mm/huge_memory.c >> +++ b/mm/huge_memory.c >> @@ -2718,11 +2718,14 @@ void vma_adjust_trans_huge(struct vm_area_struct *vma, >> >> static void unmap_folio(struct folio *folio) >> { >> - enum ttu_flags ttu_flags = TTU_RMAP_LOCKED | TTU_SPLIT_HUGE_PMD | >> - TTU_SYNC | TTU_BATCH_FLUSH; >> + enum ttu_flags ttu_flags = TTU_RMAP_LOCKED | TTU_SYNC | >> + TTU_BATCH_FLUSH; >> >> VM_BUG_ON_FOLIO(!folio_test_large(folio), folio); >> >> + if (folio_test_pmd_mappable(folio)) >> + ttu_flags |= TTU_SPLIT_HUGE_PMD; > > Should we split this change out? I think it makes sense independent of this series? > Sure. Since multi-size THP is upstream, this avoid unnecessary code path if the THP is not PMD-mapped. >> + >> /* >> * Anon pages need migration entries to preserve them, but file >> * pages can simply be left unmapped, then faulted back on demand. >> @@ -2756,7 +2759,6 @@ static void lru_add_page_tail(struct page *head, struct page *tail, >> struct lruvec *lruvec, struct list_head *list) >> { >> VM_BUG_ON_PAGE(!PageHead(head), head); >> - VM_BUG_ON_PAGE(PageCompound(tail), head); >> VM_BUG_ON_PAGE(PageLRU(tail), head); >> lockdep_assert_held(&lruvec->lru_lock); >> >> @@ -2777,7 +2779,8 @@ static void lru_add_page_tail(struct page *head, struct page *tail, >> } >> >> static void __split_huge_page_tail(struct folio *folio, int tail, >> - struct lruvec *lruvec, struct list_head *list) >> + struct lruvec *lruvec, struct list_head *list, >> + unsigned int new_order) >> { >> struct page *head = &folio->page; >> struct page *page_tail = head + tail; >> @@ -2847,10 +2850,15 @@ static void __split_huge_page_tail(struct folio *folio, int tail, >> * which needs correct compound_head(). >> */ >> clear_compound_head(page_tail); >> + if (new_order) { >> + prep_compound_page(page_tail, new_order); >> + folio_prep_large_rmappable(page_folio(page_tail)); >> + } >> >> /* Finally unfreeze refcount. Additional reference from page cache. */ >> - page_ref_unfreeze(page_tail, 1 + (!folio_test_anon(folio) || >> - folio_test_swapcache(folio))); >> + page_ref_unfreeze(page_tail, >> + 1 + ((!folio_test_anon(folio) || folio_test_swapcache(folio)) ? >> + folio_nr_pages(page_folio(page_tail)) : 0)); >> >> if (folio_test_young(folio)) >> folio_set_young(new_folio); >> @@ -2868,7 +2876,7 @@ static void __split_huge_page_tail(struct folio *folio, int tail, >> } >> >> static void __split_huge_page(struct page *page, struct list_head *list, >> - pgoff_t end) >> + pgoff_t end, unsigned int new_order) >> { >> struct folio *folio = page_folio(page); >> struct page *head = &folio->page; >> @@ -2877,10 +2885,11 @@ static void __split_huge_page(struct page *page, struct list_head *list, >> unsigned long offset = 0; >> unsigned int nr = thp_nr_pages(head); >> int i, nr_dropped = 0; >> + unsigned int new_nr = 1 << new_order; >> int order = folio_order(folio); >> >> /* complete memcg works before add pages to LRU */ >> - split_page_memcg(head, order, 0); >> + split_page_memcg(head, order, new_order); >> >> if (folio_test_anon(folio) && folio_test_swapcache(folio)) { >> offset = swp_offset(folio->swap); >> @@ -2893,8 +2902,8 @@ static void __split_huge_page(struct page *page, struct list_head *list, >> >> ClearPageHasHWPoisoned(head); >> >> - for (i = nr - 1; i >= 1; i--) { >> - __split_huge_page_tail(folio, i, lruvec, list); >> + for (i = nr - new_nr; i >= new_nr; i -= new_nr) { >> + __split_huge_page_tail(folio, i, lruvec, list, new_order); >> /* Some pages can be beyond EOF: drop them from page cache */ >> if (head[i].index >= end) { >> struct folio *tail = page_folio(head + i); >> @@ -2910,29 +2919,41 @@ static void __split_huge_page(struct page *page, struct list_head *list, >> __xa_store(&head->mapping->i_pages, head[i].index, >> head + i, 0); >> } else if (swap_cache) { >> + /* >> + * split anonymous THPs (including swapped out ones) to >> + * non-zero order not supported >> + */ >> + VM_WARN_ONCE(new_order, >> + "Split swap-cached anon folio to non-0 order not supported"); > > Why isn't it supported? Even if it's not supported, is this level the right > place to enforce these kinds of policy decisions? I wonder if we should be > leaving that to the higher level to decide? Is the swap-out small-size THP without splitting merged? This needs that patchset. You are right that a warning here is not appropriate. I will fail the splitting if the folio is swapcached and going to be split into >0 order. >> __xa_store(&swap_cache->i_pages, offset + i, >> head + i, 0); >> } >> } >> -- Best Regards, Yan, Zi
On 14/02/2024 16:11, Zi Yan wrote: > On 14 Feb 2024, at 5:38, Ryan Roberts wrote: > >> On 13/02/2024 21:55, Zi Yan wrote: >>> From: Zi Yan <ziy@nvidia.com> >>> >>> To split a THP to any lower order (except order-1) pages, we need to >>> reform THPs on subpages at given order and add page refcount based on the >>> new page order. Also we need to reinitialize page_deferred_list after >>> removing the page from the split_queue, otherwise a subsequent split will >>> see list corruption when checking the page_deferred_list again. >>> >>> It has many uses, like minimizing the number of pages after >>> truncating a huge pagecache page. For anonymous THPs, we can only split >>> them to order-0 like before until we add support for any size anonymous >>> THPs. >> >> multi-size THP is now upstream. Not sure if this comment still makes sense. > Will change it to reflect the fact that multi-size THP is already upstream. > >> Still its not completely clear to me how you would integrate this new machinery >> and decide what non-zero order to split anon THP to? > > Originally, it was developed along with my 1GB THP support. So it was intended > to split order-18 to order-9. But for now, like you and David said in the cover > letter email thread, we might not want to use it for anonymous large folios > until we find a necessary use case. > >>> >>> Order-1 folio is not supported because _deferred_list, which is used by >>> partially mapped folios, is stored in subpage 2 and an order-1 folio only >>> has subpage 0 and 1. >>> >>> Signed-off-by: Zi Yan <ziy@nvidia.com> >>> --- >>> include/linux/huge_mm.h | 21 +++++--- >>> mm/huge_memory.c | 114 +++++++++++++++++++++++++++++++--------- >>> 2 files changed, 101 insertions(+), 34 deletions(-) >>> >>> diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h >>> index 5adb86af35fc..de0c89105076 100644 >>> --- a/include/linux/huge_mm.h >>> +++ b/include/linux/huge_mm.h >>> @@ -265,10 +265,11 @@ unsigned long thp_get_unmapped_area(struct file *filp, unsigned long addr, >>> >>> void 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); >>> +int split_huge_page_to_list_to_order(struct page *page, struct list_head *list, >>> + unsigned int new_order); >>> static inline int split_huge_page(struct page *page) >>> { >>> - return split_huge_page_to_list(page, NULL); >>> + return split_huge_page_to_list_to_order(page, NULL, 0); >>> } >>> void deferred_split_folio(struct folio *folio); >>> >>> @@ -422,7 +423,8 @@ can_split_folio(struct folio *folio, int *pextra_pins) >>> return false; >>> } >>> static inline int >>> -split_huge_page_to_list(struct page *page, struct list_head *list) >>> +split_huge_page_to_list_to_order(struct page *page, struct list_head *list, >>> + unsigned int new_order) >>> { >>> return 0; >>> } >>> @@ -519,17 +521,20 @@ static inline bool thp_migration_supported(void) >>> } >>> #endif /* CONFIG_TRANSPARENT_HUGEPAGE */ >>> >>> -static inline int split_folio_to_list(struct folio *folio, >>> - struct list_head *list) >>> +static inline int split_folio_to_list_to_order(struct folio *folio, >>> + struct list_head *list, int new_order) >>> { >>> - return split_huge_page_to_list(&folio->page, list); >>> + return split_huge_page_to_list_to_order(&folio->page, list, new_order); >>> } >>> >>> -static inline int split_folio(struct folio *folio) >>> +static inline int split_folio_to_order(struct folio *folio, int new_order) >>> { >>> - return split_folio_to_list(folio, NULL); >>> + return split_folio_to_list_to_order(folio, NULL, new_order); >>> } >>> >>> +#define split_folio_to_list(f, l) split_folio_to_list_to_order(f, l, 0) >>> +#define split_folio(f) split_folio_to_order(f, 0) >>> + >>> /* >>> * archs that select ARCH_WANTS_THP_SWAP but don't support THP_SWP due to >>> * limitations in the implementation like arm64 MTE can override this to >>> diff --git a/mm/huge_memory.c b/mm/huge_memory.c >>> index ad7133c97428..d0e555a8ea98 100644 >>> --- a/mm/huge_memory.c >>> +++ b/mm/huge_memory.c >>> @@ -2718,11 +2718,14 @@ void vma_adjust_trans_huge(struct vm_area_struct *vma, >>> >>> static void unmap_folio(struct folio *folio) >>> { >>> - enum ttu_flags ttu_flags = TTU_RMAP_LOCKED | TTU_SPLIT_HUGE_PMD | >>> - TTU_SYNC | TTU_BATCH_FLUSH; >>> + enum ttu_flags ttu_flags = TTU_RMAP_LOCKED | TTU_SYNC | >>> + TTU_BATCH_FLUSH; >>> >>> VM_BUG_ON_FOLIO(!folio_test_large(folio), folio); >>> >>> + if (folio_test_pmd_mappable(folio)) >>> + ttu_flags |= TTU_SPLIT_HUGE_PMD; >> >> Should we split this change out? I think it makes sense independent of this series? >> > > Sure. Since multi-size THP is upstream, this avoid unnecessary code path if > the THP is not PMD-mapped. > >>> + >>> /* >>> * Anon pages need migration entries to preserve them, but file >>> * pages can simply be left unmapped, then faulted back on demand. >>> @@ -2756,7 +2759,6 @@ static void lru_add_page_tail(struct page *head, struct page *tail, >>> struct lruvec *lruvec, struct list_head *list) >>> { >>> VM_BUG_ON_PAGE(!PageHead(head), head); >>> - VM_BUG_ON_PAGE(PageCompound(tail), head); >>> VM_BUG_ON_PAGE(PageLRU(tail), head); >>> lockdep_assert_held(&lruvec->lru_lock); >>> >>> @@ -2777,7 +2779,8 @@ static void lru_add_page_tail(struct page *head, struct page *tail, >>> } >>> >>> static void __split_huge_page_tail(struct folio *folio, int tail, >>> - struct lruvec *lruvec, struct list_head *list) >>> + struct lruvec *lruvec, struct list_head *list, >>> + unsigned int new_order) >>> { >>> struct page *head = &folio->page; >>> struct page *page_tail = head + tail; >>> @@ -2847,10 +2850,15 @@ static void __split_huge_page_tail(struct folio *folio, int tail, >>> * which needs correct compound_head(). >>> */ >>> clear_compound_head(page_tail); >>> + if (new_order) { >>> + prep_compound_page(page_tail, new_order); >>> + folio_prep_large_rmappable(page_folio(page_tail)); >>> + } >>> >>> /* Finally unfreeze refcount. Additional reference from page cache. */ >>> - page_ref_unfreeze(page_tail, 1 + (!folio_test_anon(folio) || >>> - folio_test_swapcache(folio))); >>> + page_ref_unfreeze(page_tail, >>> + 1 + ((!folio_test_anon(folio) || folio_test_swapcache(folio)) ? >>> + folio_nr_pages(page_folio(page_tail)) : 0)); >>> >>> if (folio_test_young(folio)) >>> folio_set_young(new_folio); >>> @@ -2868,7 +2876,7 @@ static void __split_huge_page_tail(struct folio *folio, int tail, >>> } >>> >>> static void __split_huge_page(struct page *page, struct list_head *list, >>> - pgoff_t end) >>> + pgoff_t end, unsigned int new_order) >>> { >>> struct folio *folio = page_folio(page); >>> struct page *head = &folio->page; >>> @@ -2877,10 +2885,11 @@ static void __split_huge_page(struct page *page, struct list_head *list, >>> unsigned long offset = 0; >>> unsigned int nr = thp_nr_pages(head); >>> int i, nr_dropped = 0; >>> + unsigned int new_nr = 1 << new_order; >>> int order = folio_order(folio); >>> >>> /* complete memcg works before add pages to LRU */ >>> - split_page_memcg(head, order, 0); >>> + split_page_memcg(head, order, new_order); >>> >>> if (folio_test_anon(folio) && folio_test_swapcache(folio)) { >>> offset = swp_offset(folio->swap); >>> @@ -2893,8 +2902,8 @@ static void __split_huge_page(struct page *page, struct list_head *list, >>> >>> ClearPageHasHWPoisoned(head); >>> >>> - for (i = nr - 1; i >= 1; i--) { >>> - __split_huge_page_tail(folio, i, lruvec, list); >>> + for (i = nr - new_nr; i >= new_nr; i -= new_nr) { >>> + __split_huge_page_tail(folio, i, lruvec, list, new_order); >>> /* Some pages can be beyond EOF: drop them from page cache */ >>> if (head[i].index >= end) { >>> struct folio *tail = page_folio(head + i); >>> @@ -2910,29 +2919,41 @@ static void __split_huge_page(struct page *page, struct list_head *list, >>> __xa_store(&head->mapping->i_pages, head[i].index, >>> head + i, 0); >>> } else if (swap_cache) { >>> + /* >>> + * split anonymous THPs (including swapped out ones) to >>> + * non-zero order not supported >>> + */ >>> + VM_WARN_ONCE(new_order, >>> + "Split swap-cached anon folio to non-0 order not supported"); >> >> Why isn't it supported? Even if it's not supported, is this level the right >> place to enforce these kinds of policy decisions? I wonder if we should be >> leaving that to the higher level to decide? > > Is the swap-out small-size THP without splitting merged? This needs that patchset. No not yet. I have to respin it. Its on my todo list. I'm not sure I understand the dependency though? > You are right that a warning here is not appropriate. I will fail the splitting > if the folio is swapcached and going to be split into >0 order. > >>> __xa_store(&swap_cache->i_pages, offset + i, >>> head + i, 0); >>> } >>> } >>> > > > -- > Best Regards, > Yan, Zi
On 14 Feb 2024, at 11:22, Ryan Roberts wrote: > On 14/02/2024 16:11, Zi Yan wrote: >> On 14 Feb 2024, at 5:38, Ryan Roberts wrote: >> >>> On 13/02/2024 21:55, Zi Yan wrote: >>>> From: Zi Yan <ziy@nvidia.com> >>>> >>>> To split a THP to any lower order (except order-1) pages, we need to >>>> reform THPs on subpages at given order and add page refcount based on the >>>> new page order. Also we need to reinitialize page_deferred_list after >>>> removing the page from the split_queue, otherwise a subsequent split will >>>> see list corruption when checking the page_deferred_list again. >>>> >>>> It has many uses, like minimizing the number of pages after >>>> truncating a huge pagecache page. For anonymous THPs, we can only split >>>> them to order-0 like before until we add support for any size anonymous >>>> THPs. >>> >>> multi-size THP is now upstream. Not sure if this comment still makes sense. >> Will change it to reflect the fact that multi-size THP is already upstream. >> >>> Still its not completely clear to me how you would integrate this new machinery >>> and decide what non-zero order to split anon THP to? >> >> Originally, it was developed along with my 1GB THP support. So it was intended >> to split order-18 to order-9. But for now, like you and David said in the cover >> letter email thread, we might not want to use it for anonymous large folios >> until we find a necessary use case. >> >>>> >>>> Order-1 folio is not supported because _deferred_list, which is used by >>>> partially mapped folios, is stored in subpage 2 and an order-1 folio only >>>> has subpage 0 and 1. >>>> >>>> Signed-off-by: Zi Yan <ziy@nvidia.com> >>>> --- >>>> include/linux/huge_mm.h | 21 +++++--- >>>> mm/huge_memory.c | 114 +++++++++++++++++++++++++++++++--------- >>>> 2 files changed, 101 insertions(+), 34 deletions(-) >>>> >>>> diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h >>>> index 5adb86af35fc..de0c89105076 100644 >>>> --- a/include/linux/huge_mm.h >>>> +++ b/include/linux/huge_mm.h >>>> @@ -265,10 +265,11 @@ unsigned long thp_get_unmapped_area(struct file *filp, unsigned long addr, >>>> >>>> void 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); >>>> +int split_huge_page_to_list_to_order(struct page *page, struct list_head *list, >>>> + unsigned int new_order); >>>> static inline int split_huge_page(struct page *page) >>>> { >>>> - return split_huge_page_to_list(page, NULL); >>>> + return split_huge_page_to_list_to_order(page, NULL, 0); >>>> } >>>> void deferred_split_folio(struct folio *folio); >>>> >>>> @@ -422,7 +423,8 @@ can_split_folio(struct folio *folio, int *pextra_pins) >>>> return false; >>>> } >>>> static inline int >>>> -split_huge_page_to_list(struct page *page, struct list_head *list) >>>> +split_huge_page_to_list_to_order(struct page *page, struct list_head *list, >>>> + unsigned int new_order) >>>> { >>>> return 0; >>>> } >>>> @@ -519,17 +521,20 @@ static inline bool thp_migration_supported(void) >>>> } >>>> #endif /* CONFIG_TRANSPARENT_HUGEPAGE */ >>>> >>>> -static inline int split_folio_to_list(struct folio *folio, >>>> - struct list_head *list) >>>> +static inline int split_folio_to_list_to_order(struct folio *folio, >>>> + struct list_head *list, int new_order) >>>> { >>>> - return split_huge_page_to_list(&folio->page, list); >>>> + return split_huge_page_to_list_to_order(&folio->page, list, new_order); >>>> } >>>> >>>> -static inline int split_folio(struct folio *folio) >>>> +static inline int split_folio_to_order(struct folio *folio, int new_order) >>>> { >>>> - return split_folio_to_list(folio, NULL); >>>> + return split_folio_to_list_to_order(folio, NULL, new_order); >>>> } >>>> >>>> +#define split_folio_to_list(f, l) split_folio_to_list_to_order(f, l, 0) >>>> +#define split_folio(f) split_folio_to_order(f, 0) >>>> + >>>> /* >>>> * archs that select ARCH_WANTS_THP_SWAP but don't support THP_SWP due to >>>> * limitations in the implementation like arm64 MTE can override this to >>>> diff --git a/mm/huge_memory.c b/mm/huge_memory.c >>>> index ad7133c97428..d0e555a8ea98 100644 >>>> --- a/mm/huge_memory.c >>>> +++ b/mm/huge_memory.c >>>> @@ -2718,11 +2718,14 @@ void vma_adjust_trans_huge(struct vm_area_struct *vma, >>>> >>>> static void unmap_folio(struct folio *folio) >>>> { >>>> - enum ttu_flags ttu_flags = TTU_RMAP_LOCKED | TTU_SPLIT_HUGE_PMD | >>>> - TTU_SYNC | TTU_BATCH_FLUSH; >>>> + enum ttu_flags ttu_flags = TTU_RMAP_LOCKED | TTU_SYNC | >>>> + TTU_BATCH_FLUSH; >>>> >>>> VM_BUG_ON_FOLIO(!folio_test_large(folio), folio); >>>> >>>> + if (folio_test_pmd_mappable(folio)) >>>> + ttu_flags |= TTU_SPLIT_HUGE_PMD; >>> >>> Should we split this change out? I think it makes sense independent of this series? >>> >> >> Sure. Since multi-size THP is upstream, this avoid unnecessary code path if >> the THP is not PMD-mapped. >> >>>> + >>>> /* >>>> * Anon pages need migration entries to preserve them, but file >>>> * pages can simply be left unmapped, then faulted back on demand. >>>> @@ -2756,7 +2759,6 @@ static void lru_add_page_tail(struct page *head, struct page *tail, >>>> struct lruvec *lruvec, struct list_head *list) >>>> { >>>> VM_BUG_ON_PAGE(!PageHead(head), head); >>>> - VM_BUG_ON_PAGE(PageCompound(tail), head); >>>> VM_BUG_ON_PAGE(PageLRU(tail), head); >>>> lockdep_assert_held(&lruvec->lru_lock); >>>> >>>> @@ -2777,7 +2779,8 @@ static void lru_add_page_tail(struct page *head, struct page *tail, >>>> } >>>> >>>> static void __split_huge_page_tail(struct folio *folio, int tail, >>>> - struct lruvec *lruvec, struct list_head *list) >>>> + struct lruvec *lruvec, struct list_head *list, >>>> + unsigned int new_order) >>>> { >>>> struct page *head = &folio->page; >>>> struct page *page_tail = head + tail; >>>> @@ -2847,10 +2850,15 @@ static void __split_huge_page_tail(struct folio *folio, int tail, >>>> * which needs correct compound_head(). >>>> */ >>>> clear_compound_head(page_tail); >>>> + if (new_order) { >>>> + prep_compound_page(page_tail, new_order); >>>> + folio_prep_large_rmappable(page_folio(page_tail)); >>>> + } >>>> >>>> /* Finally unfreeze refcount. Additional reference from page cache. */ >>>> - page_ref_unfreeze(page_tail, 1 + (!folio_test_anon(folio) || >>>> - folio_test_swapcache(folio))); >>>> + page_ref_unfreeze(page_tail, >>>> + 1 + ((!folio_test_anon(folio) || folio_test_swapcache(folio)) ? >>>> + folio_nr_pages(page_folio(page_tail)) : 0)); >>>> >>>> if (folio_test_young(folio)) >>>> folio_set_young(new_folio); >>>> @@ -2868,7 +2876,7 @@ static void __split_huge_page_tail(struct folio *folio, int tail, >>>> } >>>> >>>> static void __split_huge_page(struct page *page, struct list_head *list, >>>> - pgoff_t end) >>>> + pgoff_t end, unsigned int new_order) >>>> { >>>> struct folio *folio = page_folio(page); >>>> struct page *head = &folio->page; >>>> @@ -2877,10 +2885,11 @@ static void __split_huge_page(struct page *page, struct list_head *list, >>>> unsigned long offset = 0; >>>> unsigned int nr = thp_nr_pages(head); >>>> int i, nr_dropped = 0; >>>> + unsigned int new_nr = 1 << new_order; >>>> int order = folio_order(folio); >>>> >>>> /* complete memcg works before add pages to LRU */ >>>> - split_page_memcg(head, order, 0); >>>> + split_page_memcg(head, order, new_order); >>>> >>>> if (folio_test_anon(folio) && folio_test_swapcache(folio)) { >>>> offset = swp_offset(folio->swap); >>>> @@ -2893,8 +2902,8 @@ static void __split_huge_page(struct page *page, struct list_head *list, >>>> >>>> ClearPageHasHWPoisoned(head); >>>> >>>> - for (i = nr - 1; i >= 1; i--) { >>>> - __split_huge_page_tail(folio, i, lruvec, list); >>>> + for (i = nr - new_nr; i >= new_nr; i -= new_nr) { >>>> + __split_huge_page_tail(folio, i, lruvec, list, new_order); >>>> /* Some pages can be beyond EOF: drop them from page cache */ >>>> if (head[i].index >= end) { >>>> struct folio *tail = page_folio(head + i); >>>> @@ -2910,29 +2919,41 @@ static void __split_huge_page(struct page *page, struct list_head *list, >>>> __xa_store(&head->mapping->i_pages, head[i].index, >>>> head + i, 0); >>>> } else if (swap_cache) { >>>> + /* >>>> + * split anonymous THPs (including swapped out ones) to >>>> + * non-zero order not supported >>>> + */ >>>> + VM_WARN_ONCE(new_order, >>>> + "Split swap-cached anon folio to non-0 order not supported"); >>> >>> Why isn't it supported? Even if it's not supported, is this level the right >>> place to enforce these kinds of policy decisions? I wonder if we should be >>> leaving that to the higher level to decide? >> >> Is the swap-out small-size THP without splitting merged? This needs that patchset. > > No not yet. I have to respin it. Its on my todo list. > > I'm not sure I understand the dependency though? IIUC, swap cache only supports one cluster size, HPAGE_PMD_NR, so splitting a PMD-size swapcached folio will need to split a cluster to smaller ones, which needs your patchset support. Let me know if I get it wrong. > >> You are right that a warning here is not appropriate. I will fail the splitting >> if the folio is swapcached and going to be split into >0 order. >> >>>> __xa_store(&swap_cache->i_pages, offset + i, >>>> head + i, 0); >>>> } >>>> } >>>> >> >> >> -- >> Best Regards, >> Yan, Zi -- Best Regards, Yan, Zi
On 14 Feb 2024, at 5:55, David Hildenbrand wrote: > On 14.02.24 11:50, Ryan Roberts wrote: >> On 13/02/2024 22:31, Zi Yan wrote: >>> On 13 Feb 2024, at 17:21, David Hildenbrand wrote: >>> >>>> On 13.02.24 22:55, Zi Yan wrote: >>>>> From: Zi Yan <ziy@nvidia.com> >>>>> >>>>> Hi all, >>>>> >>>>> File folio supports any order and multi-size THP is upstreamed[1], so both >>>>> file and anonymous folios can be >0 order. Currently, split_huge_page() >>>>> only splits a huge page to order-0 pages, but splitting to orders higher than >>>>> 0 is going to better utilize large folios. In addition, Large Block >>>>> Sizes in XFS support would benefit from it[2]. This patchset adds support for >>>>> splitting a large folio to any lower order folios and uses it during file >>>>> folio truncate operations. >>>>> >>>>> For Patch 6, Hugh did not like my approach to minimize the number of >>>>> folios for truncate[3]. I would like to get more feedback, especially >>>>> from FS people, on it to decide whether to keep it or not. >>>> >>>> I'm curious, would it make sense to exclude the "more" controversial parts (i.e., patch #6) for now, and focus on the XFS use case only? >>> >>> Sure. Patch 6 was there to make use of split_huge_page_to_list_to_order(). >>> Now we have multi-size THP and XFS use cases, it can be dropped. >> >> What are your plans for how to determine when to split THP and to what order? I >> don't see anything in this series that would split anon THP to non-zero order? >> >> We have talked about using hints from user space in the past (e.g. mremap, >> munmap, madvise, etc). But chrome has a use case where it temporarily mprotects >> a single (4K) page as part of garbage collection (IIRC). If you eagerly split on >> that hint, you will have lost the benefits of the large folio when it later >> mprotects back to the original setting. > > Not only that, splitting will make some of these operations more expensive, possibly with no actual benefit. > >> >> I guess David will suggest this would be a good use case for the khugepaged-lite >> machanism we have been talking about. I dunno - it seems wasteful to split then >> collapse again. > > I agree. mprotect() and even madvise(), ... might not be good candidates for splitting. mremap() likely is, if the folio is mapped exclusively. MADV_DONTNEED/munmap()/mlock() might be good candidates (again, if mapped exclusively). This will need a lot of thought I'm afraid (as you say, deferred splitting is another example). My initial use was for splitting 1GB THP to 2MB THP, but 1GB THP is not upstream yet. So for now, this might only be used by XFS. For anonymous large folios, we will use this when we find a justified use case. What I can think of is when a PMD-mapped THP happens to be split and the resulting order can be a HW/SW favored order, like 64KB or 32KB (to be able to use contig PTE), we split to that order, otherwise, we still split to order-0. -- Best Regards, Yan, Zi
On 14/02/2024 16:28, Zi Yan wrote: > On 14 Feb 2024, at 11:22, Ryan Roberts wrote: > >> On 14/02/2024 16:11, Zi Yan wrote: >>> On 14 Feb 2024, at 5:38, Ryan Roberts wrote: >>> >>>> On 13/02/2024 21:55, Zi Yan wrote: >>>>> From: Zi Yan <ziy@nvidia.com> >>>>> >>>>> To split a THP to any lower order (except order-1) pages, we need to >>>>> reform THPs on subpages at given order and add page refcount based on the >>>>> new page order. Also we need to reinitialize page_deferred_list after >>>>> removing the page from the split_queue, otherwise a subsequent split will >>>>> see list corruption when checking the page_deferred_list again. >>>>> >>>>> It has many uses, like minimizing the number of pages after >>>>> truncating a huge pagecache page. For anonymous THPs, we can only split >>>>> them to order-0 like before until we add support for any size anonymous >>>>> THPs. >>>> >>>> multi-size THP is now upstream. Not sure if this comment still makes sense. >>> Will change it to reflect the fact that multi-size THP is already upstream. >>> >>>> Still its not completely clear to me how you would integrate this new machinery >>>> and decide what non-zero order to split anon THP to? >>> >>> Originally, it was developed along with my 1GB THP support. So it was intended >>> to split order-18 to order-9. But for now, like you and David said in the cover >>> letter email thread, we might not want to use it for anonymous large folios >>> until we find a necessary use case. >>> >>>>> >>>>> Order-1 folio is not supported because _deferred_list, which is used by >>>>> partially mapped folios, is stored in subpage 2 and an order-1 folio only >>>>> has subpage 0 and 1. >>>>> >>>>> Signed-off-by: Zi Yan <ziy@nvidia.com> >>>>> --- >>>>> include/linux/huge_mm.h | 21 +++++--- >>>>> mm/huge_memory.c | 114 +++++++++++++++++++++++++++++++--------- >>>>> 2 files changed, 101 insertions(+), 34 deletions(-) >>>>> >>>>> diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h >>>>> index 5adb86af35fc..de0c89105076 100644 >>>>> --- a/include/linux/huge_mm.h >>>>> +++ b/include/linux/huge_mm.h >>>>> @@ -265,10 +265,11 @@ unsigned long thp_get_unmapped_area(struct file *filp, unsigned long addr, >>>>> >>>>> void 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); >>>>> +int split_huge_page_to_list_to_order(struct page *page, struct list_head *list, >>>>> + unsigned int new_order); >>>>> static inline int split_huge_page(struct page *page) >>>>> { >>>>> - return split_huge_page_to_list(page, NULL); >>>>> + return split_huge_page_to_list_to_order(page, NULL, 0); >>>>> } >>>>> void deferred_split_folio(struct folio *folio); >>>>> >>>>> @@ -422,7 +423,8 @@ can_split_folio(struct folio *folio, int *pextra_pins) >>>>> return false; >>>>> } >>>>> static inline int >>>>> -split_huge_page_to_list(struct page *page, struct list_head *list) >>>>> +split_huge_page_to_list_to_order(struct page *page, struct list_head *list, >>>>> + unsigned int new_order) >>>>> { >>>>> return 0; >>>>> } >>>>> @@ -519,17 +521,20 @@ static inline bool thp_migration_supported(void) >>>>> } >>>>> #endif /* CONFIG_TRANSPARENT_HUGEPAGE */ >>>>> >>>>> -static inline int split_folio_to_list(struct folio *folio, >>>>> - struct list_head *list) >>>>> +static inline int split_folio_to_list_to_order(struct folio *folio, >>>>> + struct list_head *list, int new_order) >>>>> { >>>>> - return split_huge_page_to_list(&folio->page, list); >>>>> + return split_huge_page_to_list_to_order(&folio->page, list, new_order); >>>>> } >>>>> >>>>> -static inline int split_folio(struct folio *folio) >>>>> +static inline int split_folio_to_order(struct folio *folio, int new_order) >>>>> { >>>>> - return split_folio_to_list(folio, NULL); >>>>> + return split_folio_to_list_to_order(folio, NULL, new_order); >>>>> } >>>>> >>>>> +#define split_folio_to_list(f, l) split_folio_to_list_to_order(f, l, 0) >>>>> +#define split_folio(f) split_folio_to_order(f, 0) >>>>> + >>>>> /* >>>>> * archs that select ARCH_WANTS_THP_SWAP but don't support THP_SWP due to >>>>> * limitations in the implementation like arm64 MTE can override this to >>>>> diff --git a/mm/huge_memory.c b/mm/huge_memory.c >>>>> index ad7133c97428..d0e555a8ea98 100644 >>>>> --- a/mm/huge_memory.c >>>>> +++ b/mm/huge_memory.c >>>>> @@ -2718,11 +2718,14 @@ void vma_adjust_trans_huge(struct vm_area_struct *vma, >>>>> >>>>> static void unmap_folio(struct folio *folio) >>>>> { >>>>> - enum ttu_flags ttu_flags = TTU_RMAP_LOCKED | TTU_SPLIT_HUGE_PMD | >>>>> - TTU_SYNC | TTU_BATCH_FLUSH; >>>>> + enum ttu_flags ttu_flags = TTU_RMAP_LOCKED | TTU_SYNC | >>>>> + TTU_BATCH_FLUSH; >>>>> >>>>> VM_BUG_ON_FOLIO(!folio_test_large(folio), folio); >>>>> >>>>> + if (folio_test_pmd_mappable(folio)) >>>>> + ttu_flags |= TTU_SPLIT_HUGE_PMD; >>>> >>>> Should we split this change out? I think it makes sense independent of this series? >>>> >>> >>> Sure. Since multi-size THP is upstream, this avoid unnecessary code path if >>> the THP is not PMD-mapped. >>> >>>>> + >>>>> /* >>>>> * Anon pages need migration entries to preserve them, but file >>>>> * pages can simply be left unmapped, then faulted back on demand. >>>>> @@ -2756,7 +2759,6 @@ static void lru_add_page_tail(struct page *head, struct page *tail, >>>>> struct lruvec *lruvec, struct list_head *list) >>>>> { >>>>> VM_BUG_ON_PAGE(!PageHead(head), head); >>>>> - VM_BUG_ON_PAGE(PageCompound(tail), head); >>>>> VM_BUG_ON_PAGE(PageLRU(tail), head); >>>>> lockdep_assert_held(&lruvec->lru_lock); >>>>> >>>>> @@ -2777,7 +2779,8 @@ static void lru_add_page_tail(struct page *head, struct page *tail, >>>>> } >>>>> >>>>> static void __split_huge_page_tail(struct folio *folio, int tail, >>>>> - struct lruvec *lruvec, struct list_head *list) >>>>> + struct lruvec *lruvec, struct list_head *list, >>>>> + unsigned int new_order) >>>>> { >>>>> struct page *head = &folio->page; >>>>> struct page *page_tail = head + tail; >>>>> @@ -2847,10 +2850,15 @@ static void __split_huge_page_tail(struct folio *folio, int tail, >>>>> * which needs correct compound_head(). >>>>> */ >>>>> clear_compound_head(page_tail); >>>>> + if (new_order) { >>>>> + prep_compound_page(page_tail, new_order); >>>>> + folio_prep_large_rmappable(page_folio(page_tail)); >>>>> + } >>>>> >>>>> /* Finally unfreeze refcount. Additional reference from page cache. */ >>>>> - page_ref_unfreeze(page_tail, 1 + (!folio_test_anon(folio) || >>>>> - folio_test_swapcache(folio))); >>>>> + page_ref_unfreeze(page_tail, >>>>> + 1 + ((!folio_test_anon(folio) || folio_test_swapcache(folio)) ? >>>>> + folio_nr_pages(page_folio(page_tail)) : 0)); >>>>> >>>>> if (folio_test_young(folio)) >>>>> folio_set_young(new_folio); >>>>> @@ -2868,7 +2876,7 @@ static void __split_huge_page_tail(struct folio *folio, int tail, >>>>> } >>>>> >>>>> static void __split_huge_page(struct page *page, struct list_head *list, >>>>> - pgoff_t end) >>>>> + pgoff_t end, unsigned int new_order) >>>>> { >>>>> struct folio *folio = page_folio(page); >>>>> struct page *head = &folio->page; >>>>> @@ -2877,10 +2885,11 @@ static void __split_huge_page(struct page *page, struct list_head *list, >>>>> unsigned long offset = 0; >>>>> unsigned int nr = thp_nr_pages(head); >>>>> int i, nr_dropped = 0; >>>>> + unsigned int new_nr = 1 << new_order; >>>>> int order = folio_order(folio); >>>>> >>>>> /* complete memcg works before add pages to LRU */ >>>>> - split_page_memcg(head, order, 0); >>>>> + split_page_memcg(head, order, new_order); >>>>> >>>>> if (folio_test_anon(folio) && folio_test_swapcache(folio)) { >>>>> offset = swp_offset(folio->swap); >>>>> @@ -2893,8 +2902,8 @@ static void __split_huge_page(struct page *page, struct list_head *list, >>>>> >>>>> ClearPageHasHWPoisoned(head); >>>>> >>>>> - for (i = nr - 1; i >= 1; i--) { >>>>> - __split_huge_page_tail(folio, i, lruvec, list); >>>>> + for (i = nr - new_nr; i >= new_nr; i -= new_nr) { >>>>> + __split_huge_page_tail(folio, i, lruvec, list, new_order); >>>>> /* Some pages can be beyond EOF: drop them from page cache */ >>>>> if (head[i].index >= end) { >>>>> struct folio *tail = page_folio(head + i); >>>>> @@ -2910,29 +2919,41 @@ static void __split_huge_page(struct page *page, struct list_head *list, >>>>> __xa_store(&head->mapping->i_pages, head[i].index, >>>>> head + i, 0); >>>>> } else if (swap_cache) { >>>>> + /* >>>>> + * split anonymous THPs (including swapped out ones) to >>>>> + * non-zero order not supported >>>>> + */ >>>>> + VM_WARN_ONCE(new_order, >>>>> + "Split swap-cached anon folio to non-0 order not supported"); >>>> >>>> Why isn't it supported? Even if it's not supported, is this level the right >>>> place to enforce these kinds of policy decisions? I wonder if we should be >>>> leaving that to the higher level to decide? >>> >>> Is the swap-out small-size THP without splitting merged? This needs that patchset. >> >> No not yet. I have to respin it. Its on my todo list. >> >> I'm not sure I understand the dependency though? > > IIUC, swap cache only supports one cluster size, HPAGE_PMD_NR, so splitting > a PMD-size swapcached folio will need to split a cluster to smaller ones, which > needs your patchset support. Let me know if I get it wrong. Ahh yeah, sorry, obvious now that you've spelled it out - thanks! > >> >>> You are right that a warning here is not appropriate. I will fail the splitting >>> if the folio is swapcached and going to be split into >0 order. >>> >>>>> __xa_store(&swap_cache->i_pages, offset + i, >>>>> head + i, 0); >>>>> } >>>>> } >>>>> >>> >>> >>> -- >>> Best Regards, >>> Yan, Zi > > > -- > Best Regards, > Yan, Zi
Hi Pankaj, On 13 Feb 2024, at 16:55, Zi Yan wrote: > From: Zi Yan <ziy@nvidia.com> > > Hi all, > > File folio supports any order and multi-size THP is upstreamed[1], so both > file and anonymous folios can be >0 order. Currently, split_huge_page() > only splits a huge page to order-0 pages, but splitting to orders higher than > 0 is going to better utilize large folios. In addition, Large Block > Sizes in XFS support would benefit from it[2]. This patchset adds support for Just talked to Matthew about his order-1 pagecache folio, I am planning to grab that into this one, so that I can remove the restriction in my patches and you guys do not need to do that in your patchset. Let me know if it works for you. -- Best Regards, Yan, Zi
On Wed, Feb 14, 2024 at 12:18:14PM -0500, Zi Yan wrote: > Hi Pankaj, > > On 13 Feb 2024, at 16:55, Zi Yan wrote: > > > From: Zi Yan <ziy@nvidia.com> > > > > Hi all, > > > > File folio supports any order and multi-size THP is upstreamed[1], so both > > file and anonymous folios can be >0 order. Currently, split_huge_page() > > only splits a huge page to order-0 pages, but splitting to orders higher than > > 0 is going to better utilize large folios. In addition, Large Block > > Sizes in XFS support would benefit from it[2]. This patchset adds support for > > Just talked to Matthew about his order-1 pagecache folio, I am planning to > grab that into this one, so that I can remove the restriction in my patches > and you guys do not need to do that in your patchset. Let me know if it works > for you. > Cool! Sounds good to me. I generally base my baseline based on -rcs. So I might include it while sending for reviews until 6.8. I will remove that patch once this gets in for the 6.9 merge window. Thanks. -- Pankaj
Hi Zi Yan, On Tue, Feb 13, 2024 at 04:55:13PM -0500, Zi Yan wrote: > From: Zi Yan <ziy@nvidia.com> > > Hi all, > > File folio supports any order and multi-size THP is upstreamed[1], so both > file and anonymous folios can be >0 order. Currently, split_huge_page() > only splits a huge page to order-0 pages, but splitting to orders higher than > 0 is going to better utilize large folios. In addition, Large Block > Sizes in XFS support would benefit from it[2]. This patchset adds support for > splitting a large folio to any lower order folios and uses it during file > folio truncate operations. I added your patches on top of my patches, but removed patch 6 and I added this instead: diff --git a/mm/truncate.c b/mm/truncate.c index 725b150e47ac..dd07e2e327a8 100644 --- a/mm/truncate.c +++ b/mm/truncate.c @@ -239,7 +239,8 @@ bool truncate_inode_partial_folio(struct folio *folio, loff_t start, loff_t end) folio_invalidate(folio, offset, length); if (!folio_test_large(folio)) return true; - if (split_folio(folio) == 0) + if (split_folio_to_order(folio, + mapping_min_folio_order(folio->mapping)) == 0) return true; if (folio_test_dirty(folio)) return false; I ran genric/476 fstest[1] with SOAK_DURATION set to 360 seconds. This test uses fstress to do a lot of writes, truncate operations, etc. I ran this on XFS with **64k block size on a 4k page size system**. I recorded the vm event for split page and this was the result I got: Before your patches: root@debian:~/xfstests# cat /proc/vmstat | grep split thp_split_page 0 thp_split_page_failed 5819 After your patches: root@debian:~/xfstests# cat /proc/vmstat | grep split thp_split_page 5846 thp_split_page_failed 20 Your patch series definitely helps with splitting the folios while still maintaining the min_folio_order that LBS requires. We are still discussing how to quantify this benefit in terms of some metric with this support. If you have some ideas here, let me know. I will run the whole xfstests tonight to check for any regressions. -- Pankaj [1] https://github.com/kdave/xfstests/blob/master/tests/generic/476
On 16 Feb 2024, at 5:06, Pankaj Raghav (Samsung) wrote: > Hi Zi Yan, > > On Tue, Feb 13, 2024 at 04:55:13PM -0500, Zi Yan wrote: >> From: Zi Yan <ziy@nvidia.com> >> >> Hi all, >> >> File folio supports any order and multi-size THP is upstreamed[1], so both >> file and anonymous folios can be >0 order. Currently, split_huge_page() >> only splits a huge page to order-0 pages, but splitting to orders higher than >> 0 is going to better utilize large folios. In addition, Large Block >> Sizes in XFS support would benefit from it[2]. This patchset adds support for >> splitting a large folio to any lower order folios and uses it during file >> folio truncate operations. > > I added your patches on top of my patches, but removed patch 6 and I > added this instead: > > diff --git a/mm/truncate.c b/mm/truncate.c > index 725b150e47ac..dd07e2e327a8 100644 > --- a/mm/truncate.c > +++ b/mm/truncate.c > @@ -239,7 +239,8 @@ bool truncate_inode_partial_folio(struct folio *folio, loff_t start, loff_t end) > folio_invalidate(folio, offset, length); > if (!folio_test_large(folio)) > return true; > - if (split_folio(folio) == 0) > + if (split_folio_to_order(folio, > + mapping_min_folio_order(folio->mapping)) == 0) > return true; > if (folio_test_dirty(folio)) > return false; > > I ran genric/476 fstest[1] with SOAK_DURATION set to 360 seconds. This > test uses fstress to do a lot of writes, truncate operations, etc. I ran > this on XFS with **64k block size on a 4k page size system**. > > I recorded the vm event for split page and this was the result I got: > > Before your patches: > root@debian:~/xfstests# cat /proc/vmstat | grep split > thp_split_page 0 > thp_split_page_failed 5819 > > After your patches: > root@debian:~/xfstests# cat /proc/vmstat | grep split > thp_split_page 5846 > thp_split_page_failed 20 > > Your patch series definitely helps with splitting the folios while still > maintaining the min_folio_order that LBS requires. Sounds great! Thanks for testing. > > We are still discussing how to quantify this benefit in terms of some > metric with this support. If you have some ideas here, let me know. From my understanding, the benefit will come from that page cache folio size is bigger with LBS (plus this patchset) after truncate. I assume any benchmark testing read/write throughput after truncate operations might be helpful. > > I will run the whole xfstests tonight to check for any regressions. Can you use the update patches from: https://github.com/x-y-z/linux-1gb-thp/tree/split_thp_to_any_order_v5-mm-everything-2024-02-16-01-35? It contains changes and fixes based on the feedback from this version. I am planning to send this new version out soon. > > -- > Pankaj > > [1] https://github.com/kdave/xfstests/blob/master/tests/generic/476 -- Best Regards, Yan, Zi
From: Zi Yan <ziy@nvidia.com> Hi all, File folio supports any order and multi-size THP is upstreamed[1], so both file and anonymous folios can be >0 order. Currently, split_huge_page() only splits a huge page to order-0 pages, but splitting to orders higher than 0 is going to better utilize large folios. In addition, Large Block Sizes in XFS support would benefit from it[2]. This patchset adds support for splitting a large folio to any lower order folios and uses it during file folio truncate operations. For Patch 6, Hugh did not like my approach to minimize the number of folios for truncate[3]. I would like to get more feedback, especially from FS people, on it to decide whether to keep it or not. The patchset is on top of mm-everything-2024-02-13-01-26. Changelog === Since v3 --- 1. Excluded shmem folios and pagecache folios without FS support from splitting to any order (per Hugh Dickins). 2. Allowed splitting anonymous large folio to any lower order since multi-size THP is upstreamed. 3. Adapted selftests code to new framework. Since v2 --- 1. Fixed an issue in __split_page_owner() introduced during my rebase Since v1 --- 1. Changed split_page_memcg() and split_page_owner() parameter to use order 2. Used folio_test_pmd_mappable() in place of the equivalent code Details === * Patch 1 changes split_page_memcg() to use order instead of nr_pages * Patch 2 changes split_page_owner() to use order instead of nr_pages * Patch 3 and 4 add new_order parameter split_page_memcg() and split_page_owner() and prepare for upcoming changes. * Patch 5 adds split_huge_page_to_list_to_order() to split a huge page to any lower order. The original split_huge_page_to_list() calls split_huge_page_to_list_to_order() with new_order = 0. * Patch 6 uses split_huge_page_to_list_to_order() in large pagecache folio truncation instead of split the large folio all the way down to order-0. * Patch 7 adds a test API to debugfs and test cases in split_huge_page_test selftests. Comments and/or suggestions are welcome. [1] https://lore.kernel.org/all/20231207161211.2374093-1-ryan.roberts@arm.com/ [2] https://lore.kernel.org/linux-mm/qzbcjn4gcyxla4gwuj6smlnwknz2wvo5wrjctin6eengjfqjei@lzkxv3iy6bol/ [3] https://lore.kernel.org/linux-mm/9dd96da-efa2-5123-20d4-4992136ef3ad@google.com/ Zi Yan (7): mm/memcg: use order instead of nr in split_page_memcg() mm/page_owner: use order instead of nr in split_page_owner() mm: memcg: make memcg huge page split support any order split. mm: page_owner: add support for splitting to any order in split page_owner. mm: thp: split huge page to any lower order pages (except order-1). mm: truncate: split huge page cache page to a non-zero order if possible. mm: huge_memory: enable debugfs to split huge pages to any order. include/linux/huge_mm.h | 21 +- include/linux/memcontrol.h | 4 +- include/linux/page_owner.h | 10 +- mm/huge_memory.c | 149 +++++++++--- mm/memcontrol.c | 10 +- mm/page_alloc.c | 8 +- mm/page_owner.c | 8 +- mm/truncate.c | 21 +- .../selftests/mm/split_huge_page_test.c | 223 +++++++++++++++++- 9 files changed, 382 insertions(+), 72 deletions(-)