On Tue, Mar 12, 2024 at 03:34:13PM +0100, David Hildenbrand wrote: > On 12.03.24 15:01, Matthew Wilcox wrote: > > __free_pages(&folio->page, huge_page_order(h)); > > Heh, __free_pages() says: > > "This function can free multi-page allocations that are not compound pages". > I suspect that means "can also free compound pages", but it's confusing. Sorry. I wrote that documentation and I was focused on one thing, but failed to think of the other thing ... it can indeed free compound pages. I'll add this: * If the pages were allocated with __GFP_COMP, prefer using put_page() * to using this function. Also prefer to call put_page() rather than * calling __free_page() or __free_pages(page, 0). > Especially, I thought we recently learned that free hugetlb folios do have a > refcount of 0? Confusing. Yes, that is confusing. This function wouldn't work if the refcount were 0 (put_page_testzero() would complain). Ah, here we go: In __folio_put(), we know that refcount is 0. __folio_put_large() -> destroy_large_folio -> free_huge_folio (refcount still 0 here, indeed it asserts it) If we add it back to the pool, the refcount stays at 0. But if we're removing it, we call __remove_hugetlb_folio() which calls folio_ref_unfreeze().