linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: John Hubbard <jhubbard@nvidia.com>
To: David Hildenbrand <david@redhat.com>,
	linmiaohe <linmiaohe@huawei.com>, <akpm@linux-foundation.org>,
	<richardw.yang@linux.intel.com>, <sfr@canb.auug.org.au>,
	<rppt@linux.ibm.com>, <jannh@google.com>, <steve.capper@arm.com>,
	<catalin.marinas@arm.com>, <aarcange@redhat.com>,
	<chenjianhong2@huawei.com>, <walken@google.com>,
	<dave.hansen@linux.intel.com>, <tiny.windzz@gmail.com>
Cc: <linux-mm@kvack.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] mm: get rid of odd jump label in find_mergeable_anon_vma
Date: Fri, 15 Nov 2019 15:38:30 -0800	[thread overview]
Message-ID: <b4d8cbf4-c553-2594-9d92-6d7e58eb246c@nvidia.com> (raw)
In-Reply-To: <5277de34-ecb3-831e-c697-1fd3f66b45ba@redhat.com>

On 11/15/19 4:58 AM, David Hildenbrand wrote:
> On 15.11.19 07:36, linmiaohe wrote:
>> From: Miaohe Lin <linmiaohe@huawei.com>
> 
> I'm pro removing unnecessary jump labels.

Thank you, simpler code is good--all other things being equal. 
The  tradeoff is, as Qian points out: code churn and risk in critical 
code paths.

In this case, I'd claim it's OK to improve this one, because we
can likely get it right by visual inspection, and the pre-existing
code is quite poor. And being in the kernel does not necessarily give
weak code a free pass to remain there and incur maintenance and annoyance
costs until the end of time. :)

However, please spend equal time when you write your commit descriptions,
because that's also very important. Commit logs should also be clear!

> 
> Subject: "mm: get rid of jump labels in find_mergeable_anon_vma()"
> 
>>
>> The odd jump label try_prev and none is not really need

s/need/needed/

> 
> s/odd jump label/jump labels/
> 
> s/is/are/
> 
>> in func find_mergeable_anon_vma, eliminate them to
>> improve readability.
>>
>> Signed-off-by: Miaohe Lin <linmiaohe@huawei.com>
>> ---
>>  mm/mmap.c | 18 +++++++-----------
>>  1 file changed, 7 insertions(+), 11 deletions(-)
>>
>> diff --git a/mm/mmap.c b/mm/mmap.c
>> index 4d4db76a07da..ab980d468a10 100644
>> --- a/mm/mmap.c
>> +++ b/mm/mmap.c
>> @@ -1276,25 +1276,21 @@ static struct anon_vma *reusable_anon_vma(struct vm_area_struct *old, struct vm_
>>   */
>>  struct anon_vma *find_mergeable_anon_vma(struct vm_area_struct *vma)
>>  {
>> -	struct anon_vma *anon_vma;
>> +	struct anon_vma *anon_vma = NULL;
>>  	struct vm_area_struct *near;
>>  
>>  	near = vma->vm_next;
>> -	if (!near)
>> -		goto try_prev;
>> -
>> -	anon_vma = reusable_anon_vma(near, vma, near);
>> +	if (near)
>> +		anon_vma = reusable_anon_vma(near, vma, near);>  	if (anon_vma)
>>  		return anon_vma;
> 
> Let me suggest the following instead:
> 
> /* Try next first */
> near = vma->vm_next;
> if (near) {
> 	anon_vma = reusable_anon_vma(near, vma, near);
> 	if (anon_vma)
> 		return anon_vma;
> }
> /* Try prev next */
> near = vma->vm_prev;
> if (near) {
> 	anon_vma = reusable_anon_vma(near, vma, near);
> 	if (anon_vma)
> 		return anon_vma;
> }
> 

Actually, it can be further simplified, because you don't need
that last "if" statement, because you're returning NULL after this.

So just return anon_vma there. (And adjust the comment block at the 
end, so that it's clear that anon_vma might be null.)


thanks,
-- 
John Hubbard
NVIDIA

>> -try_prev:
>> -	near = vma->vm_prev;
>> -	if (!near)
>> -		goto none;
>>  
>> -	anon_vma = reusable_anon_vma(near, near, vma);
>> +	near = vma->vm_prev;
>> +	if (near)
>> +		anon_vma = reusable_anon_vma(near, near, vma);
>>  	if (anon_vma)
>>  		return anon_vma;
>> -none:
>> +
>>  	/*
>>  	 * There's no absolute need to look only at touching neighbours:
>>  	 * we could search further afield for "compatible" anon_vmas.
>>
> 
> 


  reply	other threads:[~2019-11-15 23:38 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-15  6:36 linmiaohe
2019-11-15 11:49 ` Qian Cai
2019-11-15 12:58 ` David Hildenbrand
2019-11-15 23:38   ` John Hubbard [this message]
2019-11-16  0:37   ` Wei Yang
2019-11-18  3:14 linmiaohe

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b4d8cbf4-c553-2594-9d92-6d7e58eb246c@nvidia.com \
    --to=jhubbard@nvidia.com \
    --cc=aarcange@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=catalin.marinas@arm.com \
    --cc=chenjianhong2@huawei.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=david@redhat.com \
    --cc=jannh@google.com \
    --cc=linmiaohe@huawei.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=richardw.yang@linux.intel.com \
    --cc=rppt@linux.ibm.com \
    --cc=sfr@canb.auug.org.au \
    --cc=steve.capper@arm.com \
    --cc=tiny.windzz@gmail.com \
    --cc=walken@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox