From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg1-f198.google.com (mail-pg1-f198.google.com [209.85.215.198]) by kanga.kvack.org (Postfix) with ESMTP id 0CA006B0006 for ; Tue, 16 Oct 2018 09:54:08 -0400 (EDT) Received: by mail-pg1-f198.google.com with SMTP id r16-v6so17058037pgv.17 for ; Tue, 16 Oct 2018 06:54:08 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org. [2607:7c80:54:e::133]) by mx.google.com with ESMTPS id g3-v6si14061978pgj.74.2018.10.16.06.54.06 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 16 Oct 2018 06:54:06 -0700 (PDT) Date: Tue, 16 Oct 2018 06:54:04 -0700 From: Matthew Wilcox Subject: Re: [RFC PATCH] mm: add a vma to vmacache when addr overlaps the vma range Message-ID: <20181016135404.GA13818@bombadil.infradead.org> References: <20181016134712.18123-1-richard.weiyang@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20181016134712.18123-1-richard.weiyang@gmail.com> Sender: owner-linux-mm@kvack.org List-ID: To: Wei Yang Cc: akpm@linux-foundation.org, dan.j.williams@intel.com, mhocko@suse.com, linux-mm@kvack.org On Tue, Oct 16, 2018 at 09:47:12PM +0800, Wei Yang wrote: > Based on my understanding, this change would put more accurate vma entry in the > cache, which means reduce unnecessary vmacache update and vmacache find. > > But the test result is not as expected. From the original changelog, I don't > see the explanation to add this non-overlap entry into the vmacache, so > curious about why this performs a little better than putting an overlapped > entry. What makes you think this performs any differently for this test-case? The numbers all seem to fall within a "reasonable variation" range to me. You're going to need to do some statistics (with a much larger sample size) to know whether there's any difference at all. > Below is the test result for building kernel in two cases: > > make -j4 make -j8 > base-line: > > real 6m15.947s real 5m11.684s > user 21m14.481s user 27m23.471s > sys 2m34.407s sys 3m13.233s > > real 6m16.089s real 5m11.445s > user 21m18.295s user 27m24.045s > sys 2m35.551s sys 3m13.443s > > real 6m16.239s real 5m11.218s > user 21m17.590s user 27m19.133s > sys 2m35.252s sys 3m12.684s > > patched: > > real 6m15.416s real 5m10.810s > user 21m21.800s user 27m25.223s > sys 2m33.398s sys 3m14.784s > > real 6m15.114s real 5m12.285s > user 21m19.986s user 27m32.055s > sys 2m34.718s sys 3m13.107s > > > real 6m16.206s real 5m11.509s > user 21m22.557s user 27m28.265s > sys 2m35.637s sys 3m12.747s > > > --- > mm/mmap.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/mm/mmap.c b/mm/mmap.c > index 2e0daf666f42..dda495d84862 100644 > --- a/mm/mmap.c > +++ b/mm/mmap.c > @@ -2214,7 +2214,7 @@ struct vm_area_struct *find_vma(struct mm_struct *mm, unsigned long addr) > rb_node = rb_node->rb_right; > } > > - if (vma) > + if (vma && vma->vm_start <= addr) > vmacache_update(addr, vma); > return vma; > } > -- > 2.15.1 >