Re: [Patch v2 2/2] mm/huge_memory: Optimize and simplify __split_unmapped_folio() logic

[David Hildenbrand <david@redhat.com>]

On 16.10.25 22:22, Zi Yan wrote:
> On 16 Oct 2025, at 16:10, David Hildenbrand wrote:
> 
>> On 16.10.25 02:46, Wei Yang wrote:
>>> Existing __split_unmapped_folio() code splits the given folio and update
>>> stats, but it is complicated to understand.
>>>
>>> After simplification, __split_unmapped_folio() directly calculate and
>>
>> s/calculate/calculates/
>>
>>> update the folio statistics upon a successful split:
>>
>> s/update/updates/
>>
>>>
>>> * All resulting folios are @split_order.
>>>
>>> * The number of new folios are calculated directly from @old_order
>>>     and @split_order.
>>
>> That makes sense.
>>
>>>
>>> * The folio for the next split is identified as the one containing
>>>     @split_at.
>>>
>>
>> That as well.
>>
>>> * An xas_try_split() error is returned directly without worrying
>>>     about stats updates.
>>
>> Why is that change ok?
> 
> Before this, the code decreases 1 for the to-be-split folio before
> the split actually happens, so for a failed xas_try_split() the stats
> needs to be fixed up. Wei’s code updates stats after the split,
> removing the stats fixup for a xas_try_split() failure.

Ah, that was not immediately clear to me.

> 
> How about?
> 
> * Stats fixup is no longer needed for an xas_try_split() error,
> since originally stats was updated before an split happens.

... since we now update the stats only after a successful split.

?

> 
>>
>>>
>>> Signed-off-by: Wei Yang <richard.weiyang@gmail.com>
>>> Cc: Zi Yan <ziy@nvidia.com>
>>> Reviewed-by: Zi Yan <ziy@nvidia.com>
>>>
>>> ---
>>> v2:
>>>     * merge patch 2-5
>>>     * retain start_order
>>>     * new_folios -> nr_new_folios
>>>     * add a comment at the end of the loop
>>> ---
>>>    mm/huge_memory.c | 66 ++++++++++++++----------------------------------
>>>    1 file changed, 19 insertions(+), 47 deletions(-)
>>
>> Skimmed over the rest and LGTM, but it's all a bit complicated to understand.
>>
>> Trusting on Zu Yan here :)
> 
> ;)

"Zi" of course :)

-- 
Cheers

David / dhildenb