mm/khugepaged: minor cleanups

[PATCH 1/3] mm/khugepaged: remove unnecessary goto 'skip' label

Posted by Shivank Garg 1 month, 3 weeks ago

Replace 'goto skip' with actual logic for better code readability.

No functional change.

Signed-off-by: Shivank Garg <shivankg@amd.com>
---
 mm/khugepaged.c | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/mm/khugepaged.c b/mm/khugepaged.c
index 6c8c35d3e0c9..107146f012b1 100644
--- a/mm/khugepaged.c
+++ b/mm/khugepaged.c
@@ -2442,14 +2442,15 @@ static unsigned int khugepaged_scan_mm_slot(unsigned int pages, int *result,
 			break;
 		}
 		if (!thp_vma_allowable_order(vma, vma->vm_flags, TVA_KHUGEPAGED, PMD_ORDER)) {
-skip:
 			progress++;
 			continue;
 		}
 		hstart = round_up(vma->vm_start, HPAGE_PMD_SIZE);
 		hend = round_down(vma->vm_end, HPAGE_PMD_SIZE);
-		if (khugepaged_scan.address > hend)
-			goto skip;
+		if (khugepaged_scan.address > hend) {
+			progress++;
+			continue;
+		}
 		if (khugepaged_scan.address < hstart)
 			khugepaged_scan.address = hstart;
 		VM_BUG_ON(khugepaged_scan.address & ~HPAGE_PMD_MASK);
-- 
2.43.0

Re: [PATCH 1/3] mm/khugepaged: remove unnecessary goto 'skip' label

Posted by Liam R. Howlett 1 month, 3 weeks ago

* Shivank Garg <shivankg@amd.com> [251216 06:12]:
> Replace 'goto skip' with actual logic for better code readability.
> 
> No functional change.
> 
> Signed-off-by: Shivank Garg <shivankg@amd.com>

Reviewed-by: Liam R. Howlett <Liam.Howlett@oracle.com>

> ---
>  mm/khugepaged.c | 7 ++++---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/mm/khugepaged.c b/mm/khugepaged.c
> index 6c8c35d3e0c9..107146f012b1 100644
> --- a/mm/khugepaged.c
> +++ b/mm/khugepaged.c
> @@ -2442,14 +2442,15 @@ static unsigned int khugepaged_scan_mm_slot(unsigned int pages, int *result,
>  			break;
>  		}
>  		if (!thp_vma_allowable_order(vma, vma->vm_flags, TVA_KHUGEPAGED, PMD_ORDER)) {
> -skip:
>  			progress++;
>  			continue;
>  		}
>  		hstart = round_up(vma->vm_start, HPAGE_PMD_SIZE);
>  		hend = round_down(vma->vm_end, HPAGE_PMD_SIZE);
> -		if (khugepaged_scan.address > hend)
> -			goto skip;
> +		if (khugepaged_scan.address > hend) {
> +			progress++;
> +			continue;
> +		}
>  		if (khugepaged_scan.address < hstart)
>  			khugepaged_scan.address = hstart;
>  		VM_BUG_ON(khugepaged_scan.address & ~HPAGE_PMD_MASK);
> -- 
> 2.43.0
>

Re: [PATCH 1/3] mm/khugepaged: remove unnecessary goto 'skip' label

Posted by David Hildenbrand (Red Hat) 1 month, 3 weeks ago

On 12/16/25 12:11, Shivank Garg wrote:
> Replace 'goto skip' with actual logic for better code readability.
> 
> No functional change.
> 
> Signed-off-by: Shivank Garg <shivankg@amd.com>
> ---
>   mm/khugepaged.c | 7 ++++---
>   1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/mm/khugepaged.c b/mm/khugepaged.c
> index 6c8c35d3e0c9..107146f012b1 100644
> --- a/mm/khugepaged.c
> +++ b/mm/khugepaged.c
> @@ -2442,14 +2442,15 @@ static unsigned int khugepaged_scan_mm_slot(unsigned int pages, int *result,
>   			break;
>   		}
>   		if (!thp_vma_allowable_order(vma, vma->vm_flags, TVA_KHUGEPAGED, PMD_ORDER)) {
> -skip:
>   			progress++;
>   			continue;
>   		}
>   		hstart = round_up(vma->vm_start, HPAGE_PMD_SIZE);
>   		hend = round_down(vma->vm_end, HPAGE_PMD_SIZE);
> -		if (khugepaged_scan.address > hend)
> -			goto skip;
> +		if (khugepaged_scan.address > hend) {
> +			progress++;
> +			continue;
> +		}
>   		if (khugepaged_scan.address < hstart)
>   			khugepaged_scan.address = hstart;
>   		VM_BUG_ON(khugepaged_scan.address & ~HPAGE_PMD_MASK);

Oh yes, please

Acked-by: David Hildenbrand (Red Hat) <david@kernel.org>

-- 
Cheers

David

Re: [PATCH 1/3] mm/khugepaged: remove unnecessary goto 'skip' label

Posted by Wei Yang 1 month, 3 weeks ago

On Tue, Dec 16, 2025 at 11:11:38AM +0000, Shivank Garg wrote:
>Replace 'goto skip' with actual logic for better code readability.
>
>No functional change.
>
>Signed-off-by: Shivank Garg <shivankg@amd.com>
>---
> mm/khugepaged.c | 7 ++++---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
>diff --git a/mm/khugepaged.c b/mm/khugepaged.c
>index 6c8c35d3e0c9..107146f012b1 100644
>--- a/mm/khugepaged.c
>+++ b/mm/khugepaged.c
>@@ -2442,14 +2442,15 @@ static unsigned int khugepaged_scan_mm_slot(unsigned int pages, int *result,
> 			break;
> 		}
> 		if (!thp_vma_allowable_order(vma, vma->vm_flags, TVA_KHUGEPAGED, PMD_ORDER)) {
>-skip:
> 			progress++;
> 			continue;
> 		}
> 		hstart = round_up(vma->vm_start, HPAGE_PMD_SIZE);
> 		hend = round_down(vma->vm_end, HPAGE_PMD_SIZE);
>-		if (khugepaged_scan.address > hend)
>-			goto skip;
>+		if (khugepaged_scan.address > hend) {
>+			progress++;
>+			continue;
>+		}

Hi, Shivank

The change here looks good, while I come up with an question.

The @progress here seems record two things:

  * number of pages scaned
  * number of vma skipped

While in very rare case, we may miss to count the second case.

For example, we have following vmas in a process:

     vma1             vma2
    +----------------+------------+
    |2M              |1M          |
    +----------------+------------+

Let's assume vma1 is exactly HPAGE_PMD_SIZE and also HPAGE_PMD_SIZE aligned.
But vma2 is only half of HPAGE_PMD_SIZE.

When scan finish vma1 and start on vma2, we would have hstart = hend =
address. So we continue here but would not do real scan, since address == hend.

I am thinking whether this could handle it:

		if (khugepaged_scan.address > hend || hend <= hstart) {
			progress++;
			continue;
		}

Do you thinks I am correct on this?

> 		if (khugepaged_scan.address < hstart)
> 			khugepaged_scan.address = hstart;
> 		VM_BUG_ON(khugepaged_scan.address & ~HPAGE_PMD_MASK);
>-- 
>2.43.0
>

-- 
Wei Yang
Help you, Help me

Re: [PATCH 1/3] mm/khugepaged: remove unnecessary goto 'skip' label

Posted by Garg, Shivank 1 month, 3 weeks ago


On 12/17/2025 8:18 AM, Wei Yang wrote:
> On Tue, Dec 16, 2025 at 11:11:38AM +0000, Shivank Garg wrote:
>> Replace 'goto skip' with actual logic for better code readability.
>>
>> No functional change.
>>
>> Signed-off-by: Shivank Garg <shivankg@amd.com>
>> ---
>> mm/khugepaged.c | 7 ++++---
>> 1 file changed, 4 insertions(+), 3 deletions(-)
>>
>> diff --git a/mm/khugepaged.c b/mm/khugepaged.c
>> index 6c8c35d3e0c9..107146f012b1 100644
>> --- a/mm/khugepaged.c
>> +++ b/mm/khugepaged.c
>> @@ -2442,14 +2442,15 @@ static unsigned int khugepaged_scan_mm_slot(unsigned int pages, int *result,
>> 			break;
>> 		}
>> 		if (!thp_vma_allowable_order(vma, vma->vm_flags, TVA_KHUGEPAGED, PMD_ORDER)) {
>> -skip:
>> 			progress++;
>> 			continue;
>> 		}
>> 		hstart = round_up(vma->vm_start, HPAGE_PMD_SIZE);
>> 		hend = round_down(vma->vm_end, HPAGE_PMD_SIZE);
>> -		if (khugepaged_scan.address > hend)
>> -			goto skip;
>> +		if (khugepaged_scan.address > hend) {
>> +			progress++;
>> +			continue;
>> +		}
> 
> Hi, Shivank
> 
> The change here looks good, while I come up with an question.
> 
> The @progress here seems record two things:
> 
>   * number of pages scaned
>   * number of vma skipped
> 
Three things: number of mm. It's incremented 1 for whole khugepaged_scan_mm_slot().


> While in very rare case, we may miss to count the second case.
> 
> For example, we have following vmas in a process:
> 
>      vma1             vma2
>     +----------------+------------+
>     |2M              |1M          |
>     +----------------+------------+
> 
> Let's assume vma1 is exactly HPAGE_PMD_SIZE and also HPAGE_PMD_SIZE aligned.
> But vma2 is only half of HPAGE_PMD_SIZE.
> 
> When scan finish vma1 and start on vma2, we would have hstart = hend =
> address. So we continue here but would not do real scan, since address == hend.
> 
> I am thinking whether this could handle it:
> 
> 		if (khugepaged_scan.address > hend || hend <= hstart) {
> 			progress++;
> 			continue;
> 		}
> 
> Do you thinks I am correct on this?

I think you're correct.
IIUC, @progress acts as rate limiter here.

It is increasing +1 for whole, and then increases by +1 per VMA (if skipped),
or by +HPAGE_PMD_NR (if actually scanned).

So, progress ensuring the hugepaged_do_scan run only until (progress >= pages)
at which point it yields and sleeps (wait_event_freezable).

Without your suggested fix, if a process contains a large number of small VMAs (where
round_up hstart >= round_down(hend), it will unfairly consume more CPU cycles before
yielding compared to a process with fewer or aligned VMAs.

I think your suggestion is ensuring fairness by charging 'progress' count correctly.

Thanks,
Shivank

Re: [PATCH 1/3] mm/khugepaged: remove unnecessary goto 'skip' label

Posted by Wei Yang 1 month, 2 weeks ago

On Fri, Dec 19, 2025 at 02:54:40PM +0530, Garg, Shivank wrote:
>
>
>On 12/17/2025 8:18 AM, Wei Yang wrote:
>> On Tue, Dec 16, 2025 at 11:11:38AM +0000, Shivank Garg wrote:
>>> Replace 'goto skip' with actual logic for better code readability.
>>>
>>> No functional change.
>>>
>>> Signed-off-by: Shivank Garg <shivankg@amd.com>
>>> ---
>>> mm/khugepaged.c | 7 ++++---
>>> 1 file changed, 4 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/mm/khugepaged.c b/mm/khugepaged.c
>>> index 6c8c35d3e0c9..107146f012b1 100644
>>> --- a/mm/khugepaged.c
>>> +++ b/mm/khugepaged.c
>>> @@ -2442,14 +2442,15 @@ static unsigned int khugepaged_scan_mm_slot(unsigned int pages, int *result,
>>> 			break;
>>> 		}
>>> 		if (!thp_vma_allowable_order(vma, vma->vm_flags, TVA_KHUGEPAGED, PMD_ORDER)) {
>>> -skip:
>>> 			progress++;
>>> 			continue;
>>> 		}
>>> 		hstart = round_up(vma->vm_start, HPAGE_PMD_SIZE);
>>> 		hend = round_down(vma->vm_end, HPAGE_PMD_SIZE);
>>> -		if (khugepaged_scan.address > hend)
>>> -			goto skip;
>>> +		if (khugepaged_scan.address > hend) {
>>> +			progress++;
>>> +			continue;
>>> +		}
>> 
>> Hi, Shivank
>> 
>> The change here looks good, while I come up with an question.
>> 
>> The @progress here seems record two things:
>> 
>>   * number of pages scaned
>>   * number of vma skipped
>> 
>Three things: number of mm. It's incremented 1 for whole khugepaged_scan_mm_slot().
>

Agree.

>
>> While in very rare case, we may miss to count the second case.
>> 
>> For example, we have following vmas in a process:
>> 
>>      vma1             vma2
>>     +----------------+------------+
>>     |2M              |1M          |
>>     +----------------+------------+
>> 
>> Let's assume vma1 is exactly HPAGE_PMD_SIZE and also HPAGE_PMD_SIZE aligned.
>> But vma2 is only half of HPAGE_PMD_SIZE.
>> 
>> When scan finish vma1 and start on vma2, we would have hstart = hend =
>> address. So we continue here but would not do real scan, since address == hend.
>> 
>> I am thinking whether this could handle it:
>> 
>> 		if (khugepaged_scan.address > hend || hend <= hstart) {
>> 			progress++;
>> 			continue;
>> 		}
>> 
>> Do you thinks I am correct on this?
>
>I think you're correct.
>IIUC, @progress acts as rate limiter here.
>
>It is increasing +1 for whole, and then increases by +1 per VMA (if skipped),
>or by +HPAGE_PMD_NR (if actually scanned).
>
>So, progress ensuring the hugepaged_do_scan run only until (progress >= pages)
>at which point it yields and sleeps (wait_event_freezable).
>
>Without your suggested fix, if a process contains a large number of small VMAs (where
>round_up hstart >= round_down(hend), it will unfairly consume more CPU cycles before
>yielding compared to a process with fewer or aligned VMAs.

You are right. While I am not sure it exists in reality, but in theory it
could be.

>
>I think your suggestion is ensuring fairness by charging 'progress' count correctly.
>

Thanks for your confirmation. Would you mind add a cleanup in next version, or
you prefer me to send it :-)

>Thanks,
>Shivank

-- 
Wei Yang
Help you, Help me

Re: [PATCH 1/3] mm/khugepaged: remove unnecessary goto 'skip' label

Posted by Garg, Shivank 1 month, 2 weeks ago


On 12/20/2025 6:08 AM, Wei Yang wrote:
> On Fri, Dec 19, 2025 at 02:54:40PM +0530, Garg, Shivank wrote:
>>
>>
>> On 12/17/2025 8:18 AM, Wei Yang wrote:
>>> On Tue, Dec 16, 2025 at 11:11:38AM +0000, Shivank Garg wrote:
>>>> Replace 'goto skip' with actual logic for better code readability.
>>>>
>>>> No functional change.
>>>>
>>>> Signed-off-by: Shivank Garg <shivankg@amd.com>
>>>> ---
>>>> mm/khugepaged.c | 7 ++++---
>>>> 1 file changed, 4 insertions(+), 3 deletions(-)
>>>>
>>>> diff --git a/mm/khugepaged.c b/mm/khugepaged.c
>>>> index 6c8c35d3e0c9..107146f012b1 100644
>>>> --- a/mm/khugepaged.c
>>>> +++ b/mm/khugepaged.c
>>>> @@ -2442,14 +2442,15 @@ static unsigned int khugepaged_scan_mm_slot(unsigned int pages, int *result,
>>>> 			break;
>>>> 		}
>>>> 		if (!thp_vma_allowable_order(vma, vma->vm_flags, TVA_KHUGEPAGED, PMD_ORDER)) {
>>>> -skip:
>>>> 			progress++;
>>>> 			continue;
>>>> 		}
>>>> 		hstart = round_up(vma->vm_start, HPAGE_PMD_SIZE);
>>>> 		hend = round_down(vma->vm_end, HPAGE_PMD_SIZE);
>>>> -		if (khugepaged_scan.address > hend)
>>>> -			goto skip;
>>>> +		if (khugepaged_scan.address > hend) {
>>>> +			progress++;
>>>> +			continue;
>>>> +		}
>>>
>>> Hi, Shivank
>>>
>>> The change here looks good, while I come up with an question.
>>>
>>> The @progress here seems record two things:
>>>
>>>   * number of pages scaned
>>>   * number of vma skipped
>>>
>> Three things: number of mm. It's incremented 1 for whole khugepaged_scan_mm_slot().
>>
> 
> Agree.
> 
>>
>>> While in very rare case, we may miss to count the second case.
>>>
>>> For example, we have following vmas in a process:
>>>
>>>      vma1             vma2
>>>     +----------------+------------+
>>>     |2M              |1M          |
>>>     +----------------+------------+
>>>
>>> Let's assume vma1 is exactly HPAGE_PMD_SIZE and also HPAGE_PMD_SIZE aligned.
>>> But vma2 is only half of HPAGE_PMD_SIZE.
>>>
>>> When scan finish vma1 and start on vma2, we would have hstart = hend =
>>> address. So we continue here but would not do real scan, since address == hend.
>>>
>>> I am thinking whether this could handle it:
>>>
>>> 		if (khugepaged_scan.address > hend || hend <= hstart) {
>>> 			progress++;
>>> 			continue;
>>> 		}
>>>
>>> Do you thinks I am correct on this?
>>
>> I think you're correct.
>> IIUC, @progress acts as rate limiter here.
>>
>> It is increasing +1 for whole, and then increases by +1 per VMA (if skipped),
>> or by +HPAGE_PMD_NR (if actually scanned).
>>
>> So, progress ensuring the hugepaged_do_scan run only until (progress >= pages)
>> at which point it yields and sleeps (wait_event_freezable).
>>
>> Without your suggested fix, if a process contains a large number of small VMAs (where
>> round_up hstart >= round_down(hend), it will unfairly consume more CPU cycles before
>> yielding compared to a process with fewer or aligned VMAs.
> 
> You are right. While I am not sure it exists in reality, but in theory it
> could be.
> 
>>
>> I think your suggestion is ensuring fairness by charging 'progress' count correctly.
>>
> 
> Thanks for your confirmation. Would you mind add a cleanup in next version, or
> you prefer me to send it :-)

Sure, I'll add this fix patch in the next version.

Thanks,
Shivank

Re: [PATCH 1/3] mm/khugepaged: remove unnecessary goto 'skip' label

Posted by Wei Yang 1 month, 2 weeks ago

On Sun, Dec 21, 2025 at 12:02:11AM +0530, Garg, Shivank wrote:
>
>
>On 12/20/2025 6:08 AM, Wei Yang wrote:
>> On Fri, Dec 19, 2025 at 02:54:40PM +0530, Garg, Shivank wrote:
>>>
>>>
>>> On 12/17/2025 8:18 AM, Wei Yang wrote:
>>>> On Tue, Dec 16, 2025 at 11:11:38AM +0000, Shivank Garg wrote:
>>>>> Replace 'goto skip' with actual logic for better code readability.
>>>>>
>>>>> No functional change.
>>>>>
>>>>> Signed-off-by: Shivank Garg <shivankg@amd.com>
>>>>> ---
>>>>> mm/khugepaged.c | 7 ++++---
>>>>> 1 file changed, 4 insertions(+), 3 deletions(-)
>>>>>
>>>>> diff --git a/mm/khugepaged.c b/mm/khugepaged.c
>>>>> index 6c8c35d3e0c9..107146f012b1 100644
>>>>> --- a/mm/khugepaged.c
>>>>> +++ b/mm/khugepaged.c
>>>>> @@ -2442,14 +2442,15 @@ static unsigned int khugepaged_scan_mm_slot(unsigned int pages, int *result,
>>>>> 			break;
>>>>> 		}
>>>>> 		if (!thp_vma_allowable_order(vma, vma->vm_flags, TVA_KHUGEPAGED, PMD_ORDER)) {
>>>>> -skip:
>>>>> 			progress++;
>>>>> 			continue;
>>>>> 		}
>>>>> 		hstart = round_up(vma->vm_start, HPAGE_PMD_SIZE);
>>>>> 		hend = round_down(vma->vm_end, HPAGE_PMD_SIZE);
>>>>> -		if (khugepaged_scan.address > hend)
>>>>> -			goto skip;
>>>>> +		if (khugepaged_scan.address > hend) {
>>>>> +			progress++;
>>>>> +			continue;
>>>>> +		}
>>>>
>>>> Hi, Shivank
>>>>
>>>> The change here looks good, while I come up with an question.
>>>>
>>>> The @progress here seems record two things:
>>>>
>>>>   * number of pages scaned
>>>>   * number of vma skipped
>>>>
>>> Three things: number of mm. It's incremented 1 for whole khugepaged_scan_mm_slot().
>>>
>> 
>> Agree.
>> 
>>>
>>>> While in very rare case, we may miss to count the second case.
>>>>
>>>> For example, we have following vmas in a process:
>>>>
>>>>      vma1             vma2
>>>>     +----------------+------------+
>>>>     |2M              |1M          |
>>>>     +----------------+------------+
>>>>
>>>> Let's assume vma1 is exactly HPAGE_PMD_SIZE and also HPAGE_PMD_SIZE aligned.
>>>> But vma2 is only half of HPAGE_PMD_SIZE.
>>>>
>>>> When scan finish vma1 and start on vma2, we would have hstart = hend =
>>>> address. So we continue here but would not do real scan, since address == hend.
>>>>
>>>> I am thinking whether this could handle it:
>>>>
>>>> 		if (khugepaged_scan.address > hend || hend <= hstart) {
>>>> 			progress++;
>>>> 			continue;
>>>> 		}
>>>>
>>>> Do you thinks I am correct on this?
>>>
>>> I think you're correct.
>>> IIUC, @progress acts as rate limiter here.
>>>
>>> It is increasing +1 for whole, and then increases by +1 per VMA (if skipped),
>>> or by +HPAGE_PMD_NR (if actually scanned).
>>>
>>> So, progress ensuring the hugepaged_do_scan run only until (progress >= pages)
>>> at which point it yields and sleeps (wait_event_freezable).
>>>
>>> Without your suggested fix, if a process contains a large number of small VMAs (where
>>> round_up hstart >= round_down(hend), it will unfairly consume more CPU cycles before
>>> yielding compared to a process with fewer or aligned VMAs.
>> 
>> You are right. While I am not sure it exists in reality, but in theory it
>> could be.
>> 
>>>
>>> I think your suggestion is ensuring fairness by charging 'progress' count correctly.
>>>
>> 
>> Thanks for your confirmation. Would you mind add a cleanup in next version, or
>> you prefer me to send it :-)
>
>Sure, I'll add this fix patch in the next version.
>

Thanks

>Thanks,
>Shivank

-- 
Wei Yang
Help you, Help me

Re: [PATCH 1/3] mm/khugepaged: remove unnecessary goto 'skip' label

Posted by Zi Yan 1 month, 3 weeks ago

On 16 Dec 2025, at 6:11, Shivank Garg wrote:

> Replace 'goto skip' with actual logic for better code readability.
>
> No functional change.
>
> Signed-off-by: Shivank Garg <shivankg@amd.com>
> ---
>  mm/khugepaged.c | 7 ++++---
>  1 file changed, 4 insertions(+), 3 deletions(-)
>
LGTM. Reviewed-by: Zi Yan <ziy@nvidia.com>

Best Regards,
Yan, Zi

Re: [PATCH 1/3] mm/khugepaged: remove unnecessary goto 'skip' label

Posted by Garg, Shivank 1 month, 3 weeks ago

On 12/16/2025 8:57 PM, Zi Yan wrote:
> On 16 Dec 2025, at 6:11, Shivank Garg wrote:
> 
>> Replace 'goto skip' with actual logic for better code readability.
>>
>> No functional change.
>>
>> Signed-off-by: Shivank Garg <shivankg@amd.com>
>> ---
>>  mm/khugepaged.c | 7 ++++---
>>  1 file changed, 4 insertions(+), 3 deletions(-)
>>
> LGTM. Reviewed-by: Zi Yan <ziy@nvidia.com>
> 

Hi Zi,

I noticed that b4 didn't pick up your Reviewed-by tag automatically (possibly because
it was on the same line as "LGTM."). Just thought I'd mention it in case it's helpful,
Since maintainers may be using b4 or similar tools and your tags might occasionally
get missed.

Of course, I'll make sure to add your tag manually when sending v2.

Thanks,
Shivank

Re: [PATCH 1/3] mm/khugepaged: remove unnecessary goto 'skip' label

Posted by Konstantin Ryabitsev 1 month, 3 weeks ago

On Fri, Dec 19, 2025 at 05:50:39PM +0530, Garg, Shivank wrote:
> I noticed that b4 didn't pick up your Reviewed-by tag automatically (possibly because
> it was on the same line as "LGTM.").

That is correct -- code review trailers must always be on a separate line for
any tooling to properly recognize them.

Best regards,
-K

Re: [PATCH 1/3] mm/khugepaged: remove unnecessary goto 'skip' label

Posted by Zi Yan 1 month, 3 weeks ago

On 19 Dec 2025, at 11:00, Konstantin Ryabitsev wrote:

> On Fri, Dec 19, 2025 at 05:50:39PM +0530, Garg, Shivank wrote:
>> I noticed that b4 didn't pick up your Reviewed-by tag automatically (possibly because
>> it was on the same line as "LGTM.").
>
> That is correct -- code review trailers must always be on a separate line for
> any tooling to properly recognize them.

Got it. Will do that from now on. Thank you both for pointing this out.

Best Regards,
Yan, Zi