Re: [PATCH] mm: Always initialise folio->_deferred_list

[Matthew Wilcox <willy@infradead.org>]

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().