All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vlastimil Babka <vbabka@suse.cz>
To: Wei Yang <richardw.yang@linux.intel.com>,
	akpm@linux-foundation.org, mhocko@suse.com,
	kirill.shutemov@linux.intel.com
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mm/mmap.c: refine data locality of find_vma_prev
Date: Tue, 6 Aug 2019 11:29:52 +0200	[thread overview]
Message-ID: <3e57ba64-732b-d5be-1ad6-eecc731ef405@suse.cz> (raw)
In-Reply-To: <20190806081123.22334-1-richardw.yang@linux.intel.com>

On 8/6/19 10:11 AM, Wei Yang wrote:
> When addr is out of the range of the whole rb_tree, pprev will points to
> the biggest node. find_vma_prev gets is by going through the right most

s/biggest/last/ ? or right-most?

> node of the tree.
> 
> Since only the last node is the one it is looking for, it is not
> necessary to assign pprev to those middle stage nodes. By assigning
> pprev to the last node directly, it tries to improve the function
> locality a little.

In the end, it will always write to the cacheline of pprev. The caller has most
likely have it on stack, so it's already hot, and there's no other CPU stealing
it. So I don't understand where the improved locality comes from. The compiler
can also optimize the patched code so the assembly is identical to the previous
code, or vice versa. Did you check for differences?

The previous code is somewhat more obvious to me, so unless I'm missing
something, readability and less churn suggests to not change.

> Signed-off-by: Wei Yang <richardw.yang@linux.intel.com>
> ---
>  mm/mmap.c | 7 +++----
>  1 file changed, 3 insertions(+), 4 deletions(-)
> 
> diff --git a/mm/mmap.c b/mm/mmap.c
> index 7e8c3e8ae75f..284bc7e51f9c 100644
> --- a/mm/mmap.c
> +++ b/mm/mmap.c
> @@ -2271,11 +2271,10 @@ find_vma_prev(struct mm_struct *mm, unsigned long addr,
>  		*pprev = vma->vm_prev;
>  	} else {
>  		struct rb_node *rb_node = mm->mm_rb.rb_node;
> -		*pprev = NULL;
> -		while (rb_node) {
> -			*pprev = rb_entry(rb_node, struct vm_area_struct, vm_rb);
> +		while (rb_node && rb_node->rb_right)
>  			rb_node = rb_node->rb_right;
> -		}
> +		*pprev = rb_node ? NULL
> +			 : rb_entry(rb_node, struct vm_area_struct, vm_rb);
>  	}
>  	return vma;
>  }
> 


  reply	other threads:[~2019-08-06  9:29 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-06  8:11 [PATCH] mm/mmap.c: refine data locality of find_vma_prev Wei Yang
2019-08-06  9:29 ` Vlastimil Babka [this message]
2019-08-07  0:31   ` Wei Yang
2019-08-07  7:51     ` Michal Hocko
2019-08-08  3:26       ` Wei Yang
2019-08-08  6:02         ` Michal Hocko
2019-08-08  8:44           ` Wei Yang
2019-08-08  8:49         ` Vlastimil Babka
2019-08-08 14:33           ` Wei Yang
2019-08-06 10:58 ` Balbir Singh
2019-08-07  0:32   ` Wei Yang

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=3e57ba64-732b-d5be-1ad6-eecc731ef405@suse.cz \
    --to=vbabka@suse.cz \
    --cc=akpm@linux-foundation.org \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@suse.com \
    --cc=richardw.yang@linux.intel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.