On 12.03.24 16:38, Matthew Wilcox wrote:
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).
Sounds good.
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().
Ah, that's the case I was missing. The joy of hugetlb :)
As a side note: hugetlb.c still talks about "destructor" and "dtor". I
assume that dates back to the times where we identified hugetlb folios
by a deconstrucor in the compound page.
--
Cheers,
David / dhildenb
