Messages in this thread | | | Date | Thu, 8 Dec 2022 14:01:06 -0800 | Subject | Re: [PATCH mm-unstable] mm: clarify folio_set_compound_order() zero support | From | John Hubbard <> |
| |
On 12/8/22 13:58, Sidhartha Kumar wrote: > Thanks John, Mike, Matthew, and Muchun for the feedback. > > To summarize this discussion and outline the next version of this patch, the changes I'll make include: > > 1) change the name of folio_set_compound_order() to folio_set_order() > 2) change the placement of this function from mm.h to mm/internal.h > 3) folio_set_order() will set both _folio_order and _folio_nr_pages and handle the zero order case correctly. > 4) remove the comment about hugetlb's specific use for zero orders > 5) improve the style of folio_set_order() by removing ifdefs from inside the function to doing > > #ifdef CONFIG_64BIT > static inline void folio_set_order(struct folio *folio, > unsigned int order) > { > VM_BUG_ON_FOLIO(!folio_test_large(folio), folio);
Sounds good, except for this part: why is a function named folio_set_order() BUG-ing on a non-large folio? The naming is still wrong, perhaps?
> > folio->_folio_order = order; > folio->_folio_nr_pages = order ? 1U << order : 0; > } > #else > static inline void folio_set_order(struct folio *folio, > unsigned int order) > { > VM_BUG_ON_FOLIO(!folio_test_large(folio), folio); > > folio->_folio_order = order; > } > #endif > > Please let me know if I missing something. > Thanks, > Sidhartha Kumar >> Thanks, >
thanks, -- John Hubbard NVIDIA
| |