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

[David Hildenbrand <david@redhat.com>]

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?

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

-- 
Cheers

David / dhildenb