linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] mm/hugetlb: remove redundant folio_test_hugetlb
@ 2025-05-23  8:05 yangge1116
  2025-05-23  8:23 ` Oscar Salvador
                   ` (2 more replies)
  0 siblings, 3 replies; 9+ messages in thread
From: yangge1116 @ 2025-05-23  8:05 UTC (permalink / raw)
  To: akpm
  Cc: linux-mm, linux-kernel, 21cnbao, david, baolin.wang, muchun.song,
	osalvador, liuzixing, Ge Yang

From: Ge Yang <yangge1116@126.com>

In the isolate_or_dissolve_huge_folio() function, the folio_test_hugetlb()
function is called to determine whether a folio is a hugetlb folio.
However, in the subsequent alloc_and_dissolve_hugetlb_folio() function,
the folio_test_hugetlb() function is called again to make the same
determination about whether the folio is a hugetlb folio. It appears that
the folio_test_hugetlb() check in the isolate_or_dissolve_huge_folio()
function can be removed. Additionally, a similar issue exists in the
replace_free_hugepage_folios() function, and it should be addressed as
well.

Suggested-by: Oscar Salvador <osalvador@suse.de>
Signed-off-by: Ge Yang <yangge1116@126.com>
---
 mm/hugetlb.c | 51 +++++++++++++--------------------------------------
 1 file changed, 13 insertions(+), 38 deletions(-)

diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 6c2e007..6e46f2f 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -2787,20 +2787,24 @@ void restore_reserve_on_error(struct hstate *h, struct vm_area_struct *vma,
 /*
  * alloc_and_dissolve_hugetlb_folio - Allocate a new folio and dissolve
  * the old one
- * @h: struct hstate old page belongs to
  * @old_folio: Old folio to dissolve
  * @list: List to isolate the page in case we need to
  * Returns 0 on success, otherwise negated error.
  */
-static int alloc_and_dissolve_hugetlb_folio(struct hstate *h,
-			struct folio *old_folio, struct list_head *list)
+static int alloc_and_dissolve_hugetlb_folio(struct folio *old_folio,
+			struct list_head *list)
 {
-	gfp_t gfp_mask = htlb_alloc_mask(h) | __GFP_THISNODE;
+	gfp_t gfp_mask;
+	struct hstate *h;
 	int nid = folio_nid(old_folio);
 	struct folio *new_folio = NULL;
 	int ret = 0;
 
 retry:
+	/*
+	 * The old_folio might have been dissolved from under our feet, so make sure
+	 * to carefully check the state under the lock.
+	 */
 	spin_lock_irq(&hugetlb_lock);
 	if (!folio_test_hugetlb(old_folio)) {
 		/*
@@ -2829,8 +2833,10 @@ static int alloc_and_dissolve_hugetlb_folio(struct hstate *h,
 		cond_resched();
 		goto retry;
 	} else {
+		h = folio_hstate(old_folio);
 		if (!new_folio) {
 			spin_unlock_irq(&hugetlb_lock);
+			gfp_mask = htlb_alloc_mask(h) | __GFP_THISNODE;
 			new_folio = alloc_buddy_hugetlb_folio(h, gfp_mask, nid,
 							      NULL, NULL);
 			if (!new_folio)
@@ -2874,35 +2880,20 @@ static int alloc_and_dissolve_hugetlb_folio(struct hstate *h,
 
 int isolate_or_dissolve_huge_folio(struct folio *folio, struct list_head *list)
 {
-	struct hstate *h;
 	int ret = -EBUSY;
 
 	/*
-	 * The page might have been dissolved from under our feet, so make sure
-	 * to carefully check the state under the lock.
-	 * Return success when racing as if we dissolved the page ourselves.
-	 */
-	spin_lock_irq(&hugetlb_lock);
-	if (folio_test_hugetlb(folio)) {
-		h = folio_hstate(folio);
-	} else {
-		spin_unlock_irq(&hugetlb_lock);
-		return 0;
-	}
-	spin_unlock_irq(&hugetlb_lock);
-
-	/*
 	 * Fence off gigantic pages as there is a cyclic dependency between
 	 * alloc_contig_range and them. Return -ENOMEM as this has the effect
 	 * of bailing out right away without further retrying.
 	 */
-	if (hstate_is_gigantic(h))
+	if (folio_order(folio) > MAX_PAGE_ORDER)
 		return -ENOMEM;
 
 	if (folio_ref_count(folio) && folio_isolate_hugetlb(folio, list))
 		ret = 0;
 	else if (!folio_ref_count(folio))
-		ret = alloc_and_dissolve_hugetlb_folio(h, folio, list);
+		ret = alloc_and_dissolve_hugetlb_folio(folio, list);
 
 	return ret;
 }
@@ -2916,7 +2907,6 @@ int isolate_or_dissolve_huge_folio(struct folio *folio, struct list_head *list)
  */
 int replace_free_hugepage_folios(unsigned long start_pfn, unsigned long end_pfn)
 {
-	struct hstate *h;
 	struct folio *folio;
 	int ret = 0;
 
@@ -2925,23 +2915,8 @@ int replace_free_hugepage_folios(unsigned long start_pfn, unsigned long end_pfn)
 	while (start_pfn < end_pfn) {
 		folio = pfn_folio(start_pfn);
 
-		/*
-		 * The folio might have been dissolved from under our feet, so make sure
-		 * to carefully check the state under the lock.
-		 */
-		spin_lock_irq(&hugetlb_lock);
-		if (folio_test_hugetlb(folio)) {
-			h = folio_hstate(folio);
-		} else {
-			spin_unlock_irq(&hugetlb_lock);
-			start_pfn++;
-			continue;
-		}
-		spin_unlock_irq(&hugetlb_lock);
-
 		if (!folio_ref_count(folio)) {
-			ret = alloc_and_dissolve_hugetlb_folio(h, folio,
-							       &isolate_list);
+			ret = alloc_and_dissolve_hugetlb_folio(folio, &isolate_list);
 			if (ret)
 				break;
 
-- 
2.7.4



^ permalink raw reply related	[flat|nested] 9+ messages in thread

* Re: [PATCH] mm/hugetlb: remove redundant folio_test_hugetlb
  2025-05-23  8:05 [PATCH] mm/hugetlb: remove redundant folio_test_hugetlb yangge1116
@ 2025-05-23  8:23 ` Oscar Salvador
  2025-05-23  8:30 ` Muchun Song
  2025-05-26 12:20 ` David Hildenbrand
  2 siblings, 0 replies; 9+ messages in thread
From: Oscar Salvador @ 2025-05-23  8:23 UTC (permalink / raw)
  To: yangge1116
  Cc: akpm, linux-mm, linux-kernel, 21cnbao, david, baolin.wang,
	muchun.song, liuzixing

On Fri, May 23, 2025 at 04:05:59PM +0800, yangge1116@126.com wrote:
> From: Ge Yang <yangge1116@126.com>
> 
> In the isolate_or_dissolve_huge_folio() function, the folio_test_hugetlb()
> function is called to determine whether a folio is a hugetlb folio.
> However, in the subsequent alloc_and_dissolve_hugetlb_folio() function,
> the folio_test_hugetlb() function is called again to make the same
> determination about whether the folio is a hugetlb folio. It appears that
> the folio_test_hugetlb() check in the isolate_or_dissolve_huge_folio()
> function can be removed. Additionally, a similar issue exists in the
> replace_free_hugepage_folios() function, and it should be addressed as
> well.
> 
> Suggested-by: Oscar Salvador <osalvador@suse.de>
> Signed-off-by: Ge Yang <yangge1116@126.com>

Acked-by: Oscar Salvador <osalvador@suse.de>


-- 
Oscar Salvador
SUSE Labs


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] mm/hugetlb: remove redundant folio_test_hugetlb
  2025-05-23  8:05 [PATCH] mm/hugetlb: remove redundant folio_test_hugetlb yangge1116
  2025-05-23  8:23 ` Oscar Salvador
@ 2025-05-23  8:30 ` Muchun Song
  2025-05-26 12:20 ` David Hildenbrand
  2 siblings, 0 replies; 9+ messages in thread
From: Muchun Song @ 2025-05-23  8:30 UTC (permalink / raw)
  To: yangge1116
  Cc: akpm, linux-mm, linux-kernel, 21cnbao, david, baolin.wang,
	osalvador, liuzixing



> On May 23, 2025, at 16:05, yangge1116@126.com wrote:
> 
> From: Ge Yang <yangge1116@126.com>
> 
> In the isolate_or_dissolve_huge_folio() function, the folio_test_hugetlb()
> function is called to determine whether a folio is a hugetlb folio.
> However, in the subsequent alloc_and_dissolve_hugetlb_folio() function,
> the folio_test_hugetlb() function is called again to make the same
> determination about whether the folio is a hugetlb folio. It appears that
> the folio_test_hugetlb() check in the isolate_or_dissolve_huge_folio()
> function can be removed. Additionally, a similar issue exists in the
> replace_free_hugepage_folios() function, and it should be addressed as
> well.
> 
> Suggested-by: Oscar Salvador <osalvador@suse.de>
> Signed-off-by: Ge Yang <yangge1116@126.com <mailto:yangge1116@126.com>>

Reviewed-by: Muchun Song <muchun.song@linux.dev>

Thanks.



^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] mm/hugetlb: remove redundant folio_test_hugetlb
  2025-05-23  8:05 [PATCH] mm/hugetlb: remove redundant folio_test_hugetlb yangge1116
  2025-05-23  8:23 ` Oscar Salvador
  2025-05-23  8:30 ` Muchun Song
@ 2025-05-26 12:20 ` David Hildenbrand
  2025-05-26 12:23   ` David Hildenbrand
  2 siblings, 1 reply; 9+ messages in thread
From: David Hildenbrand @ 2025-05-26 12:20 UTC (permalink / raw)
  To: yangge1116, akpm
  Cc: linux-mm, linux-kernel, 21cnbao, baolin.wang, muchun.song,
	osalvador, liuzixing

On 23.05.25 10:05, yangge1116@126.com wrote:
> From: Ge Yang <yangge1116@126.com>
> 
> In the isolate_or_dissolve_huge_folio() function, the folio_test_hugetlb()
> function is called to determine whether a folio is a hugetlb folio.
> However, in the subsequent alloc_and_dissolve_hugetlb_folio() function,
> the folio_test_hugetlb() function is called again to make the same
> determination about whether the folio is a hugetlb folio. It appears that
> the folio_test_hugetlb() check in the isolate_or_dissolve_huge_folio()
> function can be removed. Additionally, a similar issue exists in the
> replace_free_hugepage_folios() function, and it should be addressed as
> well.
> 
> Suggested-by: Oscar Salvador <osalvador@suse.de>
> Signed-off-by: Ge Yang <yangge1116@126.com>
> ---
>   mm/hugetlb.c | 51 +++++++++++++--------------------------------------
>   1 file changed, 13 insertions(+), 38 deletions(-)
> 
> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> index 6c2e007..6e46f2f 100644
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -2787,20 +2787,24 @@ void restore_reserve_on_error(struct hstate *h, struct vm_area_struct *vma,
>   /*
>    * alloc_and_dissolve_hugetlb_folio - Allocate a new folio and dissolve
>    * the old one
> - * @h: struct hstate old page belongs to
>    * @old_folio: Old folio to dissolve
>    * @list: List to isolate the page in case we need to
>    * Returns 0 on success, otherwise negated error.
>    */
> -static int alloc_and_dissolve_hugetlb_folio(struct hstate *h,
> -			struct folio *old_folio, struct list_head *list)
> +static int alloc_and_dissolve_hugetlb_folio(struct folio *old_folio,
> +			struct list_head *list)
>   {
> -	gfp_t gfp_mask = htlb_alloc_mask(h) | __GFP_THISNODE;
> +	gfp_t gfp_mask;
> +	struct hstate *h;
>   	int nid = folio_nid(old_folio);
>   	struct folio *new_folio = NULL;
>   	int ret = 0;
>   
>   retry:
> +	/*
> +	 * The old_folio might have been dissolved from under our feet, so make sure
> +	 * to carefully check the state under the lock.
> +	 */
>   	spin_lock_irq(&hugetlb_lock);
>   	if (!folio_test_hugetlb(old_folio)) {
>   		/*
> @@ -2829,8 +2833,10 @@ static int alloc_and_dissolve_hugetlb_folio(struct hstate *h,
>   		cond_resched();
>   		goto retry;
>   	} else {
> +		h = folio_hstate(old_folio);
>   		if (!new_folio) {
>   			spin_unlock_irq(&hugetlb_lock);
> +			gfp_mask = htlb_alloc_mask(h) | __GFP_THISNODE;
>   			new_folio = alloc_buddy_hugetlb_folio(h, gfp_mask, nid,
>   							      NULL, NULL);
>   			if (!new_folio)
> @@ -2874,35 +2880,20 @@ static int alloc_and_dissolve_hugetlb_folio(struct hstate *h,
>   
>   int isolate_or_dissolve_huge_folio(struct folio *folio, struct list_head *list)
>   {
> -	struct hstate *h;
>   	int ret = -EBUSY;
>   
>   	/*
> -	 * The page might have been dissolved from under our feet, so make sure
> -	 * to carefully check the state under the lock.
> -	 * Return success when racing as if we dissolved the page ourselves.
> -	 */
> -	spin_lock_irq(&hugetlb_lock);
> -	if (folio_test_hugetlb(folio)) {
> -		h = folio_hstate(folio);
> -	} else {
> -		spin_unlock_irq(&hugetlb_lock);
> -		return 0;
> -	}
> -	spin_unlock_irq(&hugetlb_lock);
> -
> -	/*
>   	 * Fence off gigantic pages as there is a cyclic dependency between
>   	 * alloc_contig_range and them. Return -ENOMEM as this has the effect
>   	 * of bailing out right away without further retrying.
>   	 */
> -	if (hstate_is_gigantic(h))
> +	if (folio_order(folio) > MAX_PAGE_ORDER)
>   		return -ENOMEM;
>   
>   	if (folio_ref_count(folio) && folio_isolate_hugetlb(folio, list))
>   		ret = 0;
>   	else if (!folio_ref_count(folio))
> -		ret = alloc_and_dissolve_hugetlb_folio(h, folio, list);
> +		ret = alloc_and_dissolve_hugetlb_folio(folio, list);
>   
>   	return ret;
>   }
> @@ -2916,7 +2907,6 @@ int isolate_or_dissolve_huge_folio(struct folio *folio, struct list_head *list)
>    */
>   int replace_free_hugepage_folios(unsigned long start_pfn, unsigned long end_pfn)
>   {
> -	struct hstate *h;
>   	struct folio *folio;
>   	int ret = 0;
>   
> @@ -2925,23 +2915,8 @@ int replace_free_hugepage_folios(unsigned long start_pfn, unsigned long end_pfn)
>   	while (start_pfn < end_pfn) {
>   		folio = pfn_folio(start_pfn);
>   
> -		/*
> -		 * The folio might have been dissolved from under our feet, so make sure
> -		 * to carefully check the state under the lock.
> -		 */
> -		spin_lock_irq(&hugetlb_lock);
> -		if (folio_test_hugetlb(folio)) {
> -			h = folio_hstate(folio);
> -		} else {
> -			spin_unlock_irq(&hugetlb_lock);
> -			start_pfn++;
> -			continue;
> -		}
> -		spin_unlock_irq(&hugetlb_lock);

^ oh my, that is bad code.

Taking the hugetlb_lock for each and ever page in the range.

Let me find that code and nack it.

> -
>   		if (!folio_ref_count(folio)) {
> -			ret = alloc_and_dissolve_hugetlb_folio(h, folio,
> -							       &isolate_list);
> +			ret = alloc_and_dissolve_hugetlb_folio(folio, &isolate_list);

And we're still doing that there now?

We *really* should have an early folio_test_hugetlb() check and skip 
whatever has no indication of being related to hugetlb.

-- 
Cheers,

David / dhildenb



^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] mm/hugetlb: remove redundant folio_test_hugetlb
  2025-05-26 12:20 ` David Hildenbrand
@ 2025-05-26 12:23   ` David Hildenbrand
  2025-05-26 13:05     ` Oscar Salvador
  0 siblings, 1 reply; 9+ messages in thread
From: David Hildenbrand @ 2025-05-26 12:23 UTC (permalink / raw)
  To: yangge1116, akpm
  Cc: linux-mm, linux-kernel, 21cnbao, baolin.wang, muchun.song,
	osalvador, liuzixing

On 26.05.25 14:20, David Hildenbrand wrote:
> On 23.05.25 10:05, yangge1116@126.com wrote:
>> From: Ge Yang <yangge1116@126.com>
>>
>> In the isolate_or_dissolve_huge_folio() function, the folio_test_hugetlb()
>> function is called to determine whether a folio is a hugetlb folio.
>> However, in the subsequent alloc_and_dissolve_hugetlb_folio() function,
>> the folio_test_hugetlb() function is called again to make the same
>> determination about whether the folio is a hugetlb folio. It appears that
>> the folio_test_hugetlb() check in the isolate_or_dissolve_huge_folio()
>> function can be removed. Additionally, a similar issue exists in the
>> replace_free_hugepage_folios() function, and it should be addressed as
>> well.
>>
>> Suggested-by: Oscar Salvador <osalvador@suse.de>
>> Signed-off-by: Ge Yang <yangge1116@126.com>
>> ---
>>    mm/hugetlb.c | 51 +++++++++++++--------------------------------------
>>    1 file changed, 13 insertions(+), 38 deletions(-)
>>
>> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
>> index 6c2e007..6e46f2f 100644
>> --- a/mm/hugetlb.c
>> +++ b/mm/hugetlb.c
>> @@ -2787,20 +2787,24 @@ void restore_reserve_on_error(struct hstate *h, struct vm_area_struct *vma,
>>    /*
>>     * alloc_and_dissolve_hugetlb_folio - Allocate a new folio and dissolve
>>     * the old one
>> - * @h: struct hstate old page belongs to
>>     * @old_folio: Old folio to dissolve
>>     * @list: List to isolate the page in case we need to
>>     * Returns 0 on success, otherwise negated error.
>>     */
>> -static int alloc_and_dissolve_hugetlb_folio(struct hstate *h,
>> -			struct folio *old_folio, struct list_head *list)
>> +static int alloc_and_dissolve_hugetlb_folio(struct folio *old_folio,
>> +			struct list_head *list)
>>    {
>> -	gfp_t gfp_mask = htlb_alloc_mask(h) | __GFP_THISNODE;
>> +	gfp_t gfp_mask;
>> +	struct hstate *h;
>>    	int nid = folio_nid(old_folio);
>>    	struct folio *new_folio = NULL;
>>    	int ret = 0;
>>    
>>    retry:
>> +	/*
>> +	 * The old_folio might have been dissolved from under our feet, so make sure
>> +	 * to carefully check the state under the lock.
>> +	 */
>>    	spin_lock_irq(&hugetlb_lock);
>>    	if (!folio_test_hugetlb(old_folio)) {
>>    		/*
>> @@ -2829,8 +2833,10 @@ static int alloc_and_dissolve_hugetlb_folio(struct hstate *h,
>>    		cond_resched();
>>    		goto retry;
>>    	} else {
>> +		h = folio_hstate(old_folio);
>>    		if (!new_folio) {
>>    			spin_unlock_irq(&hugetlb_lock);
>> +			gfp_mask = htlb_alloc_mask(h) | __GFP_THISNODE;
>>    			new_folio = alloc_buddy_hugetlb_folio(h, gfp_mask, nid,
>>    							      NULL, NULL);
>>    			if (!new_folio)
>> @@ -2874,35 +2880,20 @@ static int alloc_and_dissolve_hugetlb_folio(struct hstate *h,
>>    
>>    int isolate_or_dissolve_huge_folio(struct folio *folio, struct list_head *list)
>>    {
>> -	struct hstate *h;
>>    	int ret = -EBUSY;
>>    
>>    	/*
>> -	 * The page might have been dissolved from under our feet, so make sure
>> -	 * to carefully check the state under the lock.
>> -	 * Return success when racing as if we dissolved the page ourselves.
>> -	 */
>> -	spin_lock_irq(&hugetlb_lock);
>> -	if (folio_test_hugetlb(folio)) {
>> -		h = folio_hstate(folio);
>> -	} else {
>> -		spin_unlock_irq(&hugetlb_lock);
>> -		return 0;
>> -	}
>> -	spin_unlock_irq(&hugetlb_lock);
>> -
>> -	/*
>>    	 * Fence off gigantic pages as there is a cyclic dependency between
>>    	 * alloc_contig_range and them. Return -ENOMEM as this has the effect
>>    	 * of bailing out right away without further retrying.
>>    	 */
>> -	if (hstate_is_gigantic(h))
>> +	if (folio_order(folio) > MAX_PAGE_ORDER)
>>    		return -ENOMEM;
>>    
>>    	if (folio_ref_count(folio) && folio_isolate_hugetlb(folio, list))
>>    		ret = 0;
>>    	else if (!folio_ref_count(folio))
>> -		ret = alloc_and_dissolve_hugetlb_folio(h, folio, list);
>> +		ret = alloc_and_dissolve_hugetlb_folio(folio, list);
>>    
>>    	return ret;
>>    }
>> @@ -2916,7 +2907,6 @@ int isolate_or_dissolve_huge_folio(struct folio *folio, struct list_head *list)
>>     */
>>    int replace_free_hugepage_folios(unsigned long start_pfn, unsigned long end_pfn)
>>    {
>> -	struct hstate *h;
>>    	struct folio *folio;
>>    	int ret = 0;
>>    
>> @@ -2925,23 +2915,8 @@ int replace_free_hugepage_folios(unsigned long start_pfn, unsigned long end_pfn)
>>    	while (start_pfn < end_pfn) {
>>    		folio = pfn_folio(start_pfn);
>>    
>> -		/*
>> -		 * The folio might have been dissolved from under our feet, so make sure
>> -		 * to carefully check the state under the lock.
>> -		 */
>> -		spin_lock_irq(&hugetlb_lock);
>> -		if (folio_test_hugetlb(folio)) {
>> -			h = folio_hstate(folio);
>> -		} else {
>> -			spin_unlock_irq(&hugetlb_lock);
>> -			start_pfn++;
>> -			continue;
>> -		}
>> -		spin_unlock_irq(&hugetlb_lock);
> 
> ^ oh my, that is bad code.
> 
> Taking the hugetlb_lock for each and ever page in the range.
> 
> Let me find that code and nack it.

Already in 6.15, gah.

Please convert that code to never ever take any hugeglb locks unless we 
are clearly dealing with a hugetlb folios.

-- 
Cheers,

David / dhildenb



^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] mm/hugetlb: remove redundant folio_test_hugetlb
  2025-05-26 12:23   ` David Hildenbrand
@ 2025-05-26 13:05     ` Oscar Salvador
  2025-05-26 13:06       ` David Hildenbrand
  0 siblings, 1 reply; 9+ messages in thread
From: Oscar Salvador @ 2025-05-26 13:05 UTC (permalink / raw)
  To: David Hildenbrand
  Cc: yangge1116, akpm, linux-mm, linux-kernel, 21cnbao, baolin.wang,
	muchun.song, liuzixing

On Mon, May 26, 2025 at 02:23:58PM +0200, David Hildenbrand wrote:
> Already in 6.15, gah.
> 
> Please convert that code to never ever take any hugeglb locks unless we are
> clearly dealing with a hugetlb folios.

I guess we could just do?

 diff --git a/mm/hugetlb.c b/mm/hugetlb.c
 index 20f08de9e37d..8bd8b950e4cb 100644
 --- a/mm/hugetlb.c
 +++ b/mm/hugetlb.c
 @@ -2911,7 +2914,7 @@ int replace_free_hugepage_folios(unsigned long start_pfn, unsigned long end_pfn)
  	while (start_pfn < end_pfn) {
  		folio = pfn_folio(start_pfn);
 
 -		if (!folio_ref_count(folio)) {
 +		if (!folio_ref_count(folio) && folio_test_hugetlb(folio)) {
  			ret = alloc_and_dissolve_hugetlb_folio(folio,
  							       &isolate_list);
  			if (ret)
 
 

-- 
Oscar Salvador
SUSE Labs


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] mm/hugetlb: remove redundant folio_test_hugetlb
  2025-05-26 13:05     ` Oscar Salvador
@ 2025-05-26 13:06       ` David Hildenbrand
  2025-05-26 13:09         ` Oscar Salvador
  2025-05-26 13:10         ` Ge Yang
  0 siblings, 2 replies; 9+ messages in thread
From: David Hildenbrand @ 2025-05-26 13:06 UTC (permalink / raw)
  To: Oscar Salvador
  Cc: yangge1116, akpm, linux-mm, linux-kernel, 21cnbao, baolin.wang,
	muchun.song, liuzixing

On 26.05.25 15:05, Oscar Salvador wrote:
> On Mon, May 26, 2025 at 02:23:58PM +0200, David Hildenbrand wrote:
>> Already in 6.15, gah.
>>
>> Please convert that code to never ever take any hugeglb locks unless we are
>> clearly dealing with a hugetlb folios.
> 
> I guess we could just do?

Yes, anything that involves hugetlb only id there is an indication of 
... hugetlb :)

-- 
Cheers,

David / dhildenb



^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] mm/hugetlb: remove redundant folio_test_hugetlb
  2025-05-26 13:06       ` David Hildenbrand
@ 2025-05-26 13:09         ` Oscar Salvador
  2025-05-26 13:10         ` Ge Yang
  1 sibling, 0 replies; 9+ messages in thread
From: Oscar Salvador @ 2025-05-26 13:09 UTC (permalink / raw)
  To: David Hildenbrand
  Cc: yangge1116, akpm, linux-mm, linux-kernel, 21cnbao, baolin.wang,
	muchun.song, liuzixing

On Mon, May 26, 2025 at 03:06:41PM +0200, David Hildenbrand wrote:
> Yes, anything that involves hugetlb only id there is an indication of ...
> hugetlb :)

Yes, I guess that after weeks of only seeing hugetlb code I became
convinced everything is hugetlb :-D.

I will send a patch later today unless no one beats me before.

Thanks for noticing!


-- 
Oscar Salvador
SUSE Labs


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] mm/hugetlb: remove redundant folio_test_hugetlb
  2025-05-26 13:06       ` David Hildenbrand
  2025-05-26 13:09         ` Oscar Salvador
@ 2025-05-26 13:10         ` Ge Yang
  1 sibling, 0 replies; 9+ messages in thread
From: Ge Yang @ 2025-05-26 13:10 UTC (permalink / raw)
  To: David Hildenbrand, Oscar Salvador
  Cc: akpm, linux-mm, linux-kernel, 21cnbao, baolin.wang, muchun.song,
	liuzixing



在 2025/5/26 21:06, David Hildenbrand 写道:
> On 26.05.25 15:05, Oscar Salvador wrote:
>> On Mon, May 26, 2025 at 02:23:58PM +0200, David Hildenbrand wrote:
>>> Already in 6.15, gah.
>>>
>>> Please convert that code to never ever take any hugeglb locks unless 
>>> we are
>>> clearly dealing with a hugetlb folios.
>>
>> I guess we could just do?
> 
> Yes, anything that involves hugetlb only id there is an indication 
> of ... hugetlb :)
> 

Okay, thanks. I'll adjust the patch again.



^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2025-05-26 13:11 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-05-23  8:05 [PATCH] mm/hugetlb: remove redundant folio_test_hugetlb yangge1116
2025-05-23  8:23 ` Oscar Salvador
2025-05-23  8:30 ` Muchun Song
2025-05-26 12:20 ` David Hildenbrand
2025-05-26 12:23   ` David Hildenbrand
2025-05-26 13:05     ` Oscar Salvador
2025-05-26 13:06       ` David Hildenbrand
2025-05-26 13:09         ` Oscar Salvador
2025-05-26 13:10         ` Ge Yang

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).