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

[David Hildenbrand <david@redhat.com>]

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