Re: [PATCH] mm/hugetlb: fix surplus pages in dissolve_free_huge_page()

[Jinjiang Tu <tujinjiang@huawei.com>]

在 2025/3/3 19:47, David Hildenbrand 写道:
> On 03.03.25 12:23, Jinjiang Tu wrote:
>>
>> 在 2025/3/3 19:16, Jinjiang Tu 写道:
>>>
>>> 在 2025/3/3 18:25, David Hildenbrand 写道:
>>>> On 03.03.25 07:09, Jinjiang Tu wrote:
>>>>> In dissolve_free_huge_page(), free huge pages are dissolved without
>>>>> adjusting surplus count. However, free huge pages may be accounted as
>>>>> surplus pages, and will lead to wrong surplus count.
>>>>>
>>>>> Steps to reproduce:
>>>>> 1) create 64 huge pages for node1
>>>>> 2) run a program to reserve (don't consume) all the huge pages
>>>>> 3) echo 0 > nr_huge_pages for node1. After this step, free huge
>>>>> pages in
>>>>> Node1 are surplus.
>>>>> 4) create 80 huge pages for node0
>>>>> 5) offline memory of node1 and kill the program in step 2)
>>>>
>>>> Can you elaborate the "offline memory" part? How much are you
>>>> offlining (the complete node vs a single memory block?)
>>> I reproduce this issue on qemu. The memory onlining and offlining
>>> operations are:
>>>
>>> 1）Node1 is memory-less at first. Hot-add memory to node1 by executing
>>> the two commands in qemu monitor
>>> object_add memory-backend-ram,id=mem1,size=1G
>>> device_add pc-dimm,id=dimm1,memdev=mem1,node=1
>>>
>>> 2）online one memory block of Node1 with：
>>> echo online_movable > /sys/devices/system/node/node1/memoryX/state
>>>
>>> 3) offline the memory block of Node1 with：
>>> echo offline > /sys/devices/system/node/node1/memoryX/state
>> The memory range to offline contains the free surplus huge pages created
>> in step1) ~ step3)
>
> Okay, that makes it a lot clearer. Can you make that clearer in the 
> patch description?
Sure, I will send a v2 patch later.
>
> The problem appears when memory offlining stumbles over a free hugetlb 
> folio. We'll call 
> dissolve_free_hugetlb_folios()->dissolve_free_hugetlb_folio() to 
> dissolve it, but don't adjust accounting with surplus pages properly.
>
> I'll note that there is another dissolve_free_hugetlb_folio() caller 
> in the memory-failure path that might similarly be affected.
>