[PATCH 0/2] mm/huge_memory: Modularize and simplify folio splitting paths

[PATCH 0/2] mm/huge_memory: Modularize and simplify folio splitting paths

[Wei Yang]

This two-patch series focuses on refactoring the core logic of folio
splitting to improve code structure, clarity, and maintainability.

The first patch introduces a new consolidated helper function that groups
all the required tasks involved in a folio split. The second patch then
leverages this new helper to clearly separate the different execution
paths for uniform and non-uniform splitting, which simplifies
__split_unmapped_folio().

This series sets a better foundation for future optimizations and
maintenance in the huge memory handling code.

Also selftests/split_huge_page_test pass.

Wei Yang (2):
  mm/huge_memory: introduce __split_folio_and_update_stats() to
    consolidate split task
  mm/huge_memory: separate uniform/non uniform split logic in
    __split_unmapped_folio()

 mm/huge_memory.c | 59 +++++++++++++++++++++++++++---------------------
 1 file changed, 33 insertions(+), 26 deletions(-)

-- 
2.34.1

[PATCH 1/2] mm/huge_memory: introduce __split_folio_and_update_stats() to consolidate split task

[Wei Yang]

The folio splitting process involves several related tasks that are
executed together:

    Adjusting memcg (memory control group) accounting.
    Updating page owner tracking.
    Splitting the folio to the target size (new_order).
    Updating necessary folio statistics.

This commit introduces the new helper function,
__split_folio_and_update_stats(), to gather all these tasks. This
consolidation improves modularity and is a necessary preparation step
for further cleanup and simplification of the surrounding folio
splitting logic.

Signed-off-by: Wei Yang <richard.weiyang@gmail.com>
Cc: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Cc: Zi Yan <ziy@nvidia.com>
---
 mm/huge_memory.c | 28 +++++++++++++++++-----------
 1 file changed, 17 insertions(+), 11 deletions(-)

diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index c37fe6ad0c96..abde0f1aa8ff 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -3567,6 +3567,22 @@ static void __split_folio_to_order(struct folio *folio, int old_order,
 		ClearPageCompound(&folio->page);
 }
 
+static void __split_folio_and_update_stats(struct folio *folio, int old_order,
+		int new_order, bool is_anon)
+{
+	int nr_new_folios = 1UL << (old_order - new_order);
+
+	folio_split_memcg_refs(folio, old_order, new_order);
+	split_page_owner(&folio->page, old_order, new_order);
+	pgalloc_tag_split(folio, old_order, new_order);
+	__split_folio_to_order(folio, old_order, new_order);
+
+	if (is_anon) {
+		mod_mthp_stat(old_order, MTHP_STAT_NR_ANON, -1);
+		mod_mthp_stat(new_order, MTHP_STAT_NR_ANON, nr_new_folios);
+	}
+}
+
 /**
  * __split_unmapped_folio() - splits an unmapped @folio to lower order folios in
  * two ways: uniform split or non-uniform split.
@@ -3623,8 +3639,6 @@ static int __split_unmapped_folio(struct folio *folio, int new_order,
 	for (split_order = start_order;
 	     split_order >= new_order;
 	     split_order--) {
-		int nr_new_folios = 1UL << (old_order - split_order);
-
 		/* order-1 anonymous folio is not supported */
 		if (is_anon && split_order == 1)
 			continue;
@@ -3645,15 +3659,7 @@ static int __split_unmapped_folio(struct folio *folio, int new_order,
 			}
 		}
 
-		folio_split_memcg_refs(folio, old_order, split_order);
-		split_page_owner(&folio->page, old_order, split_order);
-		pgalloc_tag_split(folio, old_order, split_order);
-		__split_folio_to_order(folio, old_order, split_order);
-
-		if (is_anon) {
-			mod_mthp_stat(old_order, MTHP_STAT_NR_ANON, -1);
-			mod_mthp_stat(split_order, MTHP_STAT_NR_ANON, nr_new_folios);
-		}
+		__split_folio_and_update_stats(folio, old_order, split_order, is_anon);
 		/*
 		 * If uniform split, the process is complete.
 		 * If non-uniform, continue splitting the folio at @split_at
-- 
2.34.1

[PATCH 2/2] mm/huge_memory: separate uniform/non uniform split logic in __split_unmapped_folio()

[Wei Yang]

By utilizing the newly introduced __split_folio_and_update_stats()
helper function, we can now clearly separate the logic for uniform and
non-uniform folio splitting within __split_unmapped_folio().

This refactoring greatly simplifies the code by creating two distinct
execution paths:

    * Uniform Split: Directly calls __split_folio_and_update_stats()
      once to achieve the @new_order in a single operation.

    * Non-Uniform Split: Continues to use a loop to iteratively split
      the folio to a single lower order at a time, eventually reaching
      the @new_order.

This separation improves code clarity and maintainability.

Signed-off-by: Wei Yang <richard.weiyang@gmail.com>
Cc: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Cc: Zi Yan <ziy@nvidia.com>
---
 mm/huge_memory.c | 31 ++++++++++++++++---------------
 1 file changed, 16 insertions(+), 15 deletions(-)

diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index abde0f1aa8ff..c4fb84cedbe0 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -3629,14 +3629,20 @@ static int __split_unmapped_folio(struct folio *folio, int new_order,
 {
 	const bool is_anon = folio_test_anon(folio);
 	int old_order = folio_order(folio);
-	int start_order = uniform_split ? new_order : old_order - 1;
 	int split_order;
 
+	/* For uniform split, folio is split to new_order directly. */
+	if (uniform_split) {
+		if (mapping)
+			xas_split(xas, folio, old_order);
+		__split_folio_and_update_stats(folio, old_order, new_order, is_anon);
+		return 0;
+	}
+
 	/*
-	 * split to new_order one order at a time. For uniform split,
-	 * folio is split to new_order directly.
+	 * For non-uniform, split to new_order one order at a time.
 	 */
-	for (split_order = start_order;
+	for (split_order = old_order - 1;
 	     split_order >= new_order;
 	     split_order--) {
 		/* order-1 anonymous folio is not supported */
@@ -3649,21 +3655,16 @@ static int __split_unmapped_folio(struct folio *folio, int new_order,
 			 * irq is disabled to allocate enough memory, whereas
 			 * non-uniform split can handle ENOMEM.
 			 */
-			if (uniform_split)
-				xas_split(xas, folio, old_order);
-			else {
-				xas_set_order(xas, folio->index, split_order);
-				xas_try_split(xas, folio, old_order);
-				if (xas_error(xas))
-					return xas_error(xas);
-			}
+			xas_set_order(xas, folio->index, split_order);
+			xas_try_split(xas, folio, old_order);
+			if (xas_error(xas))
+				return xas_error(xas);
 		}
 
 		__split_folio_and_update_stats(folio, old_order, split_order, is_anon);
 		/*
-		 * If uniform split, the process is complete.
-		 * If non-uniform, continue splitting the folio at @split_at
-		 * as long as the next @split_order is >= @new_order.
+		 * Continue splitting the folio at @split_at as long as the
+		 * next @split_order is >= @new_order.
 		 */
 		folio = page_folio(split_at);
 		old_order = split_order;
-- 
2.34.1

Re: [PATCH 1/2] mm/huge_memory: introduce __split_folio_and_update_stats() to consolidate split task

[David Hildenbrand (Red Hat)]

On 01.11.25 01:29, Wei Yang wrote:
> The folio splitting process involves several related tasks that are
> executed together:
> 
>      Adjusting memcg (memory control group) accounting.
>      Updating page owner tracking.
>      Splitting the folio to the target size (new_order).
>      Updating necessary folio statistics.
> 
> This commit introduces the new helper function,
> __split_folio_and_update_stats(), to gather all these tasks. This
> consolidation improves modularity and is a necessary preparation step
> for further cleanup and simplification of the surrounding folio
> splitting logic.
> 
> Signed-off-by: Wei Yang <richard.weiyang@gmail.com>
> Cc: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
> Cc: Zi Yan <ziy@nvidia.com>
> ---
>   mm/huge_memory.c | 28 +++++++++++++++++-----------
>   1 file changed, 17 insertions(+), 11 deletions(-)
> 
> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> index c37fe6ad0c96..abde0f1aa8ff 100644
> --- a/mm/huge_memory.c
> +++ b/mm/huge_memory.c
> @@ -3567,6 +3567,22 @@ static void __split_folio_to_order(struct folio *folio, int old_order,
>   		ClearPageCompound(&folio->page);
>   }
>   
> +static void __split_folio_and_update_stats(struct folio *folio, int old_order,
> +		int new_order, bool is_anon)

Is there any good reason we want to pass things like "is_anon" instead 
of just querying it in that helper?


> +{
> +	int nr_new_folios = 1UL << (old_order - new_order);

Could be const.


-- 
Cheers

David

Re: [PATCH 1/2] mm/huge_memory: introduce __split_folio_and_update_stats() to consolidate split task

[David Hildenbrand (Red Hat)]

On 03.11.25 17:20, David Hildenbrand (Red Hat) wrote:
> On 01.11.25 01:29, Wei Yang wrote:
>> The folio splitting process involves several related tasks that are
>> executed together:
>>
>>       Adjusting memcg (memory control group) accounting.
>>       Updating page owner tracking.
>>       Splitting the folio to the target size (new_order).
>>       Updating necessary folio statistics.
>>
>> This commit introduces the new helper function,
>> __split_folio_and_update_stats(), to gather all these tasks. This
>> consolidation improves modularity and is a necessary preparation step
>> for further cleanup and simplification of the surrounding folio
>> splitting logic.
>>
>> Signed-off-by: Wei Yang <richard.weiyang@gmail.com>
>> Cc: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
>> Cc: Zi Yan <ziy@nvidia.com>
>> ---
>>    mm/huge_memory.c | 28 +++++++++++++++++-----------
>>    1 file changed, 17 insertions(+), 11 deletions(-)
>>
>> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
>> index c37fe6ad0c96..abde0f1aa8ff 100644
>> --- a/mm/huge_memory.c
>> +++ b/mm/huge_memory.c
>> @@ -3567,6 +3567,22 @@ static void __split_folio_to_order(struct folio *folio, int old_order,
>>    		ClearPageCompound(&folio->page);
>>    }
>>    
>> +static void __split_folio_and_update_stats(struct folio *folio, int old_order,
>> +		int new_order, bool is_anon)
> 
> Is there any good reason we want to pass things like "is_anon" instead
> of just querying it in that helper?
> 
> 
>> +{
>> +	int nr_new_folios = 1UL << (old_order - new_order);
> 
> Could be const.
> 
> 

Looking at it again, and that we are not reusing this function on patch 
#2, I am not sure factoring this out is really helpful at this point?

-- 
Cheers

David

Re: [PATCH 1/2] mm/huge_memory: introduce __split_folio_and_update_stats() to consolidate split task

[David Hildenbrand (Red Hat)]

On 03.11.25 17:21, David Hildenbrand (Red Hat) wrote:
> On 03.11.25 17:20, David Hildenbrand (Red Hat) wrote:
>> On 01.11.25 01:29, Wei Yang wrote:
>>> The folio splitting process involves several related tasks that are
>>> executed together:
>>>
>>>        Adjusting memcg (memory control group) accounting.
>>>        Updating page owner tracking.
>>>        Splitting the folio to the target size (new_order).
>>>        Updating necessary folio statistics.
>>>
>>> This commit introduces the new helper function,
>>> __split_folio_and_update_stats(), to gather all these tasks. This
>>> consolidation improves modularity and is a necessary preparation step
>>> for further cleanup and simplification of the surrounding folio
>>> splitting logic.
>>>
>>> Signed-off-by: Wei Yang <richard.weiyang@gmail.com>
>>> Cc: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
>>> Cc: Zi Yan <ziy@nvidia.com>
>>> ---
>>>     mm/huge_memory.c | 28 +++++++++++++++++-----------
>>>     1 file changed, 17 insertions(+), 11 deletions(-)
>>>
>>> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
>>> index c37fe6ad0c96..abde0f1aa8ff 100644
>>> --- a/mm/huge_memory.c
>>> +++ b/mm/huge_memory.c
>>> @@ -3567,6 +3567,22 @@ static void __split_folio_to_order(struct folio *folio, int old_order,
>>>     		ClearPageCompound(&folio->page);
>>>     }
>>>     
>>> +static void __split_folio_and_update_stats(struct folio *folio, int old_order,
>>> +		int new_order, bool is_anon)
>>
>> Is there any good reason we want to pass things like "is_anon" instead
>> of just querying it in that helper?
>>
>>
>>> +{
>>> +	int nr_new_folios = 1UL << (old_order - new_order);
>>
>> Could be const.
>>
>>
> 
> Looking at it again, and that we are not reusing this function on patch
> #2, I am not sure factoring this out is really helpful at this point?

Ignore that, I was briefly confused by patch #2 :)

-- 
Cheers

David

Re: [PATCH 1/2] mm/huge_memory: introduce __split_folio_and_update_stats() to consolidate split task

[Wei Yang]

On Mon, Nov 03, 2025 at 05:20:02PM +0100, David Hildenbrand (Red Hat) wrote:
>On 01.11.25 01:29, Wei Yang wrote:
>> The folio splitting process involves several related tasks that are
>> executed together:
>> 
>>      Adjusting memcg (memory control group) accounting.
>>      Updating page owner tracking.
>>      Splitting the folio to the target size (new_order).
>>      Updating necessary folio statistics.
>> 
>> This commit introduces the new helper function,
>> __split_folio_and_update_stats(), to gather all these tasks. This
>> consolidation improves modularity and is a necessary preparation step
>> for further cleanup and simplification of the surrounding folio
>> splitting logic.
>> 
>> Signed-off-by: Wei Yang <richard.weiyang@gmail.com>
>> Cc: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
>> Cc: Zi Yan <ziy@nvidia.com>
>> ---
>>   mm/huge_memory.c | 28 +++++++++++++++++-----------
>>   1 file changed, 17 insertions(+), 11 deletions(-)
>> 
>> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
>> index c37fe6ad0c96..abde0f1aa8ff 100644
>> --- a/mm/huge_memory.c
>> +++ b/mm/huge_memory.c
>> @@ -3567,6 +3567,22 @@ static void __split_folio_to_order(struct folio *folio, int old_order,
>>   		ClearPageCompound(&folio->page);
>>   }
>> +static void __split_folio_and_update_stats(struct folio *folio, int old_order,
>> +		int new_order, bool is_anon)
>
>Is there any good reason we want to pass things like "is_anon" instead of
>just querying it in that helper?
>

The reason is during split, folio's attribute will not change. In
__split_unmapped_folio() it is queried and set as const.

Otherwise we need to query it on each split.

>
>> +{
>> +	int nr_new_folios = 1UL << (old_order - new_order);
>
>Could be const.
>

Will add it.

>
>-- 
>Cheers
>
>David

-- 
Wei Yang
Help you, Help me

Re: [PATCH 1/2] mm/huge_memory: introduce __split_folio_and_update_stats() to consolidate split task

[David Hildenbrand (Red Hat)]

On 04.11.25 00:37, Wei Yang wrote:
> On Mon, Nov 03, 2025 at 05:20:02PM +0100, David Hildenbrand (Red Hat) wrote:
>> On 01.11.25 01:29, Wei Yang wrote:
>>> The folio splitting process involves several related tasks that are
>>> executed together:
>>>
>>>       Adjusting memcg (memory control group) accounting.
>>>       Updating page owner tracking.
>>>       Splitting the folio to the target size (new_order).
>>>       Updating necessary folio statistics.
>>>
>>> This commit introduces the new helper function,
>>> __split_folio_and_update_stats(), to gather all these tasks. This
>>> consolidation improves modularity and is a necessary preparation step
>>> for further cleanup and simplification of the surrounding folio
>>> splitting logic.
>>>
>>> Signed-off-by: Wei Yang <richard.weiyang@gmail.com>
>>> Cc: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
>>> Cc: Zi Yan <ziy@nvidia.com>
>>> ---
>>>    mm/huge_memory.c | 28 +++++++++++++++++-----------
>>>    1 file changed, 17 insertions(+), 11 deletions(-)
>>>
>>> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
>>> index c37fe6ad0c96..abde0f1aa8ff 100644
>>> --- a/mm/huge_memory.c
>>> +++ b/mm/huge_memory.c
>>> @@ -3567,6 +3567,22 @@ static void __split_folio_to_order(struct folio *folio, int old_order,
>>>    		ClearPageCompound(&folio->page);
>>>    }
>>> +static void __split_folio_and_update_stats(struct folio *folio, int old_order,
>>> +		int new_order, bool is_anon)
>>
>> Is there any good reason we want to pass things like "is_anon" instead of
>> just querying it in that helper?
>>
> 
> The reason is during split, folio's attribute will not change. In
> __split_unmapped_folio() it is queried and set as const.
> 
> Otherwise we need to query it on each split.

These checks are extremely cheap. Do we really care?

-- 
Cheers

David

Re: [PATCH 1/2] mm/huge_memory: introduce __split_folio_and_update_stats() to consolidate split task

[Wei Yang]

On Tue, Nov 04, 2025 at 11:33:43AM +0100, David Hildenbrand (Red Hat) wrote:
>On 04.11.25 00:37, Wei Yang wrote:
>> On Mon, Nov 03, 2025 at 05:20:02PM +0100, David Hildenbrand (Red Hat) wrote:
>> > On 01.11.25 01:29, Wei Yang wrote:
>> > > The folio splitting process involves several related tasks that are
>> > > executed together:
>> > > 
>> > >       Adjusting memcg (memory control group) accounting.
>> > >       Updating page owner tracking.
>> > >       Splitting the folio to the target size (new_order).
>> > >       Updating necessary folio statistics.
>> > > 
>> > > This commit introduces the new helper function,
>> > > __split_folio_and_update_stats(), to gather all these tasks. This
>> > > consolidation improves modularity and is a necessary preparation step
>> > > for further cleanup and simplification of the surrounding folio
>> > > splitting logic.
>> > > 
>> > > Signed-off-by: Wei Yang <richard.weiyang@gmail.com>
>> > > Cc: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
>> > > Cc: Zi Yan <ziy@nvidia.com>
>> > > ---
>> > >    mm/huge_memory.c | 28 +++++++++++++++++-----------
>> > >    1 file changed, 17 insertions(+), 11 deletions(-)
>> > > 
>> > > diff --git a/mm/huge_memory.c b/mm/huge_memory.c
>> > > index c37fe6ad0c96..abde0f1aa8ff 100644
>> > > --- a/mm/huge_memory.c
>> > > +++ b/mm/huge_memory.c
>> > > @@ -3567,6 +3567,22 @@ static void __split_folio_to_order(struct folio *folio, int old_order,
>> > >    		ClearPageCompound(&folio->page);
>> > >    }
>> > > +static void __split_folio_and_update_stats(struct folio *folio, int old_order,
>> > > +		int new_order, bool is_anon)
>> > 
>> > Is there any good reason we want to pass things like "is_anon" instead of
>> > just querying it in that helper?
>> > 
>> 
>> The reason is during split, folio's attribute will not change. In
>> __split_unmapped_folio() it is queried and set as const.
>> 
>> Otherwise we need to query it on each split.
>
>These checks are extremely cheap. Do we really care?
>

Ok, will remove it.

>-- 
>Cheers
>
>David

-- 
Wei Yang
Help you, Help me

Re: [PATCH 0/2] mm/huge_memory: Modularize and simplify folio splitting paths

[Wei Yang]

On Sat, Nov 01, 2025 at 12:29:25AM +0000, Wei Yang wrote:
>This two-patch series focuses on refactoring the core logic of folio
>splitting to improve code structure, clarity, and maintainability.
>
>The first patch introduces a new consolidated helper function that groups
>all the required tasks involved in a folio split. The second patch then
>leverages this new helper to clearly separate the different execution
>paths for uniform and non-uniform splitting, which simplifies
>__split_unmapped_folio().
>
>This series sets a better foundation for future optimizations and
>maintenance in the huge memory handling code.
>
>Also selftests/split_huge_page_test pass.

Hi, Lorenzo , Zi

This patch set is based on your suggestion from [1].

Not sure you still like it?

[1]: http://lkml.kernel.org/r/f1830e4e-1630-4242-be0d-1cf65f20b54b@lucifer.local

>
>Wei Yang (2):
>  mm/huge_memory: introduce __split_folio_and_update_stats() to
>    consolidate split task
>  mm/huge_memory: separate uniform/non uniform split logic in
>    __split_unmapped_folio()
>
> mm/huge_memory.c | 59 +++++++++++++++++++++++++++---------------------
> 1 file changed, 33 insertions(+), 26 deletions(-)
>
>-- 
>2.34.1

-- 
Wei Yang
Help you, Help me

Re: [PATCH 0/2] mm/huge_memory: Modularize and simplify folio splitting paths

[Zi Yan]

On 6 Nov 2025, at 20:02, Wei Yang wrote:

> On Sat, Nov 01, 2025 at 12:29:25AM +0000, Wei Yang wrote:
>> This two-patch series focuses on refactoring the core logic of folio
>> splitting to improve code structure, clarity, and maintainability.
>>
>> The first patch introduces a new consolidated helper function that groups
>> all the required tasks involved in a folio split. The second patch then
>> leverages this new helper to clearly separate the different execution
>> paths for uniform and non-uniform splitting, which simplifies
>> __split_unmapped_folio().
>>
>> This series sets a better foundation for future optimizations and
>> maintenance in the huge memory handling code.
>>
>> Also selftests/split_huge_page_test pass.
>
> Hi, Lorenzo , Zi
>
> This patch set is based on your suggestion from [1].
>
> Not sure you still like it?
>
> [1]: http://lkml.kernel.org/r/f1830e4e-1630-4242-be0d-1cf65f20b54b@lucifer.local
>

Can you address David’s concern and update the patches?
I will take a look then.

Thanks.

>>
>> Wei Yang (2):
>>  mm/huge_memory: introduce __split_folio_and_update_stats() to
>>    consolidate split task
>>  mm/huge_memory: separate uniform/non uniform split logic in
>>    __split_unmapped_folio()
>>
>> mm/huge_memory.c | 59 +++++++++++++++++++++++++++---------------------
>> 1 file changed, 33 insertions(+), 26 deletions(-)
>>
>> -- 
>> 2.34.1
>
> -- 
> Wei Yang
> Help you, Help me


Best Regards,
Yan, Zi

Re: [PATCH 1/2] mm/huge_memory: introduce __split_folio_and_update_stats() to consolidate split task

[Wei Yang]

On Mon, Nov 03, 2025 at 05:22:10PM +0100, David Hildenbrand (Red Hat) wrote:
>On 03.11.25 17:21, David Hildenbrand (Red Hat) wrote:
>> On 03.11.25 17:20, David Hildenbrand (Red Hat) wrote:
>> > On 01.11.25 01:29, Wei Yang wrote:
>> > > The folio splitting process involves several related tasks that are
>> > > executed together:
>> > > 
>> > >        Adjusting memcg (memory control group) accounting.
>> > >        Updating page owner tracking.
>> > >        Splitting the folio to the target size (new_order).
>> > >        Updating necessary folio statistics.
>> > > 
>> > > This commit introduces the new helper function,
>> > > __split_folio_and_update_stats(), to gather all these tasks. This
>> > > consolidation improves modularity and is a necessary preparation step
>> > > for further cleanup and simplification of the surrounding folio
>> > > splitting logic.
>> > > 
>> > > Signed-off-by: Wei Yang <richard.weiyang@gmail.com>
>> > > Cc: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
>> > > Cc: Zi Yan <ziy@nvidia.com>
>> > > ---
>> > >     mm/huge_memory.c | 28 +++++++++++++++++-----------
>> > >     1 file changed, 17 insertions(+), 11 deletions(-)
>> > > 
>> > > diff --git a/mm/huge_memory.c b/mm/huge_memory.c
>> > > index c37fe6ad0c96..abde0f1aa8ff 100644
>> > > --- a/mm/huge_memory.c
>> > > +++ b/mm/huge_memory.c
>> > > @@ -3567,6 +3567,22 @@ static void __split_folio_to_order(struct folio *folio, int old_order,
>> > >     		ClearPageCompound(&folio->page);
>> > >     }
>> > > +static void __split_folio_and_update_stats(struct folio *folio, int old_order,
>> > > +		int new_order, bool is_anon)
>> > 
>> > Is there any good reason we want to pass things like "is_anon" instead
>> > of just querying it in that helper?
>> > 
>> > 
>> > > +{
>> > > +	int nr_new_folios = 1UL << (old_order - new_order);
>> > 
>> > Could be const.
>> > 
>> > 
>> 
>> Looking at it again, and that we are not reusing this function on patch
>> #2, I am not sure factoring this out is really helpful at this point?
>
>Ignore that, I was briefly confused by patch #2 :)
>

Hi, David

Would you mind be more specific on which part confuse you?

>-- 
>Cheers
>
>David

-- 
Wei Yang
Help you, Help me