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

[Zi Yan <ziy@nvidia.com>]

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.

How about?

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

>
>>
>> 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 :)

;)

Best Regards,
Yan, Zi