From: Wei Yang <richard.weiyang@gmail.com>
To: akpm@linux-foundation.org, dan.j.williams@intel.com, mhocko@suse.com
Cc: linux-mm@kvack.org, Wei Yang <richard.weiyang@gmail.com>
Subject: [RFC PATCH] mm: add a vma to vmacache when addr overlaps the vma range
Date: Tue, 16 Oct 2018 21:47:12 +0800 [thread overview]
Message-ID: <20181016134712.18123-1-richard.weiyang@gmail.com> (raw)
vmacache will cache the latest visited vma to improve the performance of
find_vma(). While current implementation would cache a vma even its range
doesn't overlap with addr.
This entry in vmacache will be a dummy entry, since the vmacache_find()
only returns a vma when its range overlap with addr.
This patch avoid to add a vma to vmacache when the range doesn't
overlap.
Signed-off-by: Wei Yang <richard.weiyang@gmail.com>
---
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.
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
next reply other threads:[~2018-10-16 13:47 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-16 13:47 Wei Yang [this message]
2018-10-16 13:54 ` [RFC PATCH] mm: add a vma to vmacache when addr overlaps the vma range Matthew Wilcox
2018-10-16 14:17 ` 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=20181016134712.18123-1-richard.weiyang@gmail.com \
--to=richard.weiyang@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=dan.j.williams@intel.com \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.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;
as well as URLs for NNTP newsgroup(s).