Received: by 2002:a25:b794:0:0:0:0:0 with SMTP id n20csp5122654ybh; Wed, 7 Aug 2019 00:52:03 -0700 (PDT) X-Google-Smtp-Source: APXvYqyDAjxHc8ZOZPGloBnW0P3bqteocy0ty0p8kQDYqLLsP/9rTdizkDMubnpl+UPL+IM94iy6 X-Received: by 2002:a62:e901:: with SMTP id j1mr8130403pfh.189.1565164323209; Wed, 07 Aug 2019 00:52:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1565164323; cv=none; d=google.com; s=arc-20160816; b=TAu3jfGv+sRstVqs1jlZSdyUF5DfF1vRxNF2Q+wWFUME8S6JWRkePCKnXpHx10Fx3K RjgK1iTfXJc9h1FRuKkjJBFl8++zWXc2h+eRF7cND4hxDcTTqOFk4vXzLH+ibNUkMnsg grMHhaakkyPgklNeXDcdNuOB9epxXq5tZliarFBx8Ja1muqWHsLx0THGdiiBKmGgVkRM WqpwYkCSMEv0hc2AJLrXaERu2N6JLIMvymJyTejIzoVvmCjc14tkRsnA7c0ouOSXOPTI whPTLDLH1zvZEpRqqjZZovBiFHvN76U2aTLUNkuexOW+FFsyRi/8n1VRTmZ0sVirWeo8 wN5w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=NiqSqWuBBWxZTNj/EkIyOWFFlLbLPmwn0ltZD+LjKds=; b=RcyZibBW5mpWce8t+TtlFSeyvo6hHwMeEXR4iWeEvt3HedCB6AZWXNzjDIeRgfsi9+ od/ltrYUlubd76MdE3GJAamX6SCSANdcNTIY8SVePKBzuua5OKIEGvBrE24AJk+1sQHv UzQCur56MoEqFdgtpmiQbyYbEp4LjEG6qDUKSYaDCoqHsN/Kp7FF8FbGmY6xJXUVNza5 IgP2XPNYxxBBbwnzVvXfiuHl05/sZkWoybRvLKUbDn8eByMvGZokZWxPVIDtiHMjL274 o8AX7SIUJCEu1X9AaBKSMr/JOdBy6IgtU6+kSy9/ETyI6/ynEsgF2BxIie6ajOkr2eoL HtrQ== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id c11si17677587pjq.0.2019.08.07.00.51.47; Wed, 07 Aug 2019 00:52:03 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2387439AbfHGHvD (ORCPT + 99 others); Wed, 7 Aug 2019 03:51:03 -0400 Received: from mx2.suse.de ([195.135.220.15]:35212 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727331AbfHGHvD (ORCPT ); Wed, 7 Aug 2019 03:51:03 -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 42D39AFDD; Wed, 7 Aug 2019 07:51:02 +0000 (UTC) Date: Wed, 7 Aug 2019 09:51:01 +0200 From: Michal Hocko To: Wei Yang Cc: Vlastimil Babka , akpm@linux-foundation.org, kirill.shutemov@linux.intel.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] mm/mmap.c: refine data locality of find_vma_prev Message-ID: <20190807075101.GN11812@dhcp22.suse.cz> References: <20190806081123.22334-1-richardw.yang@linux.intel.com> <3e57ba64-732b-d5be-1ad6-eecc731ef405@suse.cz> <20190807003109.GB24750@richard> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190807003109.GB24750@richard> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed 07-08-19 08:31:09, Wei Yang wrote: > On Tue, Aug 06, 2019 at 11:29:52AM +0200, Vlastimil Babka wrote: > >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? > > Vlastimil > > Thanks for your comment. > > I believe you get a point. I may not use the word locality. This patch tries > to reduce some unnecessary assignment of pprev. > > Original code would assign the value on each node during iteration, this is > what I want to reduce. Is there any measurable difference (on micro benchmarks or regular workloads)? -- Michal Hocko SUSE Labs