From: Mike Kravetz <mike.kravetz@oracle.com>
To: Zhigang Lu <totty.lu@gmail.com>,
luzhigang001@gmail.com, linux-mm@kvack.org,
linux-kernel@vger.kernel.org
Cc: Zhigang Lu <tonnylu@tencent.com>
Subject: Re: [PATCH v2] mm/hugetlb: avoid looping to the same hugepage if !pages and !vmas
Date: Tue, 3 Sep 2019 14:26:08 -0700 [thread overview]
Message-ID: <1f0e6e1a-c947-f389-801e-b1d748cb5bce@oracle.com> (raw)
In-Reply-To: <1567086657-22528-1-git-send-email-totty.lu@gmail.com>
On 8/29/19 6:50 AM, Zhigang Lu wrote:
> From: Zhigang Lu <tonnylu@tencent.com>
>
> When mmapping an existing hugetlbfs file with MAP_POPULATE, we find
> it is very time consuming. For example, mmapping a 128GB file takes
> about 50 milliseconds. Sampling with perfevent shows it spends 99%
> time in the same_page loop in follow_hugetlb_page().
>
> samples: 205 of event 'cycles', Event count (approx.): 136686374
> - 99.04% test_mmap_huget [kernel.kallsyms] [k] follow_hugetlb_page
> follow_hugetlb_page
> __get_user_pages
> __mlock_vma_pages_range
> __mm_populate
> vm_mmap_pgoff
> sys_mmap_pgoff
> sys_mmap
> system_call_fastpath
> __mmap64
>
> follow_hugetlb_page() is called with pages=NULL and vmas=NULL, so for
> each hugepage, we run into the same_page loop for pages_per_huge_page()
> times, but doing nothing. With this change, it takes less then 1
> millisecond to mmap a 128GB file in hugetlbfs.
Thanks for the analysis!
Just curious, do you have an application that does this (mmap(MAP_POPULATE)
for an existing hugetlbfs file), or was this part of some test suite or
debug code?
> Signed-off-by: Zhigang Lu <tonnylu@tencent.com>
> Reviewed-by: Haozhong Zhang <hzhongzhang@tencent.com>
> Reviewed-by: Zongming Zhang <knightzhang@tencent.com>
> Acked-by: Matthew Wilcox <willy@infradead.org>
> ---
> mm/hugetlb.c | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> index 6d7296d..2df941a 100644
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -4391,6 +4391,17 @@ long follow_hugetlb_page(struct mm_struct *mm, struct vm_area_struct *vma,
> break;
> }
> }
It might be helpful to add a comment here to help readers of the code.
Something like:
/*
* If subpage information not requested, update counters
* and skip the same_page loop below.
*/
> +
> + if (!pages && !vmas && !pfn_offset &&
> + (vaddr + huge_page_size(h) < vma->vm_end) &&
> + (remainder >= pages_per_huge_page(h))) {
> + vaddr += huge_page_size(h);
> + remainder -= pages_per_huge_page(h);
> + i += pages_per_huge_page(h);
> + spin_unlock(ptl);
> + continue;
> + }
> +
> same_page:
> if (pages) {
> pages[i] = mem_map_offset(page, pfn_offset);
>
With a comment added to the code,
Reviewed-by: Mike Kravetz <mike.kravetz@oracle.com>
--
Mike Kravetz
next prev parent reply other threads:[~2019-09-03 21:26 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-29 13:50 Zhigang Lu
2019-09-03 21:26 ` Mike Kravetz [this message]
2019-09-04 3:24 ` 陆志刚
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=1f0e6e1a-c947-f389-801e-b1d748cb5bce@oracle.com \
--to=mike.kravetz@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=luzhigang001@gmail.com \
--cc=tonnylu@tencent.com \
--cc=totty.lu@gmail.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