Messages in this thread | | | Date | Wed, 14 Dec 2022 12:35:23 -0800 | Subject | Re: [PATCH mm-unstable] mm: move folio_set_compound_order() to mm/internal.h | From | Sidhartha Kumar <> |
| |
On 12/14/22 12:43 AM, John Hubbard wrote: > On 12/13/22 13:20, Sidhartha Kumar wrote: >> folio_set_compound_order() is moved to an mm-internal location so external >> folio users cannot misuse this function. Change the name of the function >> to folio_set_order() and use WARN_ON_ONCE() rather than BUG_ON. Also, >> handle the case if a non-large folio is passed and add clarifying comments >> to the function. >> >> Link: https://lore.kernel.org/lkml/20221207223731.32784-1-sidhartha.kumar@oracle.com/T/ >> Fixes: 9fd330582b2f ("mm: add folio dtor and order setter functions") >> >> Signed-off-by: Sidhartha Kumar <sidhartha.kumar@oracle.com> >> Suggested-by: Mike Kravetz <mike.kravetz@oracle.com> >> Suggested-by: Muchun Song <songmuchun@bytedance.com> >> Suggested-by: Matthew Wilcox <willy@infradead.org> >> Suggested-by: John Hubbard <jhubbard@nvidia.com> >> --- >> include/linux/mm.h | 16 ---------------- >> mm/hugetlb.c | 6 +++--- >> mm/internal.h | 21 +++++++++++++++++++++ >> 3 files changed, 24 insertions(+), 19 deletions(-) > > I think this looks good. One small question below. > >> >> diff --git a/include/linux/mm.h b/include/linux/mm.h >> index 7dc376052d40..300d92d2b49d 100644 >> --- a/include/linux/mm.h >> +++ b/include/linux/mm.h >> @@ -1019,22 +1019,6 @@ static inline void set_compound_order(struct page *page, unsigned int order) >> #endif >> } >> >> -/* >> - * folio_set_compound_order is generally passed a non-zero order to >> - * initialize a large folio. However, hugetlb code abuses this by >> - * passing in zero when 'dissolving' a large folio. >> - */ >> -static inline void folio_set_compound_order(struct folio *folio, >> - unsigned int order) >> -{ >> - VM_BUG_ON_FOLIO(!folio_test_large(folio), folio); >> - >> - folio->_folio_order = order; >> -#ifdef CONFIG_64BIT >> - folio->_folio_nr_pages = order ? 1U << order : 0; >> -#endif >> -} >> - >> /* Returns the number of pages in this potentially compound page. */ >> static inline unsigned long compound_nr(struct page *page) >> { >> diff --git a/mm/hugetlb.c b/mm/hugetlb.c >> index 7cdbcc22587b..810e840bb4f1 100644 >> --- a/mm/hugetlb.c >> +++ b/mm/hugetlb.c >> @@ -1344,7 +1344,7 @@ static void __destroy_compound_gigantic_folio(struct folio *folio, >> set_page_refcounted(p); >> } >> >> - folio_set_compound_order(folio, 0); >> + folio_set_order(folio, 0); >> __folio_clear_head(folio); >> } >> >> @@ -1808,7 +1808,7 @@ static bool __prep_compound_gigantic_folio(struct folio *folio, >> __folio_clear_reserved(folio); >> __folio_set_head(folio); >> /* we rely on prep_new_hugetlb_folio to set the destructor */ >> - folio_set_compound_order(folio, order); >> + folio_set_order(folio, order); >> for (i = 0; i < nr_pages; i++) { >> p = folio_page(folio, i); >> >> @@ -1872,7 +1872,7 @@ static bool __prep_compound_gigantic_folio(struct folio *folio, >> p = folio_page(folio, j); >> __ClearPageReserved(p); >> } >> - folio_set_compound_order(folio, 0); >> + folio_set_order(folio, 0); >> __folio_clear_head(folio); >> return false; >> } >> diff --git a/mm/internal.h b/mm/internal.h >> index bcf75a8b032d..829b6a60ceb7 100644 >> --- a/mm/internal.h >> +++ b/mm/internal.h >> @@ -378,6 +378,27 @@ extern void *memmap_alloc(phys_addr_t size, phys_addr_t align, >> int split_free_page(struct page *free_page, >> unsigned int order, unsigned long split_pfn_offset); >> >> +/* >> + * This will have no effect, other than possibly generating a warning, if the >> + * caller passes in a non-large folio. >> + */ >> +static inline void folio_set_order(struct folio *folio, unsigned int order) >> +{ >> + if (!folio_test_large(folio)) { >> + WARN_ON_ONCE(order); >> + return; >> + } > > Would it be better to do this (below)? I'm not sure of the value of > warning on "order"--it's a little odd and unexplained and doesn't really > do anything more helpful than simply warning about what why the code is > failing, which is really about !large, rather than order. Unless I'm > missing something? > > if (WARN_ON_ONCE(!folio_test_large(folio))) > return; >I agree that warning this way is clearer, I will change in a v2.
> Sorry to drive you crazy over nits. This is the last one from me. :) > No worries, I appreciate the feedback.
Thanks, Sidhartha Kumar
> thanks,
| |