Received: by 2002:a25:b794:0:0:0:0:0 with SMTP id n20csp3855415ybh; Tue, 6 Aug 2019 02:32:17 -0700 (PDT) X-Google-Smtp-Source: APXvYqwBplsGR9Y6wgjmwsSUbuPJNv4jziW6M3oxyAAhafcVMxn5bpVyhKDMhrQt+OLBPNbOZxfy X-Received: by 2002:a17:90a:b312:: with SMTP id d18mr2168088pjr.35.1565083937081; Tue, 06 Aug 2019 02:32:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1565083937; cv=none; d=google.com; s=arc-20160816; b=eQZsswWzWwAZdUhQK1mANvWFcRACzlolaWwgMCP3ApfTT1WJAQLNUj9Kdkozc9QfyG HqIxO9tBAhIjTCXzLuhXO96ejg8NT8PVRtiJbP6PUYkeo1JDwcRkN0VDJEavh8F/Jv3N /KOcwcGEscx0LQuz8fTjaKEgVxWt2zDvLcQDq8dZNToh9bTMuFbqsCCcpTrV12rPk4S/ 1NmcI7+whhg87OwIyZMauyO1OXOFd4qyfPGqjibJwU9UF6vFFwittDD5K/TCiqrTg60c 7CVJRp2qz8TnzTXYiEE8y129yOmamtIzBncydIFgW0tUF+iUwDkoZqiAja/ltKpFwh9z Arog== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=T2ELb0ZhBbYWqNNSohuWnmj+NPgNYqQ4wB6/MjFV1gw=; b=BiRVril5hqlzuxz7Kp+Y2OtUTI19s3f4ZWfEkxsUq7cJ/DBTIzj7AwelUz7lIOa0kf BQnHxkzE7WOMXy+nN6+XFE7GBxBAhyfRkqp2Wytl8iqKPictrfzgQl9fgGqTD9Q+ClWy CAIP6JsVtkkA72/U7G2Z/yaoUn9wS77iF7k0S1lDdlQpYlozThF5wHUChIbMayH32XOv zW//DhFOba6sU5FBh147lzsrftlk24gYsJvoppXr5hKsuahv97Ev7fWOBLl3v7Z0sqsf LIRhJfbe47i8l2IeII4/OAzqhNZhEWRaVd9s1hUNSmqeS2txaRLJPBShMMpTRWDzRP2t MgLw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 1si48252480pfe.271.2019.08.06.02.32.01; Tue, 06 Aug 2019 02:32:17 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732428AbfHFJ3y (ORCPT + 99 others); Tue, 6 Aug 2019 05:29:54 -0400 Received: from mx2.suse.de ([195.135.220.15]:46788 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726713AbfHFJ3x (ORCPT ); Tue, 6 Aug 2019 05:29:53 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id DB23AAE6F; Tue, 6 Aug 2019 09:29:52 +0000 (UTC) Subject: Re: [PATCH] mm/mmap.c: refine data locality of find_vma_prev To: Wei Yang , akpm@linux-foundation.org, mhocko@suse.com, kirill.shutemov@linux.intel.com Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <20190806081123.22334-1-richardw.yang@linux.intel.com> From: Vlastimil Babka Message-ID: <3e57ba64-732b-d5be-1ad6-eecc731ef405@suse.cz> Date: Tue, 6 Aug 2019 11:29:52 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <20190806081123.22334-1-richardw.yang@linux.intel.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 > --- > 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; > } >