Re: [PATCH 1/2] mm: Turn folio_test_hugetlb into a PageType

[Miaohe Lin <linmiaohe@huawei.com>]

On 2024/3/15 20:32, Matthew Wilcox wrote:
> On Fri, Mar 15, 2024 at 02:19:10PM +0800, Miaohe Lin wrote:
>> On 2024/3/14 22:33, Matthew Wilcox wrote:
>>> I actually want to do a bit more here ...
>>>
>>> +++ b/mm/debug.c
>>> @@ -58,15 +58,10 @@ static void __dump_folio(struct folio *folio, struct page *page,
>>>         int mapcount = 0;
>>>         char *type = "";
>>>
>>> -       /*
>>> -        * page->_mapcount space in struct page is used by slab pages to
>>> -        * encode own info, and we must avoid calling page_folio() again.
>>> -        */
>>> -       if (!folio_test_slab(folio)) {
>>> +       if (!page_has_type(page)) {
>>>                 mapcount = atomic_read(&page->_mapcount) + 1;
>>> -               if (folio_test_large(folio))
>>> -                       mapcount += folio_entire_mapcount(folio);
>>> -       }
>>> +       if (folio_test_large(folio))
>>> +               mapcount += folio_entire_mapcount(folio);
>>
>> Why folio_test_large is not within the "if (!page_has_type(page))" block? I think a slab page could also be large folio.
>> Or am I miss something?
> 
> Slab pages don't use the first tail page so folio_entire_mapcount will
> be 0 for them.  And we don't want the folio_test_large() to be gated by
> page_has_type() because hugetlb pages (after this patch) will be in the
> page_has_type() category.  So for hugetlb pages, we want to not read
> page->mapcount (leaving mapcount at zero), but we do want to read the
> entire_mapcount.

I see. Many thanks for your explanation. This might worth a comment to avoid future confusion.
Thanks.